Formulaire

Critère 11.4 [A] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés ?

Ajouter ma proposition
  • Proposition DINSIC | 06/04/2019 - 22:37

    Modification du critère 11.4

    Raison de la modiciation du critère 11.4

    Ajout d'un cas particulier pour les test 11.4.2 et 11.4.3

    Ancien critère 11.4

    Critère 11.4 [A] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés ?

    Nouveau critère 11.4

    Critère 11.4 [A] Dans chaque formulaire, chaque étiquette de champ et son champ associé sont-ils accolés (hors cas particuliers) ?

    halnaf

    Quelle est la valeur de "Dans chaque formulaire" ? est-ce qu'on doit prendre en compte que les champs de formulaire contenu dans une balise form ? ne faudrait-il pas modifier le critère comme suit:
    "Chaque champ de formulaire et son étiquette associée sont-ils accolés (hors cas particulier) ?"

    • Pas d'accord 0 Pas d'accord

  • Proposition DINSIC | 27/11/2018 - 11:04

    Création du test 11.4.2

    Raison de le la création du test 11.4.2

    Test ajouté suite à la prise en compte des contraintes présentent dans la technique G162 des WCAG.

    Nouveau test 11.4.2

    Test 11.4.2 : Chaque étiquette accolée à un champ (à l'exception des case à cocher, bouton radio ou balises ayant un attribut WAI-ARIA role="checkbox", role="radio" ou role="switch"), vérifie-t-elle ces conditions (hors cas particulier)? 

    • L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de gauche à droite.
    • L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche

    Mise(s) à jour 

    • le 06/04/2019 suite à proposition DINSIC le 30/01/2019 - 22:05

    JPV

    Sur la référence du sens de lecture

    La référence du sens de lecture est importante puisque c'est elle qui va décider de la position de l'étiquette.
    Actuellement le test propose de prendre comme référence le sens de lecture de l'étiquette ce qui est très insuffisant :

    • Dans le cas où l'étiquette mélange une portion de texte qui se lit de droite à gauche avec une portion de texte qui se lit de gauche à droite.
    • Dans le cas où un formulaire contient des labels de plusieurs langues qui se liraient de droite à gauche et inversement. Par exemple un formulaire de commande en arabe qui propose une liste de case à cocher de produit en langue française ou mixant des produits en langue arabe ou en langue française.

    Dans ces deux cas les tests actuellement rédigés obligeraient à alterner le positionnement des étiquettes en langue arabe à gauche des cases à cocher et les étiquettes en langue française à droite.
    Ce qui serait naturellement très peu approprié.

    Une solution serait de prendre la langue de traitement ce qui donnerait comme test :

    L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la page est de gauche à droite.

    Mais se serait également insuffisant dans le cas de contenu multilingue.
    Par exemple une page bilingue qui contient deux formulaires identiques, l'un dans la langue de traitement de la page et l'autre dans une langue dont le sens de lecture est inversé.

    Cas des éléments de formulaire complexes ou d'éléments de saisie développés avec JavaScript

    Les types checkbox ou radio peuvent être utilisés pour créer des composants qui ne se présentent pas visuellement comme des cases à cocher ou des boutons radios.
    C'est le cas par exemple des switch button ou de composant plus complexes pour lequel il pourrait être légitime, du point de vue UX, de placer les étiquettes à gauche.

    Un même formulaire peut contenir des composants de formulaire natif et des composants développés avec JavaScript. Actuellement les tests ne prennent pas en compte, par exemple, une case à cocher développé avec ARIA et basé sur un élément HTML quelconque.

    Enfin les applications web, notamment celles qui sont proposées en mode "application" peuvent contenir des éléments particuliers, comme des listes d'options de menu dans lequel il peut être également légitime de positionner les cases à cocher ou les boutons radios à droite des étiquettes qui les définissent.

    Sur le fond

    La diversité des situations dans lesquelles cette recommandation ferait peser une contrainte trop forte, voire générerait une dégradation de l'utilisabilité ou de l'ergonomie d'interface particulière rend une application stricte difficilement réalisable.

    Même si, de manière générale, elle pourra être suivie il est inévitable qu'elle génère des conflits légitimes.

    On peut s'interroger en revanche sur le but poursuivi par les deux critères WCAG et par la technique elle-même.

    Le but est de pouvoir établir, visuellement, une liaison prédictive entre l'étiquette et sa saisie et s'adapter à des types de consultations spécifiques notamment avec une loupe d'écran.

    Par exemple pour les cases à cocher ce que l'on veut surtout contrôler c'est la présentation d'une série de cases à cocher associée à des labels de longueur différentes, la case à cocher étant un objet de largeur fixe.

    L'autre argument est de respecter un usage mais il faut remarquer que cette technique est très ancienne et ne prends pas en compte la formidable évolution du web particulièrement dans le domaine des SPA.

    Avoir des étiquettes positionnées de manière cohérente sur l'ensemble du formulaire

    Une possibilité pour prendre en charge cette problématique sans créer des contraintes qui pourraient être jugée déraisonnable ou entrer en conflit avec des objectifs d'utilisabilité, d'ergonomie ou d'UX serait de créer un critère plus générique associé à une définition de glossaire qui présenterait la technique et ses objectifs tout en laissant la possibilité d'adapter la recommandation à des contextes particuliers.

    Proposition

    Test 11.4.2 : Pour chaque formulaire ou écran de saisie, les étiquettes des champs ou des éléments de saisie sont-elles positionnées de manière cohérente ?

    Définition de glossaire

    Ecran de saisie

    Ecran faisant intervenir des champs de saisie qui utilisent des éléments HTML natifs ou développés avec JavaScript, par exemple dans une application Web.

    Positionnées de manière cohérente

    La technique G162 préconise que les étiquettes des champs de saisie de texte ou de valeurs prédéterminées, comme les listes par exemple, soient placées avant le champ, donc à gauche ou en haut des champs concernés. À l'inverse, les étiquettes des champs de type radio ou case à cocher devraient être placées après le champ, donc à droite ou en bas.

    Cette recommandation devrait être généralement suivie, elle permet de rendre la liaison visuelle entre l'étiquette et son champ plus prédictive, elle correspond à l'usage et permet de faciliter la prise en charge de contextes de consultation particuliers.

    Néanmoins il peut exister des cas de figure spécifiques où cette recommandation pourrait entrer en conflit avec des caractéristiques particulières d'un écran de saisie dans une application web par exemple.
    Dans ce cas l'objectif est de vérifier que les principes de positionnement appliqués à tous les éléments de saisie sont cohérents entre-eux.
    Ainsi, si l'écran possède plusieurs groupes qui apparaissent visuellement comme des cases à cocher toutes leurs étiquettes devraient être positionnées de la même manière.

    Conformité WCAG/RGAA

    Il est à noter que ce positionnement, par rapport à la technique G162, ne pose aucun problème de conformité WCAG.
    Un contenu RGAA qui présenterait des écrans de saisie où les étiquettes des cases à cocher sont placés à gauche pour des raisons d'UX ou de caractéristiques spécifiques à l'application resterait conforme WCAG.
    La cohérence du positionnement permettant de considérer que le critère WCAG 1.3.1 ou 3.3.2 est satisfait.
    De même, un contenu WCAG dans le même cas resterait conforme RGAA alors qu'avec la rédaction actuelle ce serait l'inverse : le contenu WCAG serait jugé non-conforme RGAA alors même que le positionnement serait jugé "cohérent".

    Exemple de switch button de type checkbox

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    Nous proposons :

    • d’ajouter un cas particulier pour gérer le cas de la langue mixé
    • de créer une entrée de glossaire « case à cocher ou bouton radio » pour gérer le cas des champs simulés via aria

    En conséquence la nouvelle formulation sera la suivante (il sera fait de même pour le 11.4.3) :

    Test 11.4.2 : Chaque étiquette accolée à un champ autre qu’une case à cocher ou un bouton radio, vérifie-t-elle ces conditions ? (hors cas particulier)

    • L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de gauche à droite.
    • L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche
    • Pas d'accord 0 Pas d'accord

  • Proposition DINSIC | 27/11/2018 - 10:04

    Création du test 11.4.3

    Raison de la création du test 11.4.3

    Test ajouté suite à la prise en compte des contraintes dans la technique G162 des WCAG.

    Nouveau test 11.4.3

    Test 11.4.3 : Chaque étiquette accolée à un champ de type checkbox ou radio ou à une balise ayant un attributWAI-ARIA role="checkbox"role="radio" ou role="switch", vérifie-t-elle ces conditions (hors cas particulier) ?

    • L'étiquette est visuellement accolée immédiatement au-dessus ou à droite du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de gauche à droite.
    • L'étiquette est visuellement accolée immédiatement au-dessus ou à gauche du champ de formulaire lorsque le sens de lecture de la langue de l’étiquette est de droite à gauche

    Mise(s) à jour 

    • le 06/04/2019 suite à proposition DINSIC le 30/01/2019 - 22:05 sur test 11.4.2

    giuseppe.rosa

    Je pense qu'il s'agit d'une erreur de copier/coller du 11.4.2 : l'étiquette d'une case à cocher ou d'un bouton radio devrait se trouver à droite de l'élément.

    • Pas d'accord 0 Pas d'accord

    giuseppe.rosa

    Il faudra également modifier le critère car je pense que là on traitera de chekbox ou radio.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    Le nouveau test 11.4.3 a été modifié suite à votre commentaire, la définition de champ de formulaire dans le glossaire traite bien également de checkbox ou radio, l'intitulé du critère 11.4 n'a donc pas besoin d'être modifié

    • Pas d'accord 0 Pas d'accord

    lcarevic

    Bonsoir,

    L'erreur de copier/coller du 11.4.2 se trouve également sur l'intitulé du test : Test 11.4.3 : Chaque étiquette accolé à un champ de type différent de checkbox ou radio, vérifie-t-elle ces conditions ?

    Note : il y a également une coquille à corriger sur les deux tests sur accolée.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    merci pour ces retours sont pris en compte.

    • Pas d'accord 0 Pas d'accord

J'ajoute ma proposition

La concertation est bientôt lancée. Il n'est pas encore possible de participer

Retour en haut