Comme chaque semestre, le W3C vient de publier une mise à jour des WCAG 2.0 (Web Content Accessibility Guidelines, version 2). Plus précisément, il s’agit d’une mise à jour des documents « Understanding WCAG 2.0 » et « Techniques for WCAG 2.0« . Le document central, celui qui décrit les critères de succès dans l’absolu, est en effet stable, car agnostique du point de vue des technologies. Ce sont les documents d’accompagnement qui sont mis à jour, pour rester en phase avec les évolutions technologiques.
Ceci a bien évidemment une incidence sur les référentiels AccessiWeb et RGAA, qui sont des méthodes de vérification de la conformité aux WCAG 2.0.
Note préliminaire: suite à échange avec des confrères, il apparaît qu’il y a une ambiguïté importante, que je vais lever illico. Cet article ne reflète que mes réflexions personnelles, qui n’engagent donc personne d’autre que moi, sur la façon d’accueillir cette mise à jour. Rien ne dit que les éléments décrits ci-dessous auront une traduction concrète dans les référentiels français, que ce soit AccessiWeb ou RGAA, quelqu’en soit la version. En l’occurrence, je ne suis qu’un praticien parmi d’autres, qui essaie d’anticiper un changement potentiel dans ses outils de travail. S’il s’avère que l’un ou l’autre de ces changements n’est pas entériné (ce qui est très possible), mais que je juge qu’il se justifie, charge à moi de le défendre le cas échéant. Je publie ces réflexions afin de les partager et les confronter à l’avis de mes confrères. Fin de la note!
Pourquoi et comment?
Si vous connaissez un peu le sujet, vous savez qu’AccessiWeb a une procédure de mise à jour qui lui permet de suivre le mouvement. Mais le RGAA? Ce n’est pas le même document depuis 2009?
Et bien si. Du coup, effectivement, toutes les mises à jour qui ont été publiées depuis n’ont rien changé au RGAA depuis sa dernière version publique, la 2.2.1. Mais voici deux infos pas forcément connues de tout le monde.
D’abord, le RGAA propose, via son document d’accompagnement, une procédure de dérogation (§5.5). Comme les exemples fournis décrivent uniquement des raisons d’échapper à l’obligation de conformité, on pense trop souvent que c’est son seul objet. Mais elle peut aussi servir à justifier des initiatives techniques. Comme par exemple utiliser des fonctionnalités du HTML5 ou d’ARIA pour rendre un contenu plus accessible, en s’affranchissant des limites du HTML4 auquel se cantonne le RGAA. Bien sûr, il faut défendre ces choix; mais si vous vous reposez sur une source fiable (comme par exemple, les WCAG, ou… AccessiWeb), ça ne sera pas très difficile.
Ensuite, comme indiqué sur le site officiel, le RGAA est en cours de refonte. Bon, j’avoue, je n’ai aucun mérite à être courant. Je suis en effet dans ce chantier jusqu’au cou, puisque mon employeur fait partie du groupement qui a remporté ce marché. Si vous avez lu l’annonce sur le site du RGAA, ou si vous avez participé à la consultation interne au Groupe de Travail AccessiWeb, vous savez également que ce qui s’appellera le RGAA 3 sera une copie quasi conforme de l’actuel référentiel AccessiWeb HTML5/ARIA, modulo des ajustements détectés entretemps. Si tout se passe comme prévu, d’ici fin 2014 le RGAA 3 sera le nouveau référentiel officiel des administrations.
Donc en résumé, que vous soyez en train de fignoler votre déclaration de conformité sur base RGAA 2.2.1, ou que vous planifiiez des travaux en anticipant sur la sortie du RGAA 3, ces modifications peuvent vous intéresser.
Quelles sont ces modifications?
Les modifications sont de trois types:
- ajout (ou retrait) de techniques ARIA
- généralisation de techniques jusque-là réservées au HTML ou à CSS
- toilettage (techniques redondantes ou contestées)
Les chapitres suivants les décrivent en détail.
Expliciter les liens avec aria-label
et aria-labelledby
Les techniques ARIA7 et ARIA8 décrivent comment rendre des liens plus explicites en utilisant les attributs aria-label
ou aria-labelledby
.
Pour nos référentiels, cela aurait pour impact de rajouter 2 façons possibles de fournir un contexte de lien, pour satisfaire au critère 6.1 (niveau A): Chaque lien est-il explicite?
On notera toutefois que les exemples décrivent des façons de complémenter des techniques déjà connues, telles que la présence d’un titre et l’inclusion à un paragraphe. Cela paraît en effet raisonnable, sachant que les navigateurs et technologies d’assistance un peu anciens risquent de ne pas supporter ces attributs.
Modification concernant aria-required
Le critère de succès WCAG 3.3.2 « Étiquettes ou instructions« incite les auteurs à rendre les champs de formulaires explicites, incluant le signalement de ceux qui sont obligatoires. Jusqu’à présent, il était recommandé (entre autres possibilités) de combiner une étiquette explicite (G131: « Providing Descriptive Labels« ) avec un attribut aria-required
(technique ARIA2) pour signaler un tel champ. Dans cette mise à jour, la technique ARIA2 est supprimée de la liste des techniques suffisantes combinables à G131. Cela paraît un peu étonnant à première vue, et ressemble à un retour en arrière. Je n’ai pas trouvé dans le système de suivi des anomalies du WAI de justification à ce changement, voici donc mon interprétation: si la technique G131 est appliquée (et donc que le caractère obligatoire du champ est mentionné via son étiquette), la technique ARIA2 est redondante. Il n’y a donc pas lieu d’inciter à l’appliquer pour le cas présent. En revanche elle reste dans la liste des techniques suffisantes pour satisfaire le critère de succès 3.3.3 « Suggestion après une erreur ».
Pour AccessiWeb cela impliquerait que le Test 11.10.1 ne pourrait plus être satisfait par la seule condition « L’indication de champ obligatoire est indiquée via la propriété ARIA aria-required ».
Alternatives aux contenus multimédia via la balise <object>
La technique H27 (version en cache; en anglais) a été supprimée. Cette technique permettait de fournir une alternative aux médias non-textuels servis via l’élément OBJECT, en y incluant l’alternative, selon le principe des poupées russes. Il s’avère qu’elle est redondante avec la technique H53 qui dit plus ou moins la même chose.
[ajouté suite à signalement par Aurélien Lévy sur Twitter:] Par ailleurs H53 évolue pour préciser qu’une alternative accessible à l’objet doit être présente, et qu’elle peut se trouver à l’intérieur de la balise uniquement dans le cas où l’objet lui-même est également accessible. Dans le cas contraire elle doit être placée en dehors de l’objet. Ceci permet de couvrir le cas où la technologie utilisée via l’objet (en général, du Flash) n’est pas supportée par le navigateur (l’utilisateur a accès par défaut au contenu de la balise). Mais également le cas où la technologie est supportée (l’utilisateur n’a généralement pas accès au contenu de la balise), pour lequel l’alternative extérieure à l’objet lui est accessible.
Cela ne changerait pas le contenu des tests AccessiWeb, qui n’appliquent pas explicitement cette technique (même si elle est référencée par le critère 4.16).
Information aux utilisateurs sur le changement de contexte
La Failure F76 (version en cache; en anglais) documentait la situation où un changement de contexte lié à un changement de réglage utilisateur pouvait échapper à l’utilisateur, si l’information associée ne se trouvait pas là où l’utilisateur aurait pu s’y attendre (oui, c’est une phrase très alambiquée, mais j’ai essayé d’être aussi fidèle que possible au libellé d’origine). Apparemment cette failure a été considérée comme non avenue… peut-être parce qu’elle est incompréhensible! 😉 [clin d’œil].
Cela ne changerait pas les tests d’AccessiWeb, même si le critère 7.4 y fait référence. Idem pour RGAA 2.2.1, où le test 8.5 ne serait pas modifié. En effet, dans les deux cas, on y décrit ce qui fonctionne, pas ce qui ne fonctionnerait pas.
Généralisation de techniques liées à une technologie particulière
Il existe en fait 2 grandes familles de techniques WCAG: les « générales » (le code commence par un G) et celles liées à une technologie particulière (code commençant par H pour HTML, C pour CSS, FLASH pour… Flash, etc.).
Trois techniques spécifiques (H87, H92 et C26) ont été supprimées et remplacées respectivement par les techniques générales G204, G205 et G206. Cela ne changerait rien aux tests d’AccessiWeb et du RGAA, qui concernent le HTML, CSS et JavaScript, pour faire simple, considérant que ce qui est vrai pour le HTML et le CSS reste vrai si la règle est généralisée.
Mais il y aurait un impact pour la liste des critères applicables aux documents bureautiques en téléchargement (Word, 56 ko), qui accompagne le référentiel AccessiWeb. La technique G204 (ne pas interférer avec le reflow de l’agent utilisateur en cas de rétrécissement de la largeur de la zone de lecture) déborde le cadre du HTML (les navigateurs ont un système de reflow efficace tant que les largeurs de boites sont en taille relative). Pour le PDF, en revanche, il faudrait spécifier dans les options d’accessibilité que l’on autorise le reflow. Ceci pourrait donc constituer un critère à part entière (de niveau triple-A, mais tout de même).
Modification de la technique sur les titres de section
[ajouté suite à signalement par Aurélien Lévy sur Twitter]
Une modification dans l’énoncé de cette technique mentionne son utilité pour naviguer plus rapidement à l’intérieur d’une page. Par ailleurs elle est maintenant rattaché au critère de succès 2.4.10 « Section Headings« .
Ces modifications n’impacteraient ni AccessiWeb ni RGAA a priori.
Suppression de l’élément acronym
DE LA TECHNIQUE SUR LES abréviations
[ajouté suite à signalement par Aurélien Lévy sur Twitter]
L’élément ACRONYM
étant abandonné dans la spécification du HTML5, il est logique que les WCAG reflètent cette évolution. La technique 28 se limite donc désormais à l’usage d’ABBR
pour fournir le développé d’une abréviation comme d’un acronyme.
Cela ne changerait rien à AccessiWeb qui intègre déjà cette évolution. En revanche le test 10.10 du RGAA 2.2.1 deviendrait caduc.
Contrastes de couleurs des contenus graphiques
Enfin, une nouvelle recommandation avec le statut « advisory » (conseillé) fait son apparition. À l’instar du texte, les éléments graphiques de contenus tels que diagrammes, camemberts, courbes, etc. devraient satisfaire des exigences de contraste minimum. Pour l’instant cette technique n’est pas documentée donc on n’a pas encore d’instructions concrètes (je suis notamment curieux de savoir ce qui constituerait un « grand » ou « petit » élément graphique). Néanmoins ça reste une bonne idée de concevoir ses graphiques de manière à assurer un contraste confortable.
En conclusion
Cette mise à jour ne changera pas la face de l’accessibilité du Web. Elle entraîne cependant quelques petits ajustements que l’on peut d’ores et déjà anticiper.
[Édité le 23/09/2014] À partir du 23/09/2014 et jusqu’au 31 octobre 2014, la version beta du RGAA 3 est soumise aux commentaires du public. Pour des raisons techniques elle n’intégre pas ces changements (publiés une semaine auparavant sur le site des WCAG), mais l’appel à commentaires publics permettra de remonter ces modifications.
En attendant, n’hésitez pas à me faire part de vos observations, car j’ai peut-être oublié ou mal interprété certains points.