Construire des sites web accessibles

L’accessibilité web n’est pas facultative : c’est une exigence fondamentale pour concevoir des expériences numériques inclusives. Plus d’un milliard de personnes dans le monde vivent avec une forme de handicap, et une conception accessible profite à tous, pas seulement aux personnes atteintes d’une déficience permanente.

Les sous-titres aident la personne qui regarde une vidéo dans le train. Un contraste élevé aide celle qui lit son téléphone en plein soleil. La prise en charge du clavier aide l’utilisateur expert comme la personne qui a le poignet dans le plâtre ce mois-ci.

Ce guide présente la norme, les patterns qui résolvent la plupart des problèmes concrets et une routine de test qui s’intègre au développement courant.

Comprendre les WCAG

Les Web Content Accessibility Guidelines (WCAG) fournissent un cadre pour rendre les contenus web perceptibles, utilisables, compréhensibles et robustes. Ces quatre principes, souvent résumés par l’acronyme anglais POUR, constituent le socle de toutes les normes d’accessibilité.

Parmi les critères de succès essentiels figurent la fourniture d’alternatives textuelles aux contenus non textuels, des rapports de contraste de couleur suffisants, l’accès à toutes les fonctionnalités au clavier et la mise à disposition de plusieurs moyens de naviguer dans le contenu.

Niveaux et versions

Chaque critère de succès est associé à un niveau : A, AA ou AAA. Le niveau AA est la cible réaliste pour la plupart des organisations, et c’est celui auquel renvoient la majorité des exigences des marchés publics et des politiques d’accessibilité. Le niveau AAA n’est pas atteignable pour tous les contenus : considérez-le comme un objectif ambitieux pour certaines pages.

Les WCAG 2.2 sont devenues une recommandation du W3C en octobre 2023. Elles complètent la version 2.1 au lieu de la remplacer : le travail réalisé selon l’ancienne version reste donc valable. Un critère, 4.1.1 Analyse syntaxique, a été supprimé car jugé obsolète. Si vous démarrez un nouveau projet, visez le niveau AA des WCAG 2.2.

Les nouveautés des WCAG 2.2

Les nouveaux critères méritent d’être connus par leur nom, car ils détectent des problèmes que les checklists plus anciennes laissent passer :

• 2.4.11 Focus non masqué (minimum), AA : un élément qui a le focus ne doit pas être entièrement caché par un contenu ajouté par l’auteur, comme un en-tête fixe ou un bandeau de cookies.
• 2.5.7 Mouvements de glissement, AA : tout ce qui se fait par glisser-déposer, comme réordonner une liste ou déplacer un curseur, doit disposer d’une alternative à pointeur unique.
• 2.5.8 Taille de la cible (minimum), AA : les cibles de pointeur doivent mesurer au moins 24 × 24 pixels CSS, ou être suffisamment espacées, à quelques exceptions près listées dans la norme.
• 3.2.6 Aide cohérente, A : les mécanismes d’aide répétés d’une page à l’autre apparaissent dans le même ordre relatif.
• 3.3.7 Saisie redondante, A : ne demandez pas aux gens de ressaisir des informations qu’ils ont déjà fournies au cours du même processus.
• 3.3.8 Authentification accessible (minimum), AA : la connexion ne doit pas dépendre d’un test de fonction cognitive, comme mémoriser ou recopier un code, sauf si une alternative ou une assistance (par exemple autoriser le collage et les gestionnaires de mots de passe) est disponible.

Les trois autres nouveaux critères (2.4.12, 2.4.13 et 3.3.9) relèvent du niveau AAA.

Les patterns d’accessibilité courants

Commencez par du HTML sémantique. Une hiérarchie de titres correcte, des éléments de landmark et des libellés de formulaire couvrent une part importante des exigences d’accessibilité. Les attributs ARIA doivent compléter la sémantique native du HTML, pas la remplacer.

Privilégier les éléments natifs

