24e séminaire AccessiWeb, du nouveau pour le RGAA et WCAG

Le 17 octobre 2017 dernier a eu lieu le 24^e séminaire AccessiWeb. Cela a permis de faire le point sur les nouveautés dans l’univers de l’accessibilité web, notamment côté RGAA (Référentiel Général d’Accessibilité pour les Administrations) et WCAG (Web Content Accessibility Guidelines) ; c’était très enrichissant. Je vous propose donc un compte-rendu de l’évènement.

Quelles nouveautés dans la version 2017 du RGAA 3.0 ?

Jean-Pierre Villain (Access42) nous a présenté les principales modifications dans le RGAA v3.2017 dont Access42 nous parle également sur son blog. J’ai notamment noté :

Ajout de tests :
- Test 3.3.5 : Le mécanisme de remplacement qui permet d’afficher les couleurs avec un contraste plus élevé doit être conforme à un ratio d’au moins 4,5:1 entre la couleur de texte et la couleur de fond.
- Test 7.1.7 : On peut enfin analyser explicitement l’élément <button> qui est utilisé pour les scripts.
- Test 7.1.5 : On doit procéder à un test de vérification avec le lecteur d’écran, que les scripts utilisent ARIA (Accessible Rich Internet Applications) ou non.
Ajout de nouvelles techniques :
- Test 11.5.1 : Dans un formulaire, les informations de même nature peuvent être regroupées avec ARIA : attributs role="group" et aria-labelledby ou aria-label ou title sur le conteneur en remplacement de <fieldset> et <legend>. Exemple :
```
<div role="group" aria-labelledby="field-legend-1">
  <p id="field-legend-1">Légende du groupe de champs</p>
  
  <label for="radio-1">Radio 1</label>
  <input type="radio" id="radio-1" name="radio-group-1" value="radio-1" />
  
  <label for="radio-2">Radio 2</label>
  <input type="radio" id="radio-2" name="radio-group-1" value="radio-2" />
<div>
```
- Cas particulier pour les critères 3.3 et 3.4 : un composant inactif (attribut disabled) ne doit pas obligatoirement respecter les règles de contrastes de couleurs.
Modification de tests :
- Test 11.1.4 : Une étiquette de champ de formulaire utilisant l’attribut aria-label ou aria-labelledby doit être visible si nécessaire.
- Critères 1.3, 1.4, 1.6 : l’alternative d’un SVG doit être présente dans une balise <title> et non plus <desc>.
  (Source : note de révision du RGAA – Note pour celles et ceux qui liront les diaporamas : il semble qu’une coquille se soit glissée dans le diaporama de la présentation)
Suppression de tests du critère 12.10 : Pour les lecteurs d’écran, la sémantique HTML et les landmarks ARIA suffisent à identifier les groupes de liens importants et zone de contenu, on n’a plus besoin des identifiants aujourd’hui. En revanche, il faut bien, toujours, des identifiants sur les éléments vers lesquels on met des liens d’accès rapide.

Des guides et des outils pour faciliter la mise en œuvre du RGAA

Le RGAA contient plus de 50 guides et outils mais ils sont un peu éparpillés et il y a peu de promotion autour de ces ressources.

Yann Olive (Empreinte Digitale) et Audrey Maniez (Access42) ont donc réalisé une formidable petite page web regroupant toutes ces ressources (archive). On y trouve notamment :

Web et handicaps : dys, handicap mental, impacts utilisateurs ;
Évaluation de la conformité :
- Assistant RGAA : extension de navigateur pour tester 268 tests sur les 335 du RGAA (encore en version RGAA v3.2016) ;
- guide des lecteurs d’écran (NVDA, VoiceOver, JAWS et guide sur l’évaluation ARIA) ;
- guide de l’auditeur ;
- méthodologie de tests.
Développement et intégration web :
- Guide de l’intégrateur web : guide sur le HTML / CSS ;
- Guide du développeur : guide sur le JS / ARIA ;
- Accessibilité des bibliothèques JavaScript (mis à jour en 2017) : outil qui donne des widgets correctifs ;
- Suite de tests automatisés pour les composants JavaScript utilisant les design patterns ARIA.
Guide des métiers ;
Développement mobile et audit d’applications : référentiel d’évaluation d’applications de bureau et mobile ;
Outils de gestion de contenu : référentiel pour les systèmes de gestion de contenu (CMS) : basé sur ATAG (Authoring Tool Accessibility Guidelines) 2.0.

Loi pour une République numérique et projet de directive européenne : quel impact sur l’accessibilité ?

Olivier Nourry (Access First) a fait le point sur ce qu’impose / imposera la directive européenne par rapport à ce qui est prévu aujourd’hui par la loi française qui est censée se plier à la directive européenne.

La directive européenne 2016/2102

La directive européenne donne des objectifs aux États membres que ceux-ci doivent transposer dans leurs propres loi :

