Formulaire

Critère 11.1 [A] Chaque champ de formulaire a-t-il une étiquette ?

Ajouter ma proposition
  • Proposition DINSIC | 27/11/2018 - 12:21

    Modification du test 11.1.1

    Raison de la modification du test 11.1.1

    • Référence directe à la balise <label>,
    • Modification de l'ordre des conditions pour reprendre l'ordre de calcul du nom accessible tel que prévu dans la spécification accname 1.1,
    • Nouvelle condition de test pour prendre en compte la technique G167 des WCAG.

    Ancien test 11.1.1

    Test 11.1.1 :Chaque champ de formulaire vérifie-t-il une de ces conditions ?

    • Le champ de formulaire possède un attribut title.
    • Une étiquette (balise <label>) est associée au champ de formulaire.
    • Le champ de formulaire possède une propriété aria-label.
    • Le champ de formulaire possède une propriété aria-labelledby référençant un passage de texte identifié.

    Nouveau test 11.1.1

    Test 11.1.1 : Chaque champ de formulaire vérifie-t-il une de ces conditions ?

    • Le champ de formulaire possède un attribut aria-labelledby référençant un passage de texte identifié.
    • Le champ de formulaire possède un attribut aria-label.
    • Une balise <label> ayant un attribut for est associée au champ de formulaire.
    • Le champ de formulaire possède un attribut title.
    • Un bouton adjacent au champ de formulaire lui fournit une étiquette visible et un attribut aria-label, aria-labelledby ou title lui fournit un nom accessible.

    Mise(s) à jour

    • le 06/04/2019 suite à proposition DINSIC le 30/01/2019 - 21:58 sur le test 11.1.2

    Armony de Koena

    J'ai une interrogation, pas sur le nouveau test en tant que tel, mais sur une des anciennes conditions, reprise ici, et qui me paraît bancale : "Le champ de formulaire possède un attribut aria-label.".

    Si le champ a seulement un attribut aria-label, sans indication visuelle associée, ça ne devrait pas être conforme, comme le suggère le SC 2.4.6 Headings and Labels qui se rattache aussi à ce critère RGAA.

    Je suggérerais donc d'ajouter la mention d'une indication visuelle, via texte adjacent visible ou titre précédent, au aria-label. Sachant que la technique ARIA6 est liée au est liée au SC 1.1.1 et non au SC 2.4.6. Il est donc nécessaire de combiner les 2 pour être cohérent.

    Qu'en pensez-vous ?

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour, ce point est déjà pris en compte par le Test 11.1.4 dont la dernière formulation proposée serait :

    Chaque champ de formulaire ayant une étiquette dont le contenu n'est pas visible ou à proximité ( masqué, aria-label, aria-labelledby), vérifie-t-il une de ses conditions ?

    • le champ de formulaire possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue
    • Pas d'accord 0 Pas d'accord

    halnaf

    En ce qui concerne la notion d'étiquette visible: est ce que cela implique un texte visible ?

    • Pas d'accord 0 Pas d'accord

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

    Modification du test 11.1.2

    Raison de la modification du test 11.1.2

    • Référence directe à la balise <label>.
    • ajout d'un condition en cas de présence d'attributs aria-label ou passage de texte associé faisant office de nom accessible via aria-labelledby.

    Ancien test 11.1.2

    Test 11.1.2 : Chaque champ de formulaire, associé à une étiquette (balise <label>), vérifie-t-il ces conditions ?

    • Le champ de formulaire possède un attribut id.
    • La valeur de l'attribut id est unique.
    • La balise <label> possède un attribut for.
    • La valeur de l'attribut for est égale à la valeur de l'attribut id du champ de formulaire associé.

    Nouveau test 11.1.2

     

    Test 11.1.2 : Chaque champ de formulaire associé à une balise <label> ayant un attribut for, vérifie-t-il ces conditions ?

    • Le champ de formulaire possède un attribut id.
    • La valeur de l'attribut for est égale à la valeur de l'attribut id du champ de formulaire associé.

    Mise(s) à jour

    • le 06/04/2019 suite à proposition DINSIC le 30/01/2019 - 21:58

    giuseppe.rosa

    Je ne vois pas l'intérêt de la 5ème condition. Dans le cas ou label et par exemple aria-labelledby est utilisé, ce dernier prime sur le label. Une condition du type reprend et/ou complète le contenu du label me conviendrait mieux.
    En effet, le label permet également de rattacher "physiquement" ce label à l'input (si xxx<:label>). A la souris, en cliquant sur le texte dans le label, le champ prend le focus. Ce n'est pas le cas si le label n'est pas rattaché avec le id/for.

    • Pas d'accord 0 Pas d'accord

    giuseppe.rosa

    Désolé, les balises sont masquée, je voulais dire dans le cas ou l'input n'est pas compris entre les balises label.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    Même si la mise à disposition d'un étiquette via la balise label associée via le mécanisme for / id reste la technique de référence à recommander, l'effet de prise de focus au clic sur le label n'est pas un élément requis par WCAG. Dès lors, il ne peut être rendu obligatoire dès qu'un autre mécanisme d'association explicite est présent.

    • Pas d'accord 0 Pas d'accord

    amaniez

    WCAG ne mentionne à aucun moment qu'il est interdit d'utiliser plusieurs méthodes de labellisation concurrentes pour un même champ, le document "HTML Accessibility API MAppings 1.0" https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-... est justement là pour traiter du calcul du nom accessible pour les champs de formulaires, notamment qui posséderaient plusieurs méthodes de labellisation.

    En quoi l'implémentation suivante serait considérée non conforme :

    <label for="myId" id="labelId">Courriel</label>

    <span id="myHelp">nomprenom@mail.com</span>

    <input type="text" id="myId" aria-labelledby="labelId myHelp"/>

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    Le code proposé est parfaitement conforme, le but visé ici est de ne rendre obligatoire la présence de l'id sur le champ et le fait que le contenu de l’attribut for du label corresponde à la valeur de l'id que lorsqu’il y a effectivement utilisation de la technique du <label>.

    Par ailleurs, l'unicité de l'id étant désormais explicitement intégré dans le test 8.2.1 il n'a plus de raison de conserver cette condition dans ce test.

    En conséquence, nous proposons la nouvelle formulation suivante :

    Test 11.1.2 : Chaque champ de formulaire associé à une étiquette <label> ayant un attribut for, vérifie-t-il ces conditions ?

    • Le champ de formulaire possède un attribut id.
    • La valeur de l'attribut for est égale à la valeur de l'attribut id du champ de formulaire associé.

    et de modifier la condition du test 11.1.1 portant sur la technique du <label> par :

    • Une balise <label> ayant un attribut for est associée au champ de formulaire.
    • Pas d'accord 0 Pas d'accord

    halnaf

    Dans le Test 11.1.2: Le champ de formulaire n'a pas d’attributs aria-label ou de passage de texte associé via aria-labelledby faisant office de nom accessible... la condition n'est-elle pas et / ou plutôt que ou ?

    • Pas d'accord 0 Pas d'accord

    DINSIC

    @halnaf la dernière formulation du test proposée suite aux échanges est dans notre commentaire précédant elle ne fait plus référence à aria-label ou à aria-labelledby

    • Pas d'accord 0 Pas d'accord

    DINSIC

    La proposition DINSIC initiale a été mise à jour

    • Pas d'accord 0 Pas d'accord

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

    Suppression du test 11.1.3

    Raison de la suppression du test 11.1.3

    Suppression du test suite à la modification de l'entrée de glossaire passage de texte qui précise désormais la présence de l'attribut id, son unicité et l'utilisation de sa valeur dans l'attribut aria-labelledby du champ correspondant. 

    Ancien test 11.1.3 (supprimé)

    Test 11.1.3 : Chaque champ de formulaire associé à une étiquette via la propriété ARIA aria-labelledby, vérifie-t-il ces conditions ?

    • L'étiquette possède un attribut id.
    • La valeur de l'attribut id est unique.
    • Les valeurs de la propriété ARIA aria-labelledby sont égales à la valeur des attributs id des passages de textes utilisés pour créer l'étiquette.

  • Proposition DINSIC | 27/11/2018 - 09:21

    Modification du test 11.1.4

    Raison de la modification du test 11.1.4

    Modification du test en raison de la prise en compte de l'usage de balise <label> masqué et suppression de l'expression redondante ARIA aria-xxx

    Ancien test 11.1.4

    Test 11.1.4 : Chaque champ de formulaire qui utilise une propriété ARIA aria-label ou aria-labelledby est-il, si nécessaire, accompagné d'un passage de texte visible et accolé au champ permettant de comprendre la nature de la saisie attendue ?

    Nouveau test 11.1.4

    Test 11.1.4 : Chaque champ de formulaire ayant une étiquette dont le contenu n'est pas visible ou à proximité (masqué, aria-label, aria-labelledby), vérifie-t-il une de ses conditions ?

    • le champ de formulaire possède un attribut title dont le contenu permet de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue

    Mise(s) à jour

    • le 06/04/2019 suite à proposition DINSIC le 28/01/2019 - 11:48

    giuseppe.rosa

    Je ne comprends pas les modifications apportées :
    1- Je pensais que le cas d'utilisation était lorsque le contexte de la page permettrait de comprendre ce qui est attendu dans le champ, avec pour les utilisateurs d'écran l'élément aria le permettrait de le comprendre également et par conséquent ce critère viserait les utilisateurs de zoom numérique. Par conséquent qu'il y ait ou non un label avec un teste masqué ne changerait pas le besoin.
    2- S'il y a une balise label visuellement masqué : s'il s'agit du masquage type left:-10000px ou class="sr-only" type bootstrap, pourquoi indiquer aria-label ou aria-labelledby et pas id/for ?

    • Pas d'accord 0 Pas d'accord

    giuseppe.rosa

    S'il s'agit d'indiquer qu'un texte adjacent peut être nécessaire, peut-être qu'il faudrait modifier la formulation :
    Test 11.1.4 : Chaque champ de formulaire qui utilise une balise dont le contenu est visuellement masqué, si un texte visible et accolé au champ est nécessaire pour en comprendre la nature de la saisie attendue, un attribut aria-labelledby doit référencé ce passage de texte.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    l'objectif de ce test est de s'assurer que lorsque le nom accessible du champ restitué aux aides techniques n'est pas visible (label non visible, aria-label ou texte associé via aria-labelledby non visible ou distant du champ) il y a bien un texte visible à coté du champ pouvant permettre de comprendre la nature de la saisie attendue

    • Pas d'accord 0 Pas d'accord

    s.noel

    Bonjour,
    Je trouve la formulation difficile a comprendre, ne faudrait-il pas rajouter un "Pour" devant le "chaque champ..." ? :
    "Pour chaque champ de formulaire utilisant une balise dont le contenu est visuellement masqué, un attribut aria-label ou aria-labelledby est-il, si nécessaire, accompagné d'un passage de texte visible et accolé au champ permettant de comprendre la nature de la saisie attendue ?"

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    Suite aux différents retours nous envisageons une évolution de la formulation de ce test de la manière suivante :

    Test 11.1.4 : Chaque champ de formulaire ayant une étiquette dont le contenu n'est pas visible ou à proximité ( masqué, aria-label, aria-labelledby), vérifie-t-il une de ses conditions ?

    • le champ de formulaire possède un attribut title ou placeholder dont le contenu permet de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte qui devient visible à la prise de focus permettant de comprendre la nature de la saisie attendue,
    • le champ de formulaire est accompagné d'un passage de texte visible accolé au champ permettant de comprendre la nature de la saisie attendue
    • Pas d'accord 0 Pas d'accord

    juliemoynat

    Pour l'usage du placeholder, n'y aurait-il pas une note à ajouter quant à sa longueur et donc sa visibilité dans le champ ? En effet, un placeholder un peu long peut être tronqué visuellement sur un écran de smartphone à 320px par exemple ou lorsqu'on agrandit le texte. Ainsi, l'alternative visuelle ne serait pas complète et ne permettrait pas forcément de comprendre ce qu'il faut saisir dans le champ.

    • Pas d'accord 0 Pas d'accord

    Annecav

    Ne devrait-on pas mettre un lien sur "masqué" pour expliquer qu'on parle bien d'une étiquette existante mais non visible (et pas d'une étiquette en display:none par exemple) ?

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour

    @juliemoynat suite à de nouvelles réflexions il semble plus pertinent de ne pas inclure la possibilité d'utiliser le placeholder car au délà des problèmes que vous signalez celui ci est masqué lors de la saisie ce qui va à l'encontre du critère WCAG demandant justement à ce qui l'étiquette soit visible

    @Annecav une entrée de glossaire pourrait effectivement être ajoutée. A noter tout de même, une étiquette type label for en display none serait également non conforme à ce test puisqu'elle n'est pas visible (elle serait également non conforme au regard du critère 10.13 puisqu'elle ne serai pas restitué aux lecteurs d'écran alors qu'elle devrait l'être)

    • Pas d'accord 0 Pas d'accord

    Annecav

    @DINSIC c'était bien le sens de mon propos !

    • Pas d'accord 0 Pas d'accord

    juliemoynat

    Bonjour @DINSIC,
    Merci pour le retour.
    Qu'en est-il de l'attribut title dans ce cas ? En effet, il n'apparaît qu'à la souris ; ce qui limite beaucoup sa visibilité : non visible au clavier ou sur écran tactile.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour @juliemoynat, bien que l'attribut title présente effectivement les défauts dont vous faites mention cette solution fait actuellement partie des techniques considérées comme conforme (cf H65), le RGAA ne peut donc invalider son utilisation.

    • Pas d'accord 0 Pas d'accord

    abatifol

    Bonjour @DINSIC,

    Ce qui me dérange pour la compréhension de ce test, c'est qu'il n'ait pas spécifié s'il faut que le contenu de l'attribut title, du placeholder ou du passage de texte soit identique ou reprenne au moins le nom accessible de l'étiquette non-visible.

    Pourriez-vous me donner quelques précisions à ce sujet.

    Merci d'avance.

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour, le "nom accessible" devra effectivement reprendre au moins l'étiquette visible au regard du critère 2.5.3 "label in name" des WCAG 2.1. Ce point sera pris en compte lors des prochaines propositions concernant ce nouveau critère

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour la proposition initiale a été mise à jour

    • Pas d'accord 0 Pas d'accord

  • Proposition DINSIC | 27/11/2018 - 08:21

    Suppression du test 11.1.5

    Raisons de la suppression du test 11.1.5

    Nous suggérons la suppression de ce test du RGAA en raison des points suivant :

    • aucune technique WCAG correspondante à ce test
    • placeholder ne fait pas partie du calcul du nom accessible selon la spécification accname 1.1
    • Les résultats de restitution seront dépendant de la base de référence utilisée
    • Ce point est déjà couvert via la pertinence de l'étiquette (critère 11.2) pour les cas où le placeholder serait non pertinent et restituté comme nom accessible

    Ancien test 11.1.5 (supprimé)

    Test 11.1.5 : Chaque champ de formulaire qui utilise un attribut title comme étiquette, vérifie-t-il une de ces conditions ?

    • L'attribut placeholder est absent.
    • L'attribut placeholder est identique à l'attribut title.

    giuseppe.rosa

    Remarque : sous NVDA si on a un title + placeholder :
    * avec un placeholder différent du title = restitution dans l'ordre de Placeholder + title
    * avec un placeholser identique au title = une seule restitution

    • Pas d'accord 0 Pas d'accord

    giuseppe.rosa

    A priori la précision serait conservé au niveau du glossaire.

    • Pas d'accord 0 Pas d'accord

    amaniez

    Bonjour,

    lI semble que l'attribut placeholder ait été réintroduit dans le calcul du nom accessible : https://w3c.github.io/html-aam/#a-1-change-log

    La suppression est-elle toujours maintenue ? des tests supplémentaires seront-ils réecrits ?

    • Pas d'accord 0 Pas d'accord

    DINSIC

    Bonjour,

    l'attribut placeholder utilisé seul comme solution pour associer une étiquette pertinente serait conforme dans les conditions suivantes :

    • si il est accompagné d'un texte servant d'étiquette pertinente qui deviendrait visible à la prise de focus
    • si il est accompagné d'un texte visible en permanence accolé au champ servant d'étiquette pertinente .

    Il faudrait par ailleurs que le placeholder reprennent au moins ce texte de manière à être conforme au critère de succès label in name

    Enfin cela reste soumis au support actuel de l'attribut placeholder. Nous allons effectuer des tests en ce sens.

    • 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