Au début de cette année, pour la toute première fois, le World Wide Web Consortium (W3C) a proposé de supprimer un critère de conformité des WCAG 2. Le critère de conformité 4.1.1 « Analyse syntaxique » garantit que les pages rédigées dans des langages de balisage tels que le HTML et le SVG sont écrites de manière à permettre aux navigateurs et aux technologies d’assistance de les comprendre de manière cohérente. Voyons pourquoi ce critère a été supprimé, comment le W3C prévoit de mettre en œuvre ce changement et quel en est l'impact sur les produits d'Deque .
Pourquoi la section 4.1.1 « Analyse syntaxique » a été supprimée
Le texte du critère de succès 4.1.1 « Analyse syntaxique » est le suivant :
4.1.1 Analyse syntaxique : dans les contenus mis en œuvre à l'aide de langages de balisage, les éléments comportent des balises d'ouverture et de fermeture complètes, sont imbriqués conformément à leurs spécifications, ne contiennent pas d'attributs en double et tous les identifiants sont uniques, sauf lorsque les spécifications autorisent ces particularités. (Niveau A)
Remarque : les balises d'ouverture et de fermeture auxquelles il manque un caractère essentiel dans leur structure, comme un crochet angulaire de fermeture ou un guillemet de valeur d'attribut non apparié, ne sont pas complètes.
Il s’agissait là d’une exigence importante avant l’arrivée du HTML 5. Les versions antérieures du HTML ne précisaient pas comment traiter les balises non conformes. Ces balises pouvaient fonctionner d’une certaine manière dans les navigateurs d’aujourd’hui, puis différemment demain. Cela avait un impact particulièrement important pour les personnes qui utilisaient des technologies d’assistance. Ainsi, lorsque le HTML 5 a normalisé la manière dont les navigateurs devaient traiter les balises non conformes, il a garanti que si une balise non conforme fonctionnait aujourd’hui, elle fonctionnerait également avec tous les futurs navigateurs.
Peu de testeurs d’accessibilité appliquent la section 4.1.1 « Analyse syntaxique » telle qu’elle a été initialement conçue. Axe-core, par exemple, ne vérifie que la présence d’identifiants en double, car ceux-ci peuvent entraîner des libellés et des propriétés incorrects pour les technologies d’assistance. Depuis la version 3.1 de axe-core , nous classons les identifiants en double qui ne peuvent pas avoir d’impact sur l’accessibilité comme un problème mineur. Mais en réalité, les identifiants en double sont un indicateur d’un problème d’accessibilité ; ils ne constituent pas un problème d’accessibilité en soi. Les véritables problèmes d’accessibilité actuellement signalés sous la section 4.1.1. « Analyse syntaxique » sont des problèmes déjà couverts par différents critères des WCAG.
Mise en œuvre dans le cadre des WCAG et ailleurs
La suppression d'un critère des WCAG est un problème délicat. Les WCAG 2.0 et 2.1 sont des normes internationales qui ont été transposées dans la législation et la réglementation. Il est difficile de les modifier, ce qui implique de longues périodes de transition. Le W3C a donc opté pour une stratégie à deux volets :
- Dans la version 2.2 des WCAG ( qui n'est pas encore finalisée), le critère 4.1.1 « Analyse syntaxique » sera supprimé. Il n'est plus obligatoire, car il ne fait plus partie de la norme.
- Pour les versions 2.1 et 2.0 des WCAG (qui sont désormais définitives), une note sera ajoutée au critère 4.1.1 « Analyse syntaxique ». Cette note indiquera que le critère 4.1.1 est toujours respecté pour les contenus HTML et XML.
Cette note que le W3C prévoit d’ajouter aux WCAG 2.0 et 2.1 est en quelque sorte une astuce, dans la mesure où elle ne modifie pas l’exigence proprement dite. Le critère reste le même qu’auparavant. La seule chose qui change, c’est une intention claire quant à la manière dont le W3C estime que ce critère doit être interprété. Cela permet à tous ceux qui utilisent aujourd’hui les WCAG 2.0 et 2.1 de dire « vous voyez, le W3C dit que cela est conforme », même si cette note ne figure pas dans les anciennes versions des WCAG qu’une organisation est tenue de respecter.
Y en aura-t-il d'autres ?
C'est un véritable triomphe pour l'accessibilité du Web que la technologie ait suffisamment progressé pour qu'un critère de succès ne soit plus nécessaire. Parallèlement, on peut se demander s'il existe d'autres aspects des WCAG qui pourraient devenir obsolètes grâce à l'amélioration des normes et des navigateurs. La bonne nouvelle, c'est que les navigateurs ont apporté toute une série d'autres améliorations notables.
De nos jours, tous les navigateurs prennent en charge le zoom, au lieu de se contenter de redimensionner la police comme c'était le cas en 2008. Plus récemment, les navigateurs ont commencé à bloquer la lecture automatique du son. Certains navigateurs proposent, dans leurs paramètres d'accessibilité, une bague de mise au point améliorée que les éditeurs de contenu ne peuvent pas désactiver. La détection automatique de la langue est également disponible dans certains navigateurs (mais elle est désactivée par défaut). Plusieurs navigateurs proposent désormais un mode « lecteur ». La liste est encore longue.
Ces efforts menés par les différents éditeurs de navigateurs sont louables, mais ils doivent faire l'objet d'une normalisation. Comme cela a été le cas pour l'analyse syntaxique, un code qui fonctionne dans un navigateur peut ne pas fonctionner dans d'autres navigateurs, voire dans la prochaine version de ce même navigateur. En l'absence d'une telle normalisation, il est peu probable que, malgré les nombreuses avancées, d'autres critères de conformité des WCAG 2 deviennent obsolètes au cours des prochaines années.
Règles obsolètes dans axe-core
Axe-core La version 4.8, prévue pour août 2023, inclura des modifications visant à tenir compte de cette mise à jour du W3C. Le document « Axe-core » comporte actuellement trois règles permettant de tester le critère de succès 4.1.1 « Analyse syntaxique ». Ces trois règles concernent toutes les identifiants en double.
Axe-core’s duplicate-id-aria Cette règle sera mentionnée sous critère 4.1.2 Nom, rôle, valeur. Cette règle vérifie que les identifiants utilisés dans ARIA et les libellés accessibles ne sont pas dupliqués. Il est important d’y prêter attention, car cela peut entraîner l’attribution d’un libellé ou d’une valeur erronée à certains contrôles. Étant donné qu’il ne s’agit pas nécessairement d’un problème d’accessibilité avéré, ces résultats seront signalés comme « à vérifier » plutôt que comme une infraction.
Le duplicate-id et duplicate-id-active Les règles vérifiant la présence d'identifiants (ID) sur les éléments pour lesquels l'absence d'un identifiant unique n'a aucune incidence sur l'accessibilité pratique de la page. Ces deux règles seront dépréciées. Cela signifie qu'elles seront désactivées par défaut et que, lors de la sortie d'axe-core e 5.0, elles seront supprimées. Ces règles ont reçu le “wcag2a-obsolete” balise destinée à tous ceux qui, pour des raisons de compatibilité ascendante, pourraient encore avoir besoin d'appliquer temporairement ces règles.
Lectures complémentaires
Vous souhaitez en savoir plus ? En février dernier, avant la décision concernant les WCAG 2.0 et 2.1, Christophe Strobbe a rédigé un excellent article intitulé « La vie difficile et la mort lamentable du critère de succès 4.1.1 ». Christophe a participé à la rédaction initiale du critère 4.1.1 « Analyse syntaxique » dans le cadre des WCAG 2.0, et c'est lui qui, l'année dernière, a soulevé la question qui a conduit à sa suppression.
