Les réglementations françaises et européennes ont récemment changé : construire un site ou une application web accessible au plus grand nombre devient une obligation pour de plus en plus d’entreprises. Comment assurer le respect de ces directives dans le code produit ? Quels sont les leviers à actionner pour convaincre le top management d’opérer ces changements ?

Techniquement, qu’est-ce que c’est ?

« Internet ne devrait pas être un espace d’exclusion.« 

Accessibilité numérique | Les document de référence du SI de l’état

Tel est le credo qui motive l’ensemble des initiatives autour de l’accessibilité. La Web Accessibility Initiative est un projet de la W3C pour « développer des standards et ressources pour aider à la compréhension et l’implémentation de l’accessibilité« .

Les objectifs de ces standards (WCAG) sont de rendre le contenu d’une page web plus :

• Perceptible (texte clair, transcription possible en synthèse vocale, braille, etc.)
• Opérant/Utilisable (navigation clavier, orientation et temps de lecture, etc.)
• Compréhensible (navigation prévisible, aide à la correction de saisie, etc.)
• Robuste (support navigateur et compatibilité aux technologies d’assistance)

Ce sont des recommandations de développement HTML, CSS et JS plus ou moins spécifiques en fonction du niveau d’accessibilité souhaité (A, AA ou AAA).

Ainsi, le design et développement d’applications web respectant ces standards donnent à un plus large public la possibilité d’interagir avec les interfaces web. De plus, les éditeurs de technologie d’assistance, tels que ReadSpeaker, s’appuient sur les WCAG pour améliorer leur solution.

Comme dit précédemment, la sensibilisation à ces pratiques n’est pas qu’à la charge des équipes de développement. Il faut un investissement sur le parcours utilisateur qui réunit à la fois les responsables produit (PO, PM, etc.) et les responsables parcours (UX, DA, etc.).

Un web moderne et éthique n’est possible que si rendre accessible ses applications devient un axe majeur de réflexion des équipes projet.

Valoriser le web accessible, l’approche française

RGAA, les experts HTML

La Direction Interministérielle du NUmérique (ex-DINSIC) est un service du Premier Ministre qui intervient dans le cadre de la modernisation de l’action publique et son accès pour tous. Deux choses sont à retenir :

• Le Référentiel Général d’Accessibilité pour les Administrations (RGAA), traduction française de la dernière version des WCAG. Ce référentiel prévoit non seulement l’encadrement du livrable HTML du site web mais aussi l’obligation de documentation à destination du public concerné.
• Le décret n° 2019-768 du 24 juillet 2019 relatif à l’accessibilité aux personnes handicapées des services de communication au public en ligne stipulant notamment les amendes encourues

Marketing, SEO – Accessibility is the new black

En plus des amendes encourues (jusqu’à 20 000 euros par site web), l’accessibilité web est devenue « tendance » avec une prise de conscience autour du handicap ces dernières années. De nombreux organismes d’audit et de formation ont vu le jour ces dernières années avec les évolutions de la législation européenne : cela a donné naissance à une multitude des labels d’accessibilité avec comme seule valeur la e-réputation de l’organisme.

Vous pouvez retrouver des pictogrammes du style :

De plus, les problématiques SEO, épousant naturellement celle de l’accessibilité, poussent le design applicatif vers les règles de l’accessibilité. Cela donne une dimension business supplémentaire à son implémentation.

Pour aller plus loin

L’initiative française est à souligner et mettre en avant, mais la restriction des entreprises ciblées et les dérogations possibles sont des obstacles à l’accélération d’un déploiement massif de l’accessibilité (Accessibilité numérique : un pas en arrière pour les personnes handicapées).

L’initiative humaine sera le vecteur majeur de cette transformation déjà initiée dans certains grands groupes. Des conférences et prises de parole sur l’accessibilité (et pour certaines… accessibles) sont également présentes sur la scène française (Paris Web, A11y Paris, DotJS, etc.)

Automatiser dans son application

Les WCAG, c’est de la norme : aussi denses que complexes ! Il existe différents outils permettant de confronter un rendu HTML aux différentes règles des niveaux de WCAG :

• Outil/Extension navigateur
• Outil en ligne
• API
• Librairie JS

AChecker est un exemple d’outil en ligne permettant d’établir un rapport sous différents formats (PDF, HTML, CSV) et fournir un label d’accessibilité pour la ressource testée.

Exemple de validation de l’accessibilité du site Kaibee.fr

Cet outil met également à disposition une API REST. On pourra aussi citer le Bureau Of Internet Accessibility ou encore l’Automated Accessibility Testing Tool de Paypal ; exemples d’initiative qui simplifient l’audit des sites web est quand le rendu HTML est statique. En effet, un DOM dynamique pose certaines problématiques pour des audits automatisés (SEO, tracking comportemental, performance, etc.)

SPA, le défi

Les très populaires Single Page Application sont par défaut pas très SEO-friendly de par une considération tardive des éditeurs et/ou du manque d’application de bonnes pratiques.

En effet, les balises d’encapsulation de web components, le virtual/shadow DOM ou encore le templating conditionnel, les directives d’affichage et les styles dynamiques rendent le SEO plus difficile mais pas impossible (SPA and SEO: Google (Googlebot) properly renders Single Page Application and execute Ajax calls).

Dessine-moi un crawler JS

Là où un crawler « classique » charge une page puis fait son inspection, le crawler JS va un peu plus loin.

L’idée serait donc d’interagir un minimum avec la SPA pour avoir un rendu suffisamment exhaustif et ainsi auditer la page en question (arriver à l’état RETURN du schéma pour auditer)
htcrawl (ex. HTCap) est une boîte à outils riche autour d’un crawler JS performant. Trois entrées de l’API correspondent à l’état RETURN :

• l’événement pageInitialized de la fonction crawler.on
• le résolution de la promesse de la méthode crawler.start
• le résolution de la promesse de la méthode crawler.stop

htcrawl + pa11y = SPA-ccessible !

Une fois l’état RETURN atteint, il suffit de lancer une analyse avec l’outil de son choix.

pa11y est assez complet avec de la gestion d’authentification, de niveau d’audit, d’impression écran, etc. Son point fort est sa simplicité en termes de reporting : formats variés (CLI, CSV, JSON, HTML), contenu compréhensible et aide à la correction d’erreur.

Ainsi, un script combinant les librairies peut produire un exemple de rapport comme suit :

[
   {
      "url":"http://localhost:4200/",
      "index":0,
      "issues":[
         {
            "message":"The html element should have a lang or xml:lang attribute which describes the language of the document.",
            "selector":"html"
         },
         {
            "message":"This element has insufficient contrast at this conformance level. Expected a contrast ratio of at least 3:1, but text in this element has a contrast ratio of 2.48:1. Recommendation:  change text colour to #4ba74b.",
            "selector":"html > body > app-root > app-layout-header > nav > div > a"
         }
      ]
   },
   {
      "url":"http://localhost:4200/register/",
      "index":1,
      "errorMessage":404
   }
]

Plus clair et concis, ce type de rapport pourrait simplifier le quotidien des équipes. Ainsi, la mise en en accessibilité de vos application pourra être plus facilement établie.

Mahamoud Saïd Omar