Quick reference card

• octo.com
• blog.octo.com

There is a better way

Web a11y pour tout le monde

Multiples contextes d'usage

• • écran + clavier + souris
• • synthèse vocale
  • liseuse N/B
  • afficheur braille
  • assistant vocal

Définition de l'accessibilité web

Concevoir pour tout le monde

Étudier la diversité pour réduire l'exclusion.

Qui sont vos utilisateurs et utilisatrices dans leur diversité ? Assez difficile de savoir exactement, parce que c'est intraçable, mais ce qui est certain, c'est que parmi elleux, certain·es sont en situation de handicap avec :

• troubles dys (10 % de la population) ;
• déficience visuelle (3 %), daltoniens (4 %) ;
• difficultés auditives (11,5 %) ;
• difficultés difficultés motrices des membres supérieurs, etc.

C'est sans compter les situations de handicap temporaire (bras dans le plâtre, dépression, etc.), situationnel (lieu bruyant, contexte stressant, etc.) ou liées à l'équipement non optimal (écran mal calibré, souris cassée, etc.).

20 à 40 % des internautes ont un accès difficile, partiel ou impossible aux informations et services en ligne.

Questions à se poser en User Research :

1. Qui sont mes utilisateurs et utilisatrices ? Et qui en est exclu ?
2. Quels sont leurs usages, dans leur diversité ?
3. Quelles sont leurs aides techniques (synthèse vocale, etc.) ?
4. Quels sont leurs besoins spécifiques ?
5. Vos personas reflètent-ils cette diversité ?

Concevoir pour un cas d'usage extrême puis étendre au plus grand nombre.

Par exemple : Lisa, aveugle, navigue à l'aide d'une synthèse vocale. En conception, des textes alternatifs sont donc prévus pour être vocalisés à la place des images. Ce qui sert aussi à Andréa qui navigue sans image, dans le train, où le débit est trop faible pour les afficher. Concevoir pour un persona aveugle élargit l'usage pour tous les cas où les images ne s'affichent pas, etc.

Normes & lois

1. WCAG Web content Accessibility Guidelines Norme ISO / EIC 40500 1999
2. EN 301549 Norme européenne d'accessibilité 2014
3. • RGAA Référentiel Général d'Amélioration de l'Accessibilité 2009
   • RAAM Référentiel d'évaluation de l'Accessibilité des Applications Mobiles 2021

Ce que dit la loi

La majorité des législations à travers le monde a adopté la norme WCAG comme référence. La directive européenne EAA établit l’obligation d’accessibilité.

Trois échéances en France :

1. Juillet 2021 tous les sites publics français
2. À partir du 28 juin 2025 tous les nouveaux produits*
3. Juin 2030 tous les produits numériques*

*Sites internet, intranet, extranet, app mobiles, progiciel (web ou mobile) et mobilier urbain numérique de service public et des entreprises privées fournissants des produits et services qui sont vendus ou utilisés au sein de l’UE, quel que soit l’endroit où les entreprises sont basées, y compris livres numériques, services bancaires et billetteries de transport.

Travail d'équipe

• 61% Développement front HTML / JS / ARIA
• 26% Contenus (textes, images, graphiques, PDF, vidéos, transcripts, …)
• 13% Design (UX + UI) inclusif et accessible

Tous les profils sont concernés. C'est un travail d'équipe sous la houlette des PO.

Les rôles clés Les compétences clés pour l'accessibilité web

• Designer formé·e au design inclusif et accessible
• Dev Front maîtrisant HTML / JS / ARIA
• Product Owner sachant prioriser et recetter l'accessibilité
• Référent·e accessibilité pilote l'application de la politique d'accessibilité
• Rédacteurs/trices formé·es à la production accessible de contenus
• Auditeur/trice expert·e pour établir la conformité

Stack Technique

L'accessibilité web repose sur le langage HTML auquel peuvent s'ajouter les langages CSS, JavaScript et une touche d'ARIA.

1. Le HTML structure l'information. Ses balises apportent la sémantique : un bouton n'est pas un lien, qui n'est pas une <div>. Chaque composant HTML embarque nativement les comportements d'interaction attendus, de façon accessible : un <button> est déjà actionnable au clavier.
2. Le CSS met en forme l'information présente dans le HTML de la page. L'usage du CSS uniquement ne rendra pas accessible l'information à tout le monde.
3. Le JavaScript régit les interactions complexes, comme l'affichage de notifications ou une carte interactive. Dans la plupart des cas, il ne sera pas nécessaire. Il permet de coder des composants au-delà de ce qui est disponible en HTML.

4. ARIA (Accessible Rich Internet Applications) propose un ensemble d'attributs qui étendent le HTML. Il donne plus d'information aux technologies d'assistance :

   • en explicitant les liens entre les éléments, par exemple l'image et sa description;
   • en explicitant l'état d'un élément, par exemple la sélection en cours dans une liste;
   • en étendant la sémantique, par exemple un onglet fait d'un composant <button> sera enrichi par le role="tab"

   À utiliser avec parcimonie : pas d'attribut ARIA vaut mieux qu'un attribut ARIA mal renseigné.

Comment vérifier ?

Une partie des tests d'accessibilité est automatisable. Il existe pour cela de nombreux outils comme WAVE, aXe, Tanaguru ou Asqatasun. Mettre en place des tests auto est le point de départ.

La majorité des tests d’accessibilité sont fonctionnels. Ils s’effectuent par une inspection manuelle. Certains ne nécessitent pas de compétences techniques et sont très faciles à réaliser en 10 « Easy checks » : il s’agit de simuler des situations réelles d’usage, en navigant par exemple sans image, sans couleur, sans souris, etc.

La pratique régulière de ces tests permet de maintenir un bon niveau d'accessibilité. Ils précédent l'audit qui établit le taux de conformité atteint (à planifier une fois par an). Il est bienvenu de les compléter par des tests avec lecteur d'écran puis par tests d'utilisabilité avec des personnes en situation de handicap.