Re: [Liste GTA] Message de demande de confirmation
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, 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 tel:%2B33%20%280%292.51.89.78.78 - f : +33 (0)2.51.89.78.50 tel:%2B33%20%280%292.51.89.78.50 ld : +33 (0) 2.51.89.78.66 tel:%2B33%20%280%29%202.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 image001.jpg___ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
Re: [Liste GTA] Message de demande de confirmation
Sauf erreur de ma part l'obligation ne porte que sur les informations caractres personnelles, financiers ou juridiques. Par ailleurs si l'utilisateur la possibilit de recrer l'information qu'il a supprim il me semble pas non plus avoir obligation de demande de confirmation (aprs tout dpend de la complexit d'ajout de l'info) Aurlien Bonjour, Je remonte ce vieux sujet. La position de Romain tait la suivante: Une demande de confirmation (de toute action) ralise sur le client est soumise alternative pour se conformer et RGAA et AccessiWeb. Cette position fait-elle lunanimit? Ne peut-on pas considrer que cette fonctionnalit relve du confort dutilisation? En particulier, si le libell/titre associ laction (lien ou bouton) est suffisamment explicite. Frdric BERNIER-MALCOIFFE De: liste_gta [mailto:liste_gta-boun...@list.accessiweb.org] De la part de Romain Gervois Envoy: vendredi 8 fvrier 2013 13:40 : GTA Objet: Re: [Liste GTA] Message de demande de confirmation Bonjour, Une demande de confirmation (de toute action) ralise sur le client est soumise alternative pour se conformer et RGAA et AccessiWeb. La solution 1 voque est le point de dpart (ce qui fait office d'alternative) : un bouton ou un lien selon la conception amne soit sur une nouvelle page soit sur la mme page aprs rechargement. Les questions de l'emplacement du message et de la discrimination des donnes se posent en effet. La solution 2 voque correspond au script qui se substituera la solution 1. Deux possibilits pour cette demande de confirmation : confirm ou fentre modale. confirm est gr nativement et est trs bien support (lecteurs d'cran compris). Pour la fentre modale, c'est plus dlicat puisque cela entrane un dveloppement assez consquent par rapport confirm : - sauvegarder l'lment l'origine de l'ouverture de la fentre modale ; - donner le focus la fentre modale (tabindex 0 en plus du role dialog et du aria-labelledby ; on peut imaginer du aria-hidden sur l'arrire-plan) ; - conserver le focus dans la fentre modale tant qu'aucune rponse n'a t fournie (manipulation des tabindex (attention au contexte) et du focus) ; - redonner le focus l'lment l'origine de l'ouverture de la fentre modale la fermeture. Cela dpendra donc du choix entre "Vieux Web" et "Nouveau Web (?)" sans parler des autres contraintes inhrentes. Enfin, le point n'est pas abord dans le sujet mais la faon dont le traitement s'effectue aprs confirmation dans un contexte client ncessitera attention. Si la confirmation, la suppression est porte sur le client (suppression de l'lment sans rafraichissement et communication vers le serveur via AJAX), une zone de notification ne sera pas un luxe (role alert et gestion du focus prvoir) - c'est galement vrai ct serveur. Esprant que a aide. Romain Le 8 fvrier 2013 12:26, Frdric 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 mcanisme de demande de confirmation suite, par exemple, une action de suppression dun itemdans une liste prsente dans un tableau de donnes ? La solution qui vient tout de suite lesprit est lutilisation de la fonction confirm de _javascript_. Mais: Fait-elle partie du champ dapplication du test RGAA 8.12 : Prsence d'une alternative au code _javascript_? En dautres termes, cela ncessite-t-il de mettre en uvre une alternative ct serveur? Est-elle correctement prise en charge par tous les agents
[Liste GTA] Dernier appel à commentaire pour l'extension html5 longdesc
Bonjour à toutes et tous, L'extension Html5 pour la description d'images complexes a été publiée comme version en dernier appel à comentaires par le W3C. Si ça vous dit de la lire et de la commenter, vous avez jusqu'au 16 septembre 2013. Tous les détails sont dans le message ci-dessous. Bonne journée Amicalmeent Sylvie Message original Sujet: Call for Review: HTML5 Image Description Extension (longdesc) Last Call Date : Tue, 16 Jul 2013 11:45:23 -0400 De : Mark Sadecki m...@w3.org Pour : w3c-wai...@w3.org Dear WAI Interest Group Participants, The HTML Accessibility Task Force [1], which is a joint task force of the Protocols and Formats Working Group (PFWG) and the HTML Working Group (HTML WG), invites your comments on the Last Call Working Draft of the HTML5 Image Description Extension at: http://www.w3.org/TR/html-longdesc This specification (HTML-longdesc) enables web authors to provide longer textual descriptions for complex images. HTML-longdesc is an extension specification that is part of the HTML5 family of specifications [2], which enables it to evolve independently and be finalized more rapidly. HTML-longdesc is part of W3C's work to ensure that the Open Web Platform [3] is accessible to people with disabilities [4]. This draft is based on feedback received on two previous Working Drafts and addresses a number of bugs that were raised and resolved. The HTML Accessibility Task Force believes this draft is stable and implementable, and looks forward to progressing to the next stages in completing the HTML5 Image Description Extension. Last Call and next stages are described in How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute at: http://www.w3.org/WAI/intro/w3c-process A list of changes since the previous publication and specific questions for review are available from the Change History section at: http://www.w3.org/TR/2013/WD-html-longdesc-20130716/Overview.html#changes Please send any comments on this Draft to the publicly-archived HTML Accessibility Task Force mailing list: public-html-a...@w3.org *by 16 September 2013* About the URI: The first URI above goes to the latest version of the specification. The dated version of this Working Draft is: http://www.w3.org/TR/2013/WD-html-longdesc-20130716/ The difference between these URIs is explained in Referencing and Linking to WAI Guidelines and Technical Documents at: http://www.w3.org/WAI/intro/linking Please let us know if you have any questions. Feel free to circulate this message to other lists; please avoid cross-postings where possible. Thank you in advance for your comments. Regards, ~ Mark Sadecki, W3C Staff Contact for the HTML Accessibility Task Force HTML Accessibility Task Force Co-Facilitators: Steve Faulkner, Charles McCathie-Neville, Janina Sajka WAI Outreach Coordinator: Shawn Henry WAI Domain Leader: Judy Brewer [1] Task Force http://www.w3.org/WAI/PF/html-accessibility-tf.html [2] Blog about extension specifications http://www.w3.org/QA/2012/09/getting_html5_to_recommendatio [3] Open Web Platform standards http://www.w3.org/standards/ [4] Accessibility - W3C http://www.w3.org/standards/webdesign/accessibility -- Mark Sadecki Web Accessibility Engineer World Wide Web Consortium, Web Accessibility Initiative Telephone: +1.617.715.4017 Email: m...@w3.org Web: http://w3.org/People/mark ___ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
Re: [Liste GTA] Message de demande de confirmation
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 aurelien.l...@temesis.com 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:liste_gta-boun...@list.accessiweb.orgliste_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