Bonjour, Frédéric écrit : Ne peut-on pas considérer que cette fonctionnalité relève du confort d’utilisation ? En particulier, si le libellé/titre associé à l’action (lien ou bouton) est suffisamment explicite.
Difficile de répondre au mieux sans connaître le type de données et le contexte mais la mise en place d'une confirmation de suppression répond dans la grande majorité des cas à des besoins de sécurité et n'est en rien comparable à un bon intitulé d'action : l'intitulé n'empêchera pas une mauvaise manipulation. Si dans ton contexte, tu considères que le processus de suppression n'a pas à être confirmé et qu'un clic est suffisant pour le provoquer alors oui, c'est une fonctionnalité de confort. Pour les solutions techniques, tu as en plus de mon précédent message la solution proposée par Aurélien. Solution excellente mais qui est bien plus complexe d'implémentation puisqu'il s'agit de temporiser le processus de suppression. Romain Le 17 juillet 2013 10:47, Aurélien Levy <[email protected]> a écrit : > Sauf erreur de ma part l'obligation ne porte que sur les informations à > caractères personnelles, financiers ou juridiques. > Par ailleurs si l'utilisateur à la possibilité de recréer l'information > qu'il a supprimé il me semble pas non plus avoir obligation de demande de > confirmation (après tout dépend de la complexité d'ajout de l'info) > > Aurélien > > Bonjour,**** > > ** ** > > Je remonte ce vieux sujet.**** > > ** ** > > La position de Romain était la suivante :**** > > « Une demande de confirmation (de toute action) réalisée sur le client est > soumise à alternative pour se conformer et à RGAA et à AccessiWeb. »**** > > Cette position fait-elle l’unanimité ?**** > > Ne peut-on pas considérer que cette fonctionnalité relève du confort > d’utilisation ? En particulier, si le libellé/titre associé à l’action > (lien ou bouton) est suffisamment explicite.**** > > ** ** > > *Frédéric BERNIER-MALCOIFFE* > > ** ** > > *De :* liste_gta > [mailto:[email protected]<[email protected]>] > *De la part de* Romain Gervois > *Envoyé :* vendredi 8 février 2013 13:40 > *À :* GTA > *Objet :* Re: [Liste GTA] Message de demande de confirmation**** > > ** ** > > Bonjour, > > > Une demande de confirmation (de toute action) réalisée sur le client est > soumise à alternative pour se conformer et à RGAA et à AccessiWeb. > > La solution 1 évoquée est le point de départ (ce qui fait office > d'alternative) : un bouton ou un lien selon la conception amène soit sur > une nouvelle page soit sur la même page après rechargement. Les questions > de l'emplacement du message et de la discrimination des données se posent > en effet. > > La solution 2 évoquée correspond au script qui se substituera à la > solution 1. Deux possibilités pour cette demande de confirmation : confirm > ou fenêtre modale. confirm est géré nativement et est très bien supporté > (lecteurs d'écran compris). Pour la fenêtre modale, c'est plus délicat > puisque cela entraîne un développement assez conséquent par rapport à > confirm : > - sauvegarder l'élément à l'origine de l'ouverture de la fenêtre modale ; > - donner le focus à la fenêtre modale (tabindex à 0 en plus du role dialog > et du aria-labelledby ; on peut imaginer du aria-hidden sur l'arrière-plan) > ; > - conserver le focus dans la fenêtre modale tant qu'aucune réponse n'a été > fournie (manipulation des tabindex (attention au contexte) et du focus) ; > - redonner le focus à l'élément à l'origine de l'ouverture de la fenêtre > modale à la fermeture. > > Cela dépendra donc du choix entre "Vieux Web" et "Nouveau Web (?)" sans > parler des autres contraintes inhérentes. > > Enfin, le point n'est pas abordé dans le sujet mais la façon dont le > traitement s'effectue après confirmation dans un contexte client > nécessitera attention. > Si à la confirmation, la suppression est portée sur le client (suppression > de l'élément sans rafraichissement et communication vers le serveur via > AJAX), une zone de notification ne sera pas un luxe (role alert et gestion > du focus à prévoir) - c'est également vrai côté serveur.**** > > > Espérant que ça aide. > Romain**** > > Le 8 février 2013 12:26, Frédéric BERNIER-MALCOIFFE < > [email protected]> a écrit :**** > > Bonjour à tous,**** > > **** > > Je souhaite vous solliciter pour avoir votre avis sur le sujet suivant.*** > * > > Comment mettre en œuvre un mécanisme de demande de confirmation suite, par > exemple, à une action de suppression d’un item dans une liste présentée > dans un tableau de données ?**** > > **** > > La solution qui vient tout de suite à l’esprit est l’utilisation de la > fonction confirm de JavaScript. Mais :**** > > · Fait-elle partie du champ d’application du test RGAA « 8.12 : > Présence d'une alternative au code javascript » ? En d’autres termes, cela > nécessite-t-il de mettre en œuvre une alternative côté serveur ?**** > > · Est-elle correctement prise en charge par tous les agents > utilisateurs (lecteurs d’écran en particulier) ?**** > > **** > > Cette solution est envisageable pour un back-office. Mais la MOA est > réticente (« ça fait vieux Web ») pour l’appliquer à la partie grand public. > **** > > Dans ce cas, quelles sont les alternatives ?**** > > · Solution 1 : Suite au lancement de l’action, rechargement de la > page et affichage d’un message de confirmation « Voulez-vous supprimer > l’item XXX ? » + liens « Oui » et « Non ». En plus du surcoût indéniable > pour développer cela, il y a des questions d’ergonomie.**** > > o Où placer ce message ?**** > > o « XXX » doit être suffisamment discriminant. Or, pour certains types > données, la discrimination est difficile et ne s’obtient que par la > concaténation de plusieurs infos de la donnée.**** > > · Solution 2 : Affichage dans une popup-inline de la solution 1 > lorsque JavaScript est activé et solution 1 lorsque JavaScript n’est pas > activé**** > > **** > > Merci de votre aide,**** > > **** > > [image: Description : effitic]**** > > FREDERIC BERNIER-MALCOIFFE chef de projets > *a : *1, rue du Château de l'Eraudière 44306 NANTES Cedex 3 > *t : *+33 (0)2.51.89.78.78 - *f : *+33 (0)2.51.89.78.50 > *ld : *+33 (0) 2.51.89.78.66 - *p : *32.66**** > > **** > > **** > > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org* > *** > > ** ** > > > _______________________________________________ > liste_gta mailing > [email protected]http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > > > > _______________________________________________ > liste_gta mailing list > [email protected] > http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org > >
<<image/jpeg>>
_______________________________________________ liste_gta mailing list [email protected] http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
