Accessibilité numérique  : quoi de neuf dans le paysage normatif et réglementaire en 2017  ?

Le 24e séminaire du groupe de travail AccessiWeb a eu lieu le mardi 17 Octobre, à la Cité des Sciences et de l’Industrie à Paris. Le thème de cette édition  : Quoi de neuf dans le paysage normatif et réglementaire en 2017  ?

Ce séminaire a été l’occasion de faire le point sur  :

• la mise à jour 2017 du RGAA 3.0 ;
• les évolutions des WCAG 2.0 et d’ARIA 1.1 ;
• la loi pour une République numérique ;
• le projet de directive européenne sur l’accessibilité.

Pour rappel, les séminaires AccessiWeb sont ouverts à tou·te·s, et pas uniquement aux membres du Groupe de Travail Accessiweb (GTA). Profitez-en  !

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

Jean-Pierre Villain, le papa du RGAA 3.0, a inauguré cette journée par un topo sur le processus de mise à jour du RGAA ainsi que ses nouveautés.

Les retours / remontées terrain proviennent de différents outils comme Github, Gitlab, Twitter, email etc. Ils sont ensuite qualifiés puis confiés à des expert·e·s afin de les évaluer. Après une double relecture et s’ils sont pertinents, ces retours seront alors validés et implémentés dans la prochaine version du RGAA. La DINSIC garde bien évidemment un rôle d’arbitrage tout au long de ce processus.

Lors d’une mise à jour, une vigilance toute particulière est apportée sur la non régression et la rétro compatibilité. Un site conforme RGAA 3 2016 ne doit pas être non conforme RGAA 3 2017. Dans les faits, il n’y a donc pas de suppression ou d’ajout de nouveau critère, il y a par contre quelques changements au niveau des tests.

Quelques exemples (liste non exhaustive)  :

• l’ajout d’un test qui rend conforme un élément de formulaire inactif même si ce dernier n’a pas un contraste suffisant. L’important est qu’il possède l’attribut adéquat, par exemple disabled s’il s’agit d’un button ;
• l’utilisation de la balise desc au lieu de title dans le cadre d’un svg porteur d’information ;
• la suppression de l’obligation d’un intitulé de champ visible à la prise de focus. Par contre pour un champ de recherche il ne sera plus obligatoire d’avoir un label visible si l’intitulé du champ de recherche est correctement renseigné dans l’attribut aria-label ;
• la prise en charge d’autres méthodes d’implémentation que fieldset pour les groupements de champs de formulaires. Par exemple role="group" + aria-label ou role="group" + aria-labelledy.
• etc.

Pour les curieuses et les curieux, vous pourrez retrouver l’ensemble des nouveautés dans la note de révision de la version 3 2016 à la version 3 2017.

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

Audrey Maniez et Yann Olive, font partie du groupement qui travaille sur la refonte du RGAA. Ils nous ont fait un état des lieux très clair sur les différentes ressources qui gravitent autour de ce référentiel.

Ses ressources sont disponibles sur le compte github de la DINSIC et le moins qu’on puisse dire c’est que c’est très riche, il y en a pour tout le monde.

Vous y trouverez par exemple  :

• une méthodologie pas à pas pour faire un audit RGAA ;
• un guide intégrateur  : profil HTML / CSS ;
• un guide développeur  : profil JS ;
• un guide concepteur  : profil UX ;
• un guide décideur  : profil manager ;
• un guide contributeur  : profil producteur de contenu web ;
• un guide lecteur d’écran  : évaluer l’accessibilité à l’aide d’un lecteur d’écran ;
• un guide impacts utilisateurs  : piqûre de rappel sur l’impact utilisateur de chaque critère ;
• une étude de l’accessibilité des principales bibliothèques JavaScript. Il ne s’agit pas juste d’un état des lieux, il y a également les corrections qui sont disponibles ;
• une extension navigateur pour faciliter l’audit par page  : le seul petit bémol c’est qu’il n’est pas à jour avec la dernière version du RGAA
• etc.

C’est un travail titanesque et d’une très bonne qualité. Les guides par profil / métier me rappelle forcément le projet Accede Web et c’est à mon avis tout à fait complémentaire.

Le guide impacts utilisateurs est une petite merveille pour la sensibilisation à l’accessibilité ou pour servir de piqûre de rappel. On oublie trop souvent pourquoi on respecte tel ou tel critère. Ce guide permet de se rappeler qu’on fait ça non pas pour être conforme mais surtout parce que ça répond à un besoin utilisateur.

Pour en savoir plus et pour mieux se retrouver dans toutes ses ressources, un lien à mettre tout de suite en favori  : http://a42.fr/ress-rgaa.

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

Olivier Nourry nous a brillamment résumé la situation en cours sur le projet de directive européenne ainsi que sur la loi pour une République numérique.

Projet de directive européenne

La directive européenne 2016/2102 est relative à l’accessibilité des sites internet et des applications mobiles des organismes du secteur public. Un des objectifs de cette directive est d’harmoniser les dispositions relatives à l’accessibilité numérique dans les services publics de l’UE. Pour cela il faut créer un cadre commun (exigences, normes et champs d’application) mais également définir les exigences minimales pour légiférer au sein de chaque état membre.

Les états membres vont donc devoir transposer localement cette directive, au plus tard le 23/09/2018. Ce qui est rassurant pour le secteur public en France, c’est que dans cette directive on retrouve des éléments déjà demandés dans le RGAA comme par exemple  :

• la publication d’une déclaration d’accessibilité ;
• un contact ou mécanisme permettant de faire des retours utilisateurs.

