RGAA 3, vous aussi participez à l'appel à commentaires !

Le , par Aurélien Levy - Accessibilité

Avertissement : cet article a été publié en 2014. Son contenu n'est peut-être plus d'actualité.

Comme récemment indiqué par mon cher collègue Eric Gateau, nous avons d’ores et déjà commencé à anticiper le RGAA 3.0 pour certains de nos clients.

Ce travail nous a donné l’occasion de nous pencher encore un peu plus en détail sur la version bêta du référentiel. Je voudrais aujourd’hui prendre un moment pour vous montrer l’importance que peut avoir pour vous le fait de participer à cet appel à commentaire qui est ouvert jusqu’au 31 octobre.

Pour vous convaincre de l’intérêt de participer je ne vais pas répéter ce qui a été déjà si bien dit par Olivier Nourry dans son article “3 bonnes raisons de commenter le RGAA 3 beta”, mais je vais plutôt essayer de vous montrer que le RGAA 3.0 beta a réellement besoin d’être relu, même si il a été conçu à partir d’une excellente base, le référentiel Accessiweb HTML5.

Pour illustrer mes propos je vais me servir du critère 11.10 qui nous dit : Dans chaque formulaire, le contrôle de saisie est-il utilisé de manière pertinente ?.

Tout d’abord je vous invite à aller prendre connaissance du test 11.10 sur le RGAA 3 beta. Il est un peu long puisqu’il contient 8 sous tests, et il concerne l’indication préalable de la présence de champ obligatoires, des formats et types de données requises ainsi que de la restitution des erreurs de saisie.

Ce test est pris en exemple pour montrer ce qu’il est possible de rencontrer sur cette version beta et qu’il est nécessaire de corriger pour permettre une meilleure évaluation par les experts qui utiliseront ce référentiel et surtout une meilleure implémentation des solutions pour les utilisateurs. Dans le cas contraire, l’appropriation et le déploiement du RGAA 3 risqueraient d’être bien moindre à cause des risques de mauvaise interprétation ou de mauvaise compréhension des tests.

C’est pourquoi ci-après, je vous présente dans un premier temps les remarques formelles, puis les problèmes plus fondamentaux pour ensuite proposer une réécriture de ce test qui lèverait les problèmes rencontrés.

