Re: [Liste GTA] Message de demande de confirmation

[Aurélien Levy]

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:liste_gta-boun...@list.accessiweb.org] 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 <frederic.bernier-malcoi...@effitic.com> 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,   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 liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org   _______________________________________________ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org

_______________________________________________
liste_gta mailing list
liste_gta@list.accessiweb.org
http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org