Un élément button peut recevoir le focus, s’active avec Entrée et Espace, expose le rôle de bouton et participe aux formulaires. Une div munie d’un gestionnaire de clic ne fait rien de tout cela tant que vous ne l’avez pas reconstruit à la main, et la plupart des versions faites maison oublient quelque chose.

<!-- À éviter : il faut un rôle, un tabindex et des gestionnaires de touches pour s'en approcher -->
<div class="btn" onclick="save()">Save</div>

<!-- À privilégier : clavier, focus et sémantique inclus -->
<button type="button" onclick="save()">Save</button>

Il en va de même pour les liens (a avec un href pour la navigation, button pour les actions), details et summary pour les contenus dépliables, et dialog pour les fenêtres modales. Lorsqu’aucun élément natif ne convient, suivez le WAI-ARIA Authoring Practices Guide plutôt que d’inventer un modèle d’interaction au clavier.

Landmarks et titres

Les utilisateurs de lecteurs d’écran naviguent souvent par landmarks et par titres plutôt que de lire la page de haut en bas. Donnez à chaque page un unique main, placez la navigation du site dans un nav, et utilisez header et footer pour les bandeaux de page. Si vous avez plusieurs nav, donnez à chacun un aria-label pour qu’on puisse les distinguer.

Les titres doivent décrire la structure du contenu, pas sa taille visuelle. Ne passez pas de h2 à h4 parce que le style plus petit était plus joli ; modifiez plutôt le style.

Formulaires

Chaque champ a besoin d’un libellé associé par programmation. Le texte d’espace réservé (placeholder) n’est pas un libellé : il disparaît à la saisie et manque souvent de contraste. Regroupez les contrôles liés avec fieldset et legend, et reliez les indications et les erreurs à leurs champs :

<label for="email">Email address</label>
<input id="email" type="email" autocomplete="email"
       aria-describedby="email-hint email-error" aria-invalid="true">
<p id="email-hint">We will only use this to send your receipt.</p>
<p id="email-error">Enter an email address in the format name@example.com.</p>

Les messages d’erreur doivent dire ce qui ne va pas et comment le corriger. À la soumission, déplacez le focus vers un récapitulatif des erreurs ou vers le premier champ invalide, pour que les utilisateurs du clavier et des lecteurs d’écran n’aient pas à deviner. L’attribut autocomplete compte aussi : il satisfait le critère 1.3.5 Identifier la finalité de la saisie et réduit la frappe pour tout le monde.

Gestion du focus

La gestion du focus est cruciale dans les applications monopages. Lorsque le contenu change dynamiquement, assurez-vous que le focus se déplace de façon prévisible, pour que les utilisateurs de lecteurs d’écran comprennent ce qui a changé. Utilisez des régions aria-live pour annoncer les mises à jour dynamiques.

Quelques règles couvrent la plupart des cas :

• Après un changement de route côté client, déplacez le focus vers le titre principal ou la région principale de la nouvelle page, et mettez à jour le titre du document.
• Lorsqu’une modale s’ouvre, placez le focus à l’intérieur et maintenez-le ; à sa fermeture, rendez le focus au contrôle qui l’a ouverte. L’élément natif dialog ouvert avec showModal() s’en charge en grande partie pour vous.
• Ne supprimez jamais l’indicateur de focus sans le remplacer. Utilisez :focus-visible pour afficher un contour net aux utilisateurs du clavier sans l’afficher à chaque clic de souris.
• Les régions live doivent exister dans le DOM avant que leur contenu ne change, sinon de nombreux lecteurs d’écran n’annonceront pas la mise à jour. Utilisez aria-live="polite" pour les messages de statut et réservez assertive aux messages réellement urgents.

Couleur et contraste