Quelques remarques de pure forme

  • L’ensemble des tests parle de propriétés ARIA, il nous semblerait préférable de parler d’attribut, puisque ce terme plus générique regroupe à la fois les états et les propriétés ARIA et cela évite la confusion avec les propriétés d’un sélecteur CSS.
  • Les tests 11.10.1 et 11.10.4 parlent de “balise attribut label” il s’agit de balises
  • Les tests 11.10.1, 11.10.4 et 11.10.7 comportent une condition qui indique dans l’étiquette (…, texte lié via la propriété ARIA aria-labelledby ). Or, si ce texte est lié via aria-labelledby il n’a pas besoin d’être dans l’étiquette (et l’usage d’aria-labelledby est alors identique à la condition L’indication de champ obligatoire est indiquée par un passage de texte lié par l’attribut ARIA aria-describedby
  • Une indication de quelque chose (erreurs, caractère obligatoire) “n’utilise” pas l’attribut X ou Y pour le faire, elle est “réalisée grâce à” l’attribut X ou Y.
  • Enfin le test 11.10.5 propose de signaler visuellement la présence d’une erreur par un passage de texte et le 11.10.2 par une indication visuelle explicite. Il nous semble donc préférable de parler “d’indication visible explicite” pour couvrir à la fois le texte et la possibilité de le faire via une icône par exemple.

Les problèmes de fond

  • Les tests 11.10.1, 11.10.4 et 11.10.7 présentent une condition par un passage de texte avant le champ de formulaire. Cette condition implique donc d’avoir obligatoirement le texte AVANT le champ. Or, dans certains cas notamment les cases à cocher ou les boutons radios le texte associé à un champ se trouve logiquement APRÈS le champ.
  • Qu’il soit AVANT ou APRÈS, il faut dans tout les cas que ce texte soit associé correctement au champ ce qui n’est pas le cas si on se contente de cette condition.
  • L’indication préalable du caractère obligatoire d’un champ, de son format de saisie ou de la présence d’erreur doit également se faire pour TOUS (handicap cognitif, navigation à la voix, etc). Il n’est donc pas possible d’utiliser uniquement des propriétés ARIA qui produisent un effet uniquement pour les utilisateurs de lecteurs d’écrans gérant ARIA. Ce cas à bien été pris en compte via 11.10.2 et 11.10.5 mais il est fait usage d’un texte AVANT le champ de formulaire au lieu de demander qu’il soit simplement associé au champ (dans étiquette ou via texte associé). De plus cette situation a été oubliée pour le cas des formats / types de saisies (à noter, le RGAA 3.0 bêta ne précise pas si le title est une solution utilisable pour ces cas précis mais nous aurions tendance à penser que non) .
  • Enfin, le test 11.10.4 ne prend pas en charge l’utilisation de l’attribut ARIA aria-invalid pour signaler la présence d’une erreur comme solution possible (à notre connaissance il est compatible avec la base de référence utilisé par le RGAA)

Ma tentative de réécriture des tests 11.10

Voici donc, en tenant compte de l’ensemble des remarques et problèmes, ma proposition de réécriture du critère 11.10.

Test 11.10.1 : Pour chaque formulaire, les indications de champs obligatoires vérifient-elles une de ces conditions ?

  • L’indication de champ obligatoire est indiquée via un attribut required
  • L’indication de champ obligatoire est indiquée via l’attribut ARIA aria-required
  • L’indication de champ obligatoire est indiquée dans l’étiquette (balise label, attribut title, attribut aria-label)
  • L’indication de champ obligatoire est indiquée par un passage de texte lié par l’attribut ARIA aria-describedby ou aria-labelledby

Test 11.10.2 : Chaque indication de champ obligatoire réalisé grâce à l’attribut required, les attributs ARIA aria-label ou aria-required doit être accompagnée d’une indication visible explicite dans l’étiquette (balise label) ou dans un passage de texte lié au champ par l’attribut ARIA aria-describedby ou aria-labelledby, cette règle est-elle respectée ?

Test 11.10.3 : Chaque indication de champ obligatoire réalisé grâce à un passage de texte lié par l’attribut ARIA aria-describedby ou aria-labelledby vérifie-t-elle ces conditions ?

  • Le passage de texte est identifié via un attribut Id
  • La valeur de l’attribut Id est unique
  • La valeur de l’attribut ARIA aria-describedby ou aria-labelledby est égale à la valeur de l’attribut Id

Test 11.10.4 : Pour chaque formulaire, les erreurs de saisie vérifient-elle une de ces conditions ?

  • L’erreur de saisie est indiquée dans l’étiquette (balise label, attribut title, attribut ARIA aria-label)
  • Le champ de formulaire possède un type qui produit de manière automatique un message d’erreur de saisie
  • L’erreur de saisie est indiquée via l’attribut ARIA aria-invalid
  • L’erreur de saisie est indiquée par un passage de texte lié par l’attribut ARIA aria-describedby ou aria-labelledby

Test 11.10.5 : Chaque indication d’erreur de saisie réalisée grâce à l’attribut ARIA aria-label ou aria-invalid doit être accompagnée d’une indication visible explicite dans l’étiquette (balise label) ou dans un passage de texte lié au champ par l’attribut ARIA aria-describedby ou aria-labelledby, cette règle est-elle respectée ?

Test 11.10.6 : Chaque indication d’erreur de saisie réalisée grâce un passage de texte lié par l’attribut ARIA aria-describedby ou aria-labelledby vérifie-t-elle ces conditions ?

  • Le passage de texte est identifié via un attribut Id
  • La valeur de l’attribut Id est unique
  • La valeur de l’attribut ARIA aria-describedby ou aria-labelledby est égale à la valeur de l’attribut Id

Test 11.10.7 : Pour chaque formulaire, les indications sur le type de donnée et/ou de format des champs obligatoires vérifie-t-elle un de ces conditions ?

  • L’indication du type de donnée et/ou de format est indiquée dans l’étiquette (balise label, attribut title, attribut ARIA aria-label)
  • L’indication du type de donnée et/ou de format est indiquée par un texte lié par l’attribut ARIA aria-describedby ou aria-labelledby

Test 11.10.8 : Chaque indication du type de donnée et/ou de format réalisée grâce à l’attribut ARIA aria-label doit être accompagnée d’une indication visible explicite dans l’étiquette (balise label) ou dans un passage de texte lié au champ par l’attribut ARIA aria-describedby ou aria-labelledby, cette règle est-elle respectée ?

Test 11.10.9 : Chaque indication de type de donnée et/ou de format réalisé grâce à un passage de texte lié par l’attribut ARIA aria-describedby ou aria-labelledby, vérifie-t-elle ces conditions ?

  • Le passage de texte est identifié via un attribut Id
  • La valeur de l’attribut Id est unique
  • La valeur de l’attribut ARIA aria-describedby ou aria-labelledby, est égale à la valeur de l’attribut Id

Conclusion : participez à l’appel à commentaire

Le critère 11.10 pris en exemple ici montre bien que cette version bêta nécessite encore d’être améliorée et nous allons bien sûr faire remonter l’information via le formulaire mis à disposition pour l’appel à commentaire. Il est logique qu’une version bêta contiennent des problèmes. C’est pourquoi, que vous soyez développeur, testeur ou utilisateur, il est important pour vous de participer et de remonter vos remarques. Cela devrait permettre de minimiser les risques ultérieurs, lorsque le référentiel devra être appliqué.