cadre commun de travail ;
exigences minimales ;
notion d’aménagement raisonnable (charge disproportionnée à éviter) ;
périmètre : secteur public, tous sites internet, applications mobiles ;
WCAG (Web Content Accessibility Guidelines) 2.0 ;
acte d’exécution à venir pour les interfaces tactiles ;
hors périmètre : organismes « diffuseurs de service public », ONG (Organisations non gouvernementales), certains contenus, les écoles et crèches peuvent être exclues selon les États ;
contrôle périodique de la conformité selon une méthode d’évaluation qui sera définie au plus tard le 23/12/2018 ;
les États doivent fournir un compte-rendu à l’Union Européenne tous les trois ans (le premier est à rendre le 23/12/2021 au plus tard) ;
procédure permettant d’assurer le respect des dispositions ;
transposition de la directive dans le droit national avant le 23/09/2018.

La loi pour une République Numérique (article 106)

Par rapport à la directive européenne, la loi française est aujourd’hui en avance sur certains points mais en retard sur d’autres :

Elle ajoute les organismes délégataires d’une mission de service public et des entreprises privées ;
Elle concerne tout type d’information numérique ;
Formation des acteurs du projet ;
Obligation d’affichage du niveau d’accessibilité ;
Introduction d’une sanction ;
Délai d’application : pas plus de 3 ans après publication du décret d’application de la loi (qui n’existe pas encore aujourd’hui).

Session ouverte

Lors de la session ouverte, on nous présenté OSAi (Open Source Accessibility Initiative), une initiative créée sous le consortium OW2 par Orange. Parmi les acteurs, on trouve notamment la DINSIC, la Poste, Wordline, Smile, Océane Consulting, Atalan. Cette initiative a, par exemple, permis de créer des outils comme les notices AcceDeWeb, Tanaguru Engine, Confort+, etc.

Aurélien Levy (Temesis) nous a également parlé d’une nouvelle API en cours d’écriture, « Accessibility object model », qui permettrait d’apporter l’accessibilité sans modifier le code HTML mais en modifiant l’arbre de l’accessibilité dans le JS. On pourrait faire dire ce qu’on veut au lecteur d’écran : il peut dire « jolie photo » au lieu de « image » quand il rencontre une balise <img>. On pourrait alors en arriver à ne plus écrire de code HTML sémantique, accessible par défaut, car cette API permettrait de « corriger » ces problèmes. Autant dire que ce n’est pas forcément une très bonne nouvelle pour la qualité des sites web. À relativiser et utiliser à bon escient.

WCAG 2.1, ARIA et ACT (Accessibility Conformance Testing) – un point sur les travaux en cours au W3C

Shadi Abou-Zahra (World Wide Web Consortium) nous a présenté les travaux en cours au W3C.

WCAG 2.1 et ARIA

WCAG 2.0 a été publié en 2008. Ce sont des standards qui ne se préoccupent pas de la technologie utilisée (HTML 4 ou 5, etc.).

La WAI (Web Accessibility Initiative) a créé WCAG Quick Reference, un outil qui permet de filtrer les règles WCAG et de s’y référer rapidement (un peu comme ça a été fait pour le RGAA).

WCAG 2.1 apporte des améliorations :

pour les personnes malvoyantes ;
pour les personnes avec des problèmes cognitifs ou des difficultés d’apprentissage ;
prise en charge de l’accessibilité mobile ;
environ une dizaine de critères en plus.

Le travail sur WCAG 2.1 a démarré en janvier 2017. La version 2.1 est attendue en recommandation W3C pour juin 2018. Cette nouvelle version sera rétrocompatible avec la version 2.0.

WAI-ARIA a fait ses début en 2006 et la version 1.1 est actuellement en cours de validation au W3C (statut « Proposed recommendation (PR) » au 02/11/2017).

WCAG ACT (Accessibility Conformance Testing)

Le groupe de travail « W3C ACT Task Force » a été lancé en 2017 et permet de se mettre d’accord sur la façon de tester la conformité d’un critère.

ACT rules est en train d’être écrit et donne les procédures de tests ainsi que le mode de test (automatique, semi-automatique ou manuel).

C’est similaire à ce que fait le RGAA en France avec sa méthodologie de tests.

Le projet COMPARE, présentation et démonstration d’une plateforme collaborative pour évaluer et discuter de l’accessibilité de composants complexes

Bruno Marmol et Alex Bernier (BrailleNet) nous ont présenté COMPARE (archive) (COMparing Peer Accessibility Rating in Evaluation), un projet mené par 3 acteurs européens dont BrailleNet en France.

Ce projet est né dans le contexte suivant :

les méthodes d’évaluation sont différentes en Europe de la conformité WCAG ;
chacun a des interprétations différentes de WCAG ou d’ARIA ;
ARIA est implémenté différemment selon les technologies d’assistance ;

Il permet de recenser différents cas de composants complexes, de les évaluer et d’échanger sur leur accessibilité. Cela permet d’avoir une banque de données d’exemples de composants accessibles ou non avec des explications.

24^e séminaire AccessiWeb, du nouveau pour le RGAA et WCAG