Loi pour une République numérique

Concernant la Loi pour une République numérique, on s’intéresse tout particulièrement à l’article 106 qui remplace l’article 47 et le complète. Pour rappel le périmètre dans l’article 47 était le suivant  :

Les services de communication au public en ligne des services de l’État, des collectivités territoriales et des établissements publics qui en dépendent doivent être accessibles aux personnes handicapées.

Il s’agit toujours de ce périmètre mais il faut désormais ajouter  :

• les organismes délégataires d’une mission de service public ;
• les entreprises privées excédant un certain seuil de chiffre d’affaire (malheureusement aucun chiffre pour le moment sur ce fameux seuil) ;

L’article 106 introduit également des obligations pouvant entraîner une sanction  :

• l’affichage de la conformité ou non aux règles d’accessibilité dès la page d’accueil ;
• l’affichage d’un schéma pluriannuel de mise en accessibilité décliné en plans d’actions annuels ;
• permettre aux utilisateurs de signaler les manquements aux règles d’accessibilité.

Le manquement à ces obligations donnera lieu à une sanction administrative pouvant aller jusqu’à 5000 € par an. Le problème étant qu’on ne sait pas vraiment d’où sort ce chiffre. Est-ce que ça sera par entreprise / organisme  ? Par site mise en défaut  ? Nous n’avons pas plus de précision pour le moment.

Session ouverte

Quelques outils nous ont été présentés durant cette session  :

• le service Orange Confort+ est une extension navigateur qui vient ajouter un confort lors de la consultation et/ou de la navigation au sein d’une page Web. Bien entendu cela ne règle pas magiquement les problèmes d’accessibilité, c’est une surcouche (il faut donc que le code de base soit “propre”) ;
• OSAI (Open Source Accessibility Initiative) est une plateforme regroupant des projets accessibles et open-source. Actuellement il y a 17 projets identifiés ;
• The Accessibility Object Model de Google est une API JavaScript permettant de modifier et d’explorer directement la couche accessibilité.

WCAG 2.1, ARIA et ACT – un point sur les travaux en cours au W3C

Shadi Abou-Zahra travaille pour la WAI (Web Accessibility Initiative) du W3C.

WCAG 2.1

Il débute sa conférence par un rappel du contexte sur l’adoption de WCAG 2.0  :

• publié par le W3C en décembre 2008 ;
• adopté au Japon via JIS 8341 en 2010 ;
• adopté comme norme ISO/IEC via 40500 en 2012 ;
• adopté par les standards européens via EN 301 549 v1.1.2 en 2014 ;
• référencé par la section 508 aux US en 2017.

Plusieurs ressources sont disponibles autour des WCAG  :

• How to meet WCAG 2.0 (customizable quick & reference) ;
• Techniques for WCAG 2.0 (instructions for developers) ;
• WCAG 2.0 (W3C standard) ;
• Understanding WCAG 2.0 (detailed & reference).

Quid de l’avenir  ? WCAG 2.1, actuellement en brouillon, prendra en compte  :

• la rétro compatible avec WCAG 2.0 ;
• les personnes ayant une faible vision ;
• les personnes ayant des troubles cognitifs et/ou des difficultés d’apprentissage ;
• l’accessibilité sur mobile.

WCAG 2.1 a débuté en janvier 2017 et devrait être en recommandation (standard) en juin 2018. C’est donc le moment de faire des retours d’expériences sur cette nouvelle version, d’implémenter et de tester.

ACT (Accessibility Conformance Testing)

L’autre gros sujet est mené par le groupe de travail ACT sur l’écriture et la standardisation des tests d’accessibilité. Cette initiative n’est pas nouvelle puisqu’elle a d’abord vue le jour en 1999 mais faute d’intérêt de la communauté et des éditeurs cela n’a pas donné suite. C’est différent maintenant puisque le sujet de l’accessibilité est de plus en plus présent et 2017 signe donc une nouvelle naissance de ce projet.

Actuellement il y a 3 tests écrits, ce n’est qu’un début, mais c’est prometteur  :  https://w3c.github.io/wcag-act-rules/

Nous avons de plus en plus d’outils pour tester l’accessibilité (le W3C recense 96 outils dans le monde), que ça soit via des tests automatiques, semi-automatiques ou manuels. Pour en avoir testé plusieurs, la qualité et/ou les résultats sont très inégaux. Le problème est que d’un outil à l’autre on ne sait pas si le test est réalisé de la même façon. Est-ce qu’il est plus ou moins permissif  ? Est-ce qu’il teste vraiment la même chose  ? Le projet ACT a justement pour but d’harmoniser ces tests, de les rendre plus justes et de trouver un consensus.

Le projet COMPARE

Le projet COMPARE (COMparing Peer Accessibility Ratings in Evaluation) présenté par Bruno Marmol et Alex Bernier de BrailleNet est un projet européen d’une plateforme collaborative pour évaluer et discuter de l’accessibilité de composants complexes.

Les objectifs de ce projet sont multiples  :

• disposer des ressources utiles à la formation en accessibilité ;
• avoir une plateforme où permettre le débat entre expert·e·s ;
• aboutir à un consensus ;
• obtenir des éléments permettant si besoin de faire progresser ARIA.

Concernant la plateforme, cela me fait fortement penser au feu KBAccess qui recensaient les bons et mauvais exemples d’accessibilité (mais qui n’est malheureusement plus à jour / maintenu). J’espère que COMPARE s’en sortira mieux, la clé dans ce genre de projet étant l’implication de la communauté (et pas uniquement des expert·e·s).