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
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
[Liste GTA] Message de demande de confirmation
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 - f : +33 (0)2.51.89.78.50 ld : +33 (0) 2.51.89.78.66 - p : 32.66 image001.jpg___ liste_gta mailing list liste_gta@list.accessiweb.org http://list.accessiweb.org/mailman/listinfo/liste_gta_list.accessiweb.org
