Très bien, le choix pour la catégorie de cette BP reste très similaire : "Navigation" ou "Structure et code" :-)
Voici la liste qu'on a actuellement, après 5 heures de taf et 7 itérations :
- Contenus
- Données personnelles
- E-Commerce
- Formulaires
- Identification et contact
- Images et médias
- Internationalisation
- Liens
- Navigation
- Newsletter
- Présentation
- Sécurité
- Serveur et performances
- Structure et code
Tout à fait : "code" en contient des similaires / Navigation est très pertinent aussi ... finalement on a l'embarras du choix ;-)
Je vote pour, puisque les risques sont liés à une mauvaise cible pour une ancre ou un label de formulaire pour aller sur le champ associé, grosso modo.
Posez un comm', sauvez une BP.
On discute, et finalement, je propose qu'on l'associe à la rubrique navigation (ancres, fonctionnement, plier déplier, etc...). Ce qui la sauverait.
Nous venons de travailler le rubriquage, nous n'arrivons pas à la relier à un enjeu utilisateur. C'est la seule sur 240. Elle est à part. Selon moi elle dépasse la mission d'Opquast, elle n'a pas sa place en tant que bonne pratique dans le référentiel. Allez-y tapez-moi dessus.
Oui, il faut la garder selon moi, et oui pour l’accessibilité. (après il y a peut-être d’autres bonnes raisons mais l’accessibilité me paraît largement suffisante comme raison dans ce cas)
OK, on vient de discuter avec Laurent, et on va la valider en candidate, ne serait-ce que parce que c'est l'une des seules (voire la dernière) qui va vraiment conduire à regarder la validité du code au moment de la recette.
C'est tellement un cas d'erreur courant qu'il me parait important de la garder. Il y a une réelle valeur ajoutée pour l'utilisateur (oui c'est très accessibilité) notamment sur les formulaires mais aussi sur les composants (show / hide etc) et c'est assez simple à vérifier, un petit coup de validateur W3C et hop.
J'ai très envie de proposer de la pousser en recommandation. Mais si vous me dites qu'elle va avoir des impacts vraiment méchants (bloquants) et fréquents en matière d'accessibilité, je suis à l'écoute.
En l’occurrence, oui, très accessibilité :)
Je m’interroge tout de même sur les risques en matière d’interopérabilité : un appel à un élément depuis l’extérieur (récupération d’une portion de DOM via AJAX par exemple) ciblant un identifiant, pas exemple. Mais le risque est très faible, je pense, puisque les scripts sont généralement testés plusieurs fois entre leur conception et leur livraison.
En fait, formulée comme ça, la bonne pratique ressemble « simplement » à l’erreur levée par le validateur du W3C — et ne reflète pas du tout l’intérêt pour l’utilisateur final. J’ai encore du mal à formuler quelque chose — il me manque un ou deux cafés à cette heure-ci — mais si on résume l’intérêt de cette vérification aux quelques exemples cités, on pourrait peut-être l’orienter sur le fonctionnement correct desdits motifs de conception. Et dans ce cas, la formulation actuelle deviendrait un moyen de vérification.
Qu’en dites-vous ?
Bien vu pour ces exemples. Une partie de la question, ici, est aussi de peser le risque que ce type d'erreur se produise : qu'est-ce qui est raisonnablement couvert par le recettage de base d'une page en production ? Qu'est-ce qui passe à travers (fréquemment, pour autant qu'on puisse en juger) ? je dirais, pour les cas à couvrir : les associations labels/champs, les associations headers/id dans les tableaux, les id en ARIA. On est très accessibilité-accessibilité, là (ce n'est pas un tort, mais une question de rôle de cette checklist ;-) )
Le premier impact auquel je pense concerne les ancres : laquelle est choisie si deux cibles avec le même identifiant existe ?
Et globalement, tous les composants requérant une association à un identifiant sont concernés :
- les labels associés à leur champs via l’attribut for, comme évoqué,
- les attributs de contrôle de formulaire sur les boutons (et notamment l’attribut form)
- les associations de cellules à leurs entêtes via l’attribut headers,
- les références à un élément tiers en guise de label ou description (via aira-labelledby ou aria-describedby , par exemple)
- les associations entre éléments dans les motifs de conception ARIA (par exemple via aria-controls).
Dans une moindre mesure :
- l’utilisation des identifiants pour les tests,
- l’utilisation des identifiants par des styles ou scripts utilisateurs.
Et il y en a probablement plein d’autres.
J’imagine que globalement, les navigateurs prennent le premier élément rencontré avec l’identifiant, mais je n’en suis pas certain.
Discussion avec Laurent Denis. Elle a notamment un impact majeur que dans les pages contenant des formulaires.
Quel est l'impact ?
Fonctionnement au clavier, composants, etc...