Le texte normal requiert un rapport de contraste d’au moins 4,5:1 avec son arrière-plan, et le texte de grande taille (environ 18 pt, ou 14 pt en gras) un rapport de 3:1 (1.4.3). Les composants d’interface et les graphismes porteurs de sens, comme les bordures de champs, les contours de focus et les lignes de graphiques, requièrent 3:1 par rapport aux couleurs adjacentes (1.4.11). Vérifiez les thèmes clair et sombre : une palette conforme dans l’un échoue souvent dans l’autre.

La couleur ne doit jamais être le seul moyen de transmettre une information (1.4.1). Une bordure rouge sur un champ invalide doit s’accompagner d’une icône ou d’un texte ; une série de graphique doit pouvoir se distinguer par son libellé, un motif ou sa position autant que par sa teinte.

Animations et zoom

Respectez la préférence de l’utilisateur en matière d’animations. Les grands effets de parallaxe et les animations en lecture automatique peuvent provoquer un réel malaise chez les personnes atteintes de troubles vestibulaires.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

Le contenu doit aussi pouvoir se réorganiser sans défilement horizontal à une largeur de 320 pixels CSS (1.4.10), ce qui correspond à une fenêtre de 1 280 pixels zoomée à 400 %. Utilisez des unités relatives pour la typographie, évitez les hauteurs fixes sur les conteneurs de texte et ne désactivez jamais le zoom par pincement dans la balise meta viewport.

Tester votre travail

Les outils automatisés comme axe-core et Lighthouse ne détectent qu’une partie des problèmes d’accessibilité. Ils excellent dans les vérifications objectives, comme les libellés manquants, les attributs ARIA invalides et les défauts de contraste, mais ils ne peuvent pas vous dire si un texte alternatif a du sens, si l’ordre du focus est logique ou si une interaction est compréhensible. Les tests manuels au clavier et avec des lecteurs d’écran (VoiceOver, NVDA, JAWS) sont indispensables pour repérer le reste. Incluez des personnes en situation de handicap dans votre recherche utilisateur pour obtenir les retours les plus justes.

Une routine qui s’intègre au développement

1. Linting et tests unitaires. Utilisez un linter d’accessibilité adapté à votre framework et ajoutez des vérifications axe automatisées à vos tests de composants et de bout en bout, pour que les régressions fassent échouer le build.
2. Passage au clavier. Débranchez la souris. Parcourez la page avec Tab : pouvez-vous atteindre et actionner chaque contrôle, l’indicateur de focus est-il toujours visible, l’ordre est-il logique ?
3. Zoom et réorganisation. Zoomez à 200 % et à 400 %. Rien ne doit se chevaucher, être tronqué ou exiger un défilement dans les deux dimensions.
4. Vérification ponctuelle au lecteur d’écran. Choisissez le parcours critique (inscription, paiement, tableau de bord principal) et réalisez-le avec un lecteur d’écran. Soyez attentif aux boutons sans libellé, aux erreurs non annoncées et à un ordre de lecture déroutant.
5. Vérification des préférences. Activez la réduction des animations, les couleurs forcées (contraste élevé de Windows) et le mode sombre, et vérifiez que rien d’important ne disparaît.

Faire durer les acquis

L’accessibilité se dégrade généralement par dérive : une fonctionnalité ajoutée des mois plus tard casse discrètement un piège à focus. Quelques habitudes permettent de l’éviter :

• Inscrivez des critères d’acceptation d’accessibilité dans les tickets, et non dans un backlog d’audit séparé.
• Intégrez les patterns aux composants partagés, pour que les équipes produit obtiennent le bon comportement par défaut.
• Publiez une déclaration d’accessibilité qui indique à quoi vous vous conformez, quels problèmes connus subsistent et comment signaler un problème.

Construire des sites web accessibles est un engagement de longue haleine, mais les outils et les patterns disponibles aujourd’hui le rendent atteignable pour toutes les équipes de développement. Partez du HTML sémantique, testez au clavier à chaque mise en production, et traitez chaque bug d’accessibilité avec le même sérieux que n’importe quel autre défaut qui empêche des utilisateurs d’accéder à votre service.