a11y (accessibility) pour tou·tes

Multiples contextes d'usage

- Écran + clavier + souris
- Synthèse vocale
- Liseuse N/B
- Afficheur braille
- Assistant vocal

Définition de l'accessibilité web

Mettre le web et ses services à la disposition de tous les individus, quels que soient

leur matériel ou logiciel ;

leur infrastructure réseau ;

leur langue maternelle, leur culture ;

leur localisation géographique ;

ou leurs aptitudes physiques ou mentales.

- Tim Berners-Lee, directeur du W3C, inventeur du 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 :

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

Designer un web accessible et inclusif

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

WCAG

Web content Accessibility Guidelines Norme ISO / EIC 40500 1999
EN 301549

Norme européenne d'accessibilité 2014
- 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 :

Juillet 2021 tous les sites publics français
À partir du 28 juin 2025 tous les nouveaux produits*
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

Répartition des critères d'accessibilité selon les compétences nécessaires à leur réussite.

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

Product Owner sachant prioriser et recetter l'accessibilité
Dev Front maîtrisant HTML / JS / ARIA accessibles
Designer formé·e au design inclusif et accessible
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.

L'accessibilité se repose avant tout sur le HTML, puis le CSS, le Javascript et enfin ARIA

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.
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.
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.
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.

Exemple: naviguer au clavier

Vérifiez que le produit web reste entièrement utilisable sans souris ni trackpad, c'est-à-dire en utilisant uniquement les touches du clavier : tab , enter…

Le déplacement doit être visible ;
et se dérouler dans un ordre logique;
Tout élément qui déclenche une action au clic ou au survol (liens, boutons, champs de formulaires, menus déroulants, vidéo, datepicker, etc.) doit être atteignable et actionnable au clavier seulement.

Ils et elles vous remercieront : les personnes ayant des difficultés motrices, celleux utilisant un lecteur d'écran (aveugles, dyslexiques...). La navigation au clavier est un quotidien pour des milliers d’internautes.

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.

Paliers A11y

Afficher une version simplifiée de l'infographie

Paliers de maturité	Test à introduire	Rôles clés	Processus introduits ou contenu produits	Objectif de fin de palier (en pourcentage de conformité au RGAA)	Mention obligatoire associée
L'accessibilité n'est pas prise en compte	Validation HTML			0%	Non conforme
L'accessibilité est introduite dans les tests	Tests A11y automatisés	Développement HTML sémantique		25%	Non conforme
L'accessibilité est incorporée dans les processus	Recette fonctionnelle 10 Easy Checks	Product Owner	Coopération Design & Dev	50%	Partiellement conforme
L'accessibilité devient une volonté stratégique	Audit de conformité	Auditeur/trice expert·e	L'accessibilité est spécifiée dans les US Mise à jour des mentions obligatoires	75%	Partiellement conforme
L'accessibilité imprègne la culture	Tests avec lecteur d'écran	Rédaction et production de contenu Référent·e accessibilité	Production de contenus accessibles	100% - Niveau légal requis	Totalement conforme
L'accessibilité se déploie à l'échelle	Tests d'utilisabilité avec handicapé·es	UX Designer	Bibliothèque de composants accessibles	100% - Niveau légal requis	Totalement conforme