Accessibilité des champs de formulaires, une nouvelle technique ?
Par Fabrice Bonny le lundi 15 décembre 2008, 14:39 - Accessibilité - Lien permanent
Comment concilier accessibilité, conformité aux standards et design dans un formulaire ? Il est toujours difficile de concilier les contraintes visuelles du design et les contraintes techniques des standards et de l'accessibilité. C'est encore plus vrai sur un formulaire. Un des points les plus problématiques concerne la mise en place des indications concernant les champs à remplir. Quel champ est obligatoire, quel format est requis, etc ?
Une pratique courante consiste à ajouter une étoile derrière les champs qui doivent obligatoirement être renseignés. Cela se combine avec l'erreur courante de n'indiquer cette convention qu'après le formulaire. Pire encore dans le cas d'une synthèse vocale, cet « * » sera le plus souvent ignoré car en dehors du label.
Pour remédier à cela, une idée me trottait dans la tête depuis quelques temps. Profitant de notre voyage commun en direction de Paris Web, j'ai demandé à Laurent Denis de faire quelques tests, entre autre sur Jaws. Bingo, ça marche ! Les deux parties du label complet sont bien lus.
Mais quelle est cette idée ?! Il s'agit tout simplement d'utiliser la possibilité d'imbriquer classiquement un élément de formulaire dans un label mais en écrivant les données complémentaires après ce champ mais à l'intérieur du label. Attention toutefois à bien indiquer le champ concerné grâce à l'attribut for, même si le label est implicitement lié au champ. Je livre un exemple minimaliste à vos tests, critiques et commentaires.
Mise à jour : ajout d'un title sur les *
Commentaires
Simple et conforme, il fallait y penser. Hop dans les "bookmarks".
Rhoooo ! Le bougre de Laurent :-D
J'ai une belle histoire qui a eue une très légère/mineure répercussion sur un sujet trainant en d'autres lieux et en une autre époque (pas si lointaine)...
Au sujet des labels explicites, implicites et implicito-explicites...
le 16/04/2008 fut commit :
Sauf erreur, quand Dieu écrivit HTML4.01 il y a un bail, il commit diverses bavures inévitables vu que l'esprit du temps était alors surtout au compromis entre les différentes implémentations de l'industrie d'alors et qu'il fallait parfois en légitimer plusieurs à la fois. Sans compter que tout cela était encore très neuf dans Son esprit et qu'il n'avait pas bien mesuré toutes les implications de chaque choix de Sa Sainte Spécification en termes de développement d'aides techniques, d'UA, tout ça... (le premier qui prononce le mot "accesskey ?" a une baffe).
Mais au 8e jour, quand les marchands du Temple commencèrent à être un peu plus rigoureux, ils firent leurs choix sans états d'âmes dans le Saint patrimoine structurel. C'est comme cela que Freedom Scientific a déclaré un beau jour que les labels implicites, bah non, c'était plus bien du tout parce que ça lui compliquait la vie. C'est là que tout a commencé, il y a 3 ou 4 ans, vers Jaws 7.0 si ma mémoire est bonne.
Partant de là, comme personne ne se concertait beaucoup plus qu'aux tous premiers temps, il fallut bien faire avec. Et tant qu'à faire, en profiter pour que les Ecritures gagnent un peu en simplicité et perdre un chouïa d'ésotérisme mystique. Quitte à faire une victime peut-être innocente, peut-être pas, avec les labels explicito-implicites qui mettent le contrôle dans le label mais aussi un FOR, et sont en effet un cas curieux, pas prévu par les exemples évidemment (qui irait mettre exprès un exemple vicieux dans une spec, hum ?).
Bref,
- explicites: bon
- implicites: mal
- implicito-explicites... tassons tous ensemble un petit peu plus le petit tas honteux à présent glissé sous le tapis, si vous le voulez bien ?
Par contre, le label qui contient l'astérisque est pas placé super logiquement : on passe sur le vrai label, puis le champ, puis l'astérique, donc on revient en arrière sur le champ, hop on revient sur l'astérisque déjà survolé, bref pour un non voyant, j'imagine que ça doit pas être super pratique.
Rémi > Pour un non voyant pas pratique ?
J'ai posé la même question à Fabrice notamment sur le déroulement de la lecture : Jaws lit : "Nom" puis "étoile", en effet input n'est pas lu .. donc aucun problème. Et puis de cette façon il comprend que le champ est obligatoire.
Harmen, le bougre de Laurent m'a bien indiqué que mon idée était sujette à discussion à cause du côté implicite des labels. C'est pour cela que mon exemple est à la fois implicite, les input sont dans les labels, et explicite, les labels ont un attribut for liés aux inputs.
Rémi, mon idée était justement de trouver une solution conforme à une demande récurrente de clients qui veulent avoir ce rendu visuel. C'est ergonomiquement discutable, certes, mais une réalité du marché. Les solutions actuelles sont une catastrophe en terme d'accessibilité. Ma solution, après l'ajout de l'abréviation sur l'astérisque, donne le rendu suivant dans Jaws : « Nom obligatoire », « Prénom obligatoire », etc. Le champ n'est lu qu'après le label, même si celui-ci est en deux parties.
Oooh, de mon coté j'ai été assez naïf pour croire jusqu'à une époque toute aussi récente qu'il suffisait d'un attribut "for" pour déclarer le label explicitement (relation plus forte que le simple positionnement dans l'arbre du DOM des labels implicitement simples). Et donc que le cas "implicito-explicites" (ou inversement) n'existait pas (quel naïf, n'est ce pas !). Et pour être honnête, je n'ai toujours pas entrevu la difficulté pour les éditeurs d'UA de les implémenter.
Donc formellement, je n'ai rien contre au contraire (ayant moi même déjà pratiqué l'implicito-explicite), mais pratiquement et à défaut de référence sur le sujet, je ne sais vraiment plus à quel saint me vouer !
**/Légende urbaine ou pas ???/** :)
bonjour,
petit retour : sous NVDA 0.6p2, les labels implicito-explicites sont lus mais pour entendre "*", il faut activer dans les préférences "Dire toutes les ponctuations", sinon tout est ok !
PS : est la même choses avec du CSS pour pousser "*" après le champ, non ?
Sanvin, tout d'abord merci beaucoup pour ce retour d'information. NVDA ne lit donc pas « obligatoire » après mon ajout d'un abbr dans le code ? Quant à la possibilité de faire ça en CSS, c'est une évidence mais je cherchais une solution plus universelle et moins sujette aux problèmes de compatibilité.
oui, "*" n'étant pas lu, abbr ne l'est pas non plus !
attention : je ne suis pas un spécialiste de NVDA,
A CONFIRMER !
Sanvin, il est justement intéressant de voir ce que donne une solution technique avec un outil dans sa configuration d'origine. Les personnes déficientes ne sont pas plus geek que les autres et ne savent pas forcément faire les réglages nécessaires.
Quid du "au format jj/mm/aaaa" qui se trouve après le input? quelqu'un qui utilise unlecteur d'écran doit revenir en arrière pour le remplir comme il faut?
Bosquet, justement non. Tout l'intérêt de la technique que je propose est que l'ensemble du label (les deux parties) est lu avant d'arriver au champ à remplir. La synthèse lira donc « date de naissance au format jj/mm/aaaa » en une seule fois puis le curseur tombera dans la zone de saisie.