Les différences entre RGAA 3 beta et AccessiWeb HTML5/ARIA

Nous nous intéressons ici aux modifications issues de la première phase de consultation du RGAA.

Une première consultation via le Groupe de travail AccessiWeb (GTA)

Cette première consultation a été limitée aux membres du GTA qui connaissent sur le bout des doigts le référentiel AccessiWeb (dont le RGAA 3 beta est une copie modifiée ou fork dans le jargon libriste).

Je profite de l’occasion pour saluer la pertinence des remontées qui montre, à chaque consultation, toute la valeur de l’expérience accumulée par le GTA, ce qui en fait sans doute l’une des communautés de professionnels la plus pointue sur le domaine.

La consultation portait sur deux grands axes.

Valider les grandes orientations du référentiel

D’abord valider un certain nombre de choix faits par le groupe d’experts piloté par la DISIC pour encadrer la mise à jour. Pour l’essentiel il s’est agit d’avaliser les grandes orientations du référentiel AccessiWeb HTML5/ARIA comme la base de référence, la prise en charge de HTML5 et de WAI-ARIA, la suppression de l’exigence des alternatives systématiques à JavaScript par exemple.

L’ensemble de ces grandes orientations a été validé et, de ce point de vue, aucune différence avec AccessiWeb HTML5/ARIA n’est à signaler.

Néanmoins, deux questions n’ont pas obtenu un consensus suffisant et ont été arbitrées par la DISIC.

L’utilisation de texte caché par CSS et d’image en propriété de fond

Le critère 10.2 d’AccessiWeb imposait de vérifier que le contenu visible restait présent lorsque les feuilles de style CSS ou les images étaient désactivées.

De fait cela restreignait l’utilisation des textes cachés associés à des images de fond à des cas très particuliers (lorsque le texte pouvait être superposé sous l’image de fond par exemple).

Le nouveau critère 10.2 de RGAA supprime la condition « images désactivées » ce qui autorise dorénavant l’utilisation sans restriction de textes cachés associés à des images de fond.

Il a été pris en compte que l’usage de cette méthode, moins robuste, était généralisée par les bibliothèques et frameworks JavaScript notamment ce qui rendait une application très stricte complexe et généralement ignorée de l’état de l’art.

Néanmoins, un avertissement dans la note de glossaire sur les contenus visibles rappelle que cet usage peut poser des problèmes.

Passer l’obligation d’indiquer les ouvertures de nouvelles fenêtres au niveau triple A (AAA)

Si l’on s’en tient au jeu des correspondances WCAG, l’indication de l’ouverture de nouvelles fenêtres devrait être de niveau triple A (AAA). AccessiWeb, depuis la version 2.0, avait maintenu cette exigence au niveau simple A pour des raisons de compatibilité avec RGAA 2.2.

Le groupe d’experts de la DISIC souhaitait de son côté passer ce critère en triple A (AAA), conformément au critère de succès principal lié.

Faute de consensus lors de la consultation du GTA, la DISIC a arbitré en décidant de maintenir ce critère au niveau simple A, compte tenu de son niveau d’appropriation et du bénéfice utilisateur.

Il n’y a, en conclusion qu’une seule différence notable (le critère 10.2), entre AccessiWeb HTML5/ARIA et RGAA 3 du point de vue des grandes orientations et des choix effectués par le groupe d’experts de la DISIC.

Cela dénote une très grande robustesse de ce nouveau référentiel, en attente des résultats de l’appel à commentaires public.

L’amélioration continue n’est pas un mythe

Un sujet libre a permis, lors de cette consultation, de capitaliser sur les premières remontées de terrain du GTA dans l’exercice délicat de la mise en application du référentiel AccessiWeb HTML5/ARIA.

De ce point de vue, la récolte fut fructueuse puisque pas moins de 31 remarques et demandes d’amélioration ont été remontées, traitées et appliquées.

Beaucoup d’entre elles concernaient des reformulations ou des ajouts de bon sens, je me contenterai d’en citer ici quelques unes, parmi les plus remarquables.

Rôles navigation et search

D’abord sur la restriction, contre-productive, d’un rôle navigation unique dans la page et la restriction d’usage du rôle search qui ne pouvait être implémenté que sur le champ de recherche lui même (critère 12.10). Ces deux restrictions sont levées et c’est une excellente chose.

À noter que le rôle navigation est maintenant le sujet d’un test permettant d’en sanctionner les abus.

Obligation de rendre les liens d’accès rapides visibles au focus, au moins

Il y avait un véritable paradoxe à rendre obligatoire les liens d’accès rapide tout en tolérant qu’ils demeurent invisibles s’ils étaient correctement masqués. Ce paradoxe est résolu : ces liens devront obligatoirement être rendus visibles à la prise de focus au moins (critère 12.11)

Prise en charge de la propriété aria-label comme contexte de lien

Anticipant, en partie, sur la récente mise à jour des WCAG, le contexte de lien, permettant de rendre un lien explicite, a été étendu à la propriété aria-label (critère 6.1) via la définition de glossaire (Contexte du lien).

Il est fort probable, à ce sujet, que la propriété aria-labelledby suive le même chemin à l’issue de l’appel à commentaires public.

Refonte du test sur la conformité des motifs de conception WAI-ARIA

Une des très grandes originalités du référentiel AccessiWeb et, par voie de conséquence, du référentiel RGAA est la prise en charge de WAI-ARIA dans tous ses aspects, y compris le fait qu’un composant respecte le motif de conception WAI-ARIA lui correspondant.

Cette exigence, qui peut être mal comprise, est cruciale pour s’assurer de l’homogénéité des composants d’interface développés avec JavaScript quant à leurs interactions avec l’utilisateur.

C’est en même temps une problématique complexe, difficile à résumer via de simples tests.

La première rédaction du test sur AccessiWeb HTML5/ARIA (critère 7.1, test 7.1.6), si elle avait le mérite d’exister, était ambigüe et insuffisante.

Cela a donné lieu à l’une des discussions les plus ardues qu’il m’ait été donné de suivre depuis AccessiWeb 2.0 et de vérifier, une fois de plus, que la rigidité apparente des règles d’écriture était une arme absolue en termes de cohérence d’intitulé.

Le test a finalement été intégralement refondu, la nouvelle rédaction (test 7.1.3) est plus précise et, espérons le, plus claire.

Vous remarquerez, au passage, que c’est l’ensemble du critère 7.1 sur la compatibilité de Javascript avec l’accessibilité qui a été refondu.

Liste des principales modifications RGAA 3.0 beta

Nous avons vu en détail l’essentiel des différences remarquables entre AccessiWeb HTML5/ARIA et ce nouveau référentiel RGAA 3.0 beta, qui se révèle, à chaque nouvelle consultation d’une très grande robustesse, fruit de plus de deux années de travail, au sein du GTA, et maintenant, via l’appel à commentaires public, au travers de la communauté toute entière.

Je ne serais néanmoins pas complet sans vous donner la liste quasi-exhaustive des modifications (de fond) effectuées sur RGAA 3.0 par rapport à son illustre aîné.

Test 1.1.4 : Chaque image vectorielle (balise svg) vérifie-telle ces conditions ?

L’élément figure doit obligatoirement posséder un role="group".

Critère 6.1, 6.2, 6.3, 6.4

Ajout du support des liens images de type svg, exemple avec le critère 6.1 :

• Test 6.1.5 : Chaque lien vectoriel vérifie-t-il une de ces conditions (hors cas particuliers) ?
  • L’intitulé de lien seul permet d’en comprendre la fonction et la destination ;
  • Le contexte du lien permet d’en comprendre la fonction et la destination.

Test 10.13.3 : Dans chaque page Web, chaque texte caché qui utilise un attribut hidden vérifie-t-il une de ces conditions ?

Suppression du test de cohérence entre l’attribut hidden et l’état affiché ou visible du contenu.

Test 11.10.2 : Chaque indication de champ obligatoire qui utilise la propriété WAI-ARIA aria-label ou aria-required doit être accompagnée d’une indication visuelle explicite, cette règle est-elle respectée ?

Ajout (très important) de la propriété aria-required qui doit être obligatoirement associée à une indication visuelle. Je note au passage que ce test répond, au débotté, à la problématique de la suppression de cette technique WCAG pour l’identification des champs de formulaire requis.

[Critère 12.10 A] Dans chaque page web, les groupes de liens importants (menu, barre de navigation…) et la zone de contenu sont-ils identifiés sauf cas particulier ?

Ajout d’un cas particulier pour prendre en charge un site d’une page qui ne comporte pas de menu de navigation.

À vos plumes !

C’est tout. Vous me direz que le compte n’y est pas et vous aurez raison, les autres modifications sont essentiellement de la forme, des reformulations neutres ou des modifications de glossaire peu impactantes.

De notre côté, cette première partie du job est terminée. La vôtre débute : le référentiel doit passer l’épreuve du feu de l’appel à commentaires public avant d’être déclaré bon pour le service.

Je compte sur vous pour apporter votre pierre à cet outil méthodologique avec lequel nous allons vivre pour les années qui viennent.

Je précise, à toutes fins utiles, qu’à l’image de ce qui se fait avec AccessiWeb, tous les messages remontés recevront une réponse détaillée.

À vous de jouer…

P.S. : Pour celles et ceux qui seraient intéressé.e.s par la correspondance entre RGAA 2.2 et RGAA 3.0 beta, notez qu’une fonctionnalité (bouton « RGAA 2.2 », juste avant la liste des critères) vous permet d’afficher (ou masquer) les correspondances avec RGAA 2.2.