Créer des pages web accessibles

Une page accessible permet aux personnes d’obtenir des informations et d’accomplir des tâches avec les outils qu’elles utilisent. Ces outils peuvent comprendre un clavier, un lecteur d’écran, une loupe ou une commande vocale. Une page peut sembler terminée alors que son code bloque encore ces utilisateurs.

Ce que reçoit une technologie d’assistance

Le navigateur lit le HTML et construit le DOM, son modèle du document. Il en déduit un arbre d’accessibilité qui décrit les objets porteurs de sens aux technologies d’assistance. Un contrôle a besoin d’un rôle, d’un nom et des états ou propriétés pertinents. Par exemple, une case à cocher peut avoir le rôle « case à cocher », le nom « Offres par e-mail » et l’état « cochée ».

Un lecteur d’écran lit le contenu à voix haute ou l’envoie à une plage braille. NVDA et JAWS fonctionnent sur Windows ; Narrator est intégré à Windows, VoiceOver à macOS et iOS, et TalkBack à Android. Les lecteurs d’écran permettent de parcourir les titres, les liens et les contrôles sans lire chaque ligne. Certains peuvent aussi indiquer les réglages de police ou de couleur. Les loupes montrent la page visuelle agrandie : sa clarté compte donc aussi.

La commande vocale permet de prononcer le nom d’un contrôle, par exemple « cliquer sur Rechercher ». Les contacteurs peuvent envoyer des commandes semblables à celles d’un clavier. La prise en charge du clavier et des noms exacts aident donc plusieurs groupes d’utilisateurs, et pas seulement les personnes qui écoutent une synthèse vocale.

Commence par le bon élément

Compare ces deux façons de créer un contrôle d’enregistrement :

<button type="button">Save</button>
<div class="btn" onclick="save()">Save</div>

Le bouton expose déjà son rôle et son nom. Il reçoit le focus avec Tab et réagit à Entrée et à Espace. CSS peut rendre la deuxième ligne visuellement identique, mais un div ne possède aucun de ces comportements de bouton. Un lecteur d’écran peut déclencher son gestionnaire de clic en mode lecture, mais il n’annonce pas l’élément comme un bouton. Une personne qui navigue avec Tab ne peut pas l’atteindre.

Le HTML sémantique consiste à choisir un élément selon le sens du contenu ou du contrôle. Utilise CSS pour régler son apparence. Cela donne au navigateur une base solide et évite de devoir reconstruire le comportement natif avec un script.

Connais l’objectif

Le W3C publie les Règles pour l’accessibilité des contenus web, ou WCAG. Leurs critères de succès sont des exigences vérifiables, chacune désignée par un numéro, un nom et un niveau. Par exemple, 1.4.3 Contraste (minimum) est de niveau AA. Les WCAG 2.2 sont devenues une recommandation en octobre 2023 et ont été mises à jour en décembre 2024.

La conformité au niveau AA exige tous les critères de niveau A et de niveau AA. Réussir quelques vérifications AA ne suffit pas. Le niveau AAA ajoute d’autres exigences. Les WCAG 2.2 ajoutent neuf critères à la version 2.1, dont six de niveau A ou AA, et suppriment le critère obsolète 4.1.1 Analyse syntaxique.

L’accessibilité comprend aussi la lisibilité du texte agrandi, les sous-titres pour sourds et malentendants, des consignes claires et des erreurs utiles. Intégrer ces fonctionnalités à la page dès le début évite de devoir remplacer un HTML inadapté une fois la mise en page terminée.

Une structure de page utile donne plusieurs moyens de se repérer. Un titre descriptif identifie la page, les régions repères désignent ses zones et les titres révèlent son plan. Ces éléments ont besoin d’une véritable sémantique HTML, même lorsque la présentation visuelle semble déjà claire.

Identifie la page et sa langue

Définis la langue principale sur l’élément racine, par exemple <html lang="en-US">. Les lecteurs d’écran s’en servent pour choisir les règles de prononciation. Signale un changement de langue dans la page sur l’élément concerné : <span lang="fr">bon appétit</span>. Ces indications répondent aux critères 3.1.1 Langue de la page (A) et 3.1.2 Langue d’un passage (AA).

Donne à chaque page un <title> unique et descriptif. « Commander un gâteau d’anniversaire - Boulangerie Green Leaf » est plus utile dans les onglets, les favoris et les annonces des lecteurs d’écran que « Boulangerie Green Leaf - Page 4 ». Place le sujet précis en premier pour que les utilisateurs distinguent rapidement des onglets similaires.

Divise la page en régions

Utilise <main> pour le contenu principal, <nav> pour la navigation et <aside> pour le contenu complémentaire. Un <header> au niveau de la page fournit la région repère de bannière et un <footer> au niveau de la page fournit les informations sur le contenu. Les éléments d’en-tête et de pied de page imbriqués dans des régions de sectionnement ne deviennent pas ces régions repères de page.

Utilise un seul <main> visible. S’il y a deux régions de navigation, distingue-les par des noms comme <nav aria-label="Main"> et <nav aria-label="Breadcrumb">. Le rôle indique déjà « navigation » ; le nom peut donc rester court. Un <section> ou un <form> ne devient une région repère que s’il a un nom accessible.

Construis un plan avant de choisir les tailles de police

Pour la page de commande de la boulangerie, un plan clair pourrait être :

<h1>Order a birthday cake</h1>
<h2>Choose a size</h2>
<h2>Choose a flavor</h2>
<h3>Chocolate</h3>
<h3>Lemon</h3>
<h2>Pickup or delivery</h2>

Utilise un h1 pour le sujet principal, des h2 pour les sections principales et des h3 pour leurs parties. Évite de sauter des niveaux en descendant. Choisis les niveaux de titre selon la structure ; ajuste leur taille avec CSS. Un paragraphe en gras n’entre pas dans la liste des titres du lecteur d’écran. À l’inverse, placer une introduction ordinaire dans un h2 ajoute une section que le contenu ne possède pas.

Préserve les regroupements et l’ordre de lecture

Utilise <ul> pour les éléments non ordonnés, <ol> pour les étapes ordonnées et <dl> pour les paires terme-description. Les lecteurs d’écran peuvent annoncer la taille d’une liste, ce qui aide les utilisateurs à évaluer la quantité de contenu qui suit. Les liens de navigation peuvent se trouver dans un ul à l’intérieur de nav. Dans Safari, supprimer les puces avec list-style: none peut empêcher VoiceOver d’annoncer les listes ; role="list" sur la liste rétablit cette annonce.

Écris le HTML dans un ordre de lecture qui a un sens. La propriété order de Flexbox, l’inversion de sa direction, le placement dans une grille et le positionnement absolu changent ce que les personnes voient sans changer l’ordre du DOM. Une rangée qui commence visuellement par « Se connecter » mais où Tab n’atteint cet élément qu’en dernier est plus difficile à suivre. Corrige l’ordre dans le code source avant de disposer les éléments.

Examine une structure de page

Le site d’une boulangerie comporte un menu principal et un second ensemble de liens pour le fil d’Ariane. Donne des noms distincts aux régions tout en conservant les deux ensembles de liens :

<nav aria-label="Main">
  <ul><li><a href="/bread">Bread</a></li></ul>
</nav>
<nav aria-label="Breadcrumb">
  <ol><li><a href="/">Home</a></li></ol>
</nav>
<main>
  <h1>Order a loaf</h1>
  <h2>Choose your bread</h2>
</main>

Inspecte la liste des régions repères : Main et Breadcrumb désignent des fonctions de navigation différentes, suivies du contenu principal. Inspecte ensuite la liste des titres : elle doit montrer le sujet de la page et sa première section. Ces deux listes offrent des parcours différents dans le même document ; aucune ne dépend des couleurs du menu ni de la taille de police du titre.

L’élément utilisé pour un contrôle indique aux utilisateurs à quoi s’attendre. Un lien annonce une destination ; un bouton annonce une action. Les contrôles et les éléments de tableau natifs fournissent aussi des relations qu’il serait difficile de recréer à partir de boîtes génériques mises en forme.

Choisis entre navigation et action

Une ancre sans href n’est pas un lien ordinaire pouvant recevoir le focus clavier. Une ancre avec href="#" et un gestionnaire de clic qui ouvre un menu annonce une navigation alors qu’elle effectue une action. Utilise un bouton pour ce menu. Dans un formulaire, donne type="button" aux boutons qui ne doivent pas l’envoyer ; sinon, leur comportement par défaut peut envoyer le formulaire.

Rends les destinations claires

Un lecteur d’écran peut rassembler les liens de la page dans une liste. Des liens répétés « En savoir plus » y sont difficiles à distinguer. « Découvrir les cours de pain au levain » nomme directement la destination. Le critère WCAG 2.4.4 Fonction du lien (selon le contexte) (A) autorise le contexte proche à expliquer un lien, mais un intitulé explicite est aussi compréhensible lorsqu’il est entendu seul.

Signale un téléchargement ou un nouvel onglet dans l’intitulé du lien : « Liste des prix (PDF, 2 Mo) » ou « Formulaire de réservation (s’ouvre dans un nouvel onglet) ». Un nouvel onglet modifie le fonctionnement du bouton Retour. Utilise une description plutôt qu’une longue URL brute lorsque c’est possible.

Chaque lien et chaque bouton a besoin d’un nom accessible. Un lien vers le panier composé uniquement d’une image a besoin d’un texte qui indique sa destination ; une image sans alternative peut laisser un lien sans nom ou identifié par un nom de fichier. Nommer le contrôle est aussi nécessaire que choisir le bon rôle.

Conserve le comportement intégré

Utilise les cases à cocher, les boutons radio et les contrôles select natifs. Ils fonctionnent au clavier et leurs états sont annoncés. Une zone dépliable simple peut utiliser uniquement du HTML :

<details>
  <summary>Delivery options</summary>
  <p>We deliver within 10 km.</p>
</details>

Le résumé reçoit le focus clavier et la zone dépliable expose son état ouvert ou fermé. Une rangée personnalisée avec une icône triangulaire nécessiterait d’implémenter ces fonctionnalités séparément.

Associe les données d’un tableau à leurs en-têtes

Utilise des tableaux pour les données qui présentent des relations entre lignes et colonnes. Un titre de tableau nomme l’ensemble de données ; th identifie les en-têtes ; scope indique au navigateur quelles cellules un en-tête décrit.

<table>
  <caption>Shop opening hours</caption>
  <tr><th scope="col">Day</th><th scope="col">Opens</th></tr>
  <tr><th scope="row">Saturday</th><td>08:00</td></tr>
</table>

Une personne qui se déplace vers la cellule de l’heure peut entendre le jour et l’en-tête de colonne associés. Une grille CSS composée d’éléments div perd ces relations intégrées. Pour la mise en page, utilise Flexbox ou une grille CSS ; un tableau de mise en page peut créer une navigation trompeuse dans un tableau là où il n’existe aucune véritable relation entre les données.

L’alternative textuelle transmet l’information utile ou la fonction d’une image à une personne qui ne peut pas la voir. Détermine ce que l’image apporte sur cette page précise avant de décrire son apparence. Une même photographie peut nécessiter des textes différents selon le contexte.

Choisis selon la fonction

Pour une photographie informative de produit, alt="Round sourdough loaf with a dark, cracked crust" décrit ce qu’un acheteur doit savoir. Sur une page consacrée aux défauts de cuisson, l’élément important pourrait plutôt être une croûte brûlée. Imagine que tu lis la page au téléphone : inclus l’information que la personne qui écoute manquerait autrement.

Pour une image purement décorative, utilise alt="". Une alternative vide indique aux lecteurs d’écran de passer l’image. Omettre l’attribut est différent : un lecteur d’écran peut annoncer un nom de fichier comme « IMG tiret bas 4032 point jpg ». Un arrière-plan purement décoratif peut aussi être placé en CSS.

Nomme une fonction, pas une forme

Lorsqu’une image est le seul contenu d’un lien ou d’un bouton, son alternative fournit le nom du contrôle. Un lien vers l’accueil peut être :

<a href="/">
  <img src="logo.svg" alt="Green Leaf Bakery home">
</a>

Pour un bouton de recherche, utilise « Rechercher », et non « Loupe ». L’utilisateur doit savoir ce que l’activation du contrôle va faire. Si un lien de produit contient déjà les mots visibles « Pain de seigle », une photo dans ce même lien peut utiliser alt="" pour que le nom du lien ne soit pas répété.

Traite le texte et les graphiques complexes

Une image de texte doit contenir les mêmes mots dans son alternative. Une bannière de soldes portant « Soldes d’été : 20 % de réduction sur tous les pains » a besoin de ces mots, et non de « Bannière de soldes ». Privilégie du vrai texte HTML mis en forme avec CSS lorsque c’est possible. Il peut être redimensionné, traduit et redistribué ; le critère WCAG 1.4.5 Images de texte (AA) exige du vrai texte lorsque la technologie le permet, avec des exceptions comme les logos.

Un graphique, un diagramme ou une carte contient souvent trop d’informations pour une alternative courte. Donne-lui une brève identification, puis fournis une description plus complète à proximité. Par exemple, alt="Bar chart of monthly website visitors, January to June" identifie le graphique. Le texte à proximité peut expliquer que le nombre de visiteurs est passé de 1 200 à 3 000, tandis qu’un tableau de données fournit les valeurs individuelles lorsqu’elles sont nécessaires. Un <figure> avec <figcaption> peut regrouper le graphique et son explication.

Sélectionne les détails utiles

Limite une alternative textuelle ordinaire à une expression ou une phrase concise. Les lecteurs d’écran identifient déjà une image ; commencer par « Image de » n’ajoute donc généralement rien d’utile. Supprime les mots répétés juste à côté et les mots-clés de recherche qui n’aident pas la personne à comprendre la page.

Le critère WCAG 1.1.1 Contenu non textuel (A) exige une fonction équivalente, et non une description de chaque détail visible. L’attribut title n’est pas un remplacement fiable : il n’est pas annoncé de façon systématique ni disponible lors de l’utilisation au clavier et au tactile. Place l’alternative d’une image dans alt et garde toute explication plus longue dans la page elle-même.

Une icône, un diagramme et une vidéo nécessitent des alternatives différentes. Commence par identifier l’information ou l’action que chacun apporte. Place ensuite l’équivalent là où le navigateur et la personne utilisant la page peuvent le trouver.

Nomme le contrôle qui contient l’icône

Un texte visible à côté d’une icône est généralement plus clair. Si un bouton doit contenir uniquement une icône, fournis un texte masqué visuellement ou une étiquette sur le bouton :

<button type="button" aria-label="Close">✕</button>

Lorsqu’une icône se trouve à côté du texte visible d’un bouton, masque l’icône décorative avec aria-hidden="true". Ne masque pas le bouton entier. Un simple span ou div possède un rôle générique qu’il est interdit de nommer ; y placer aria-label n’est pas un moyen fiable de nommer une icône.

Le texte masqué visuellement reste accessible aux lecteurs d’écran. Une classe CSS réutilisable peut utiliser un positionnement absolu, une largeur et une hauteur de 1 px, un débordement masqué, clip-path: inset(50%) et white-space: nowrap. Contrairement à display: none ou visibility: hidden, elle conserve le texte dans l’arbre d’accessibilité.

Pour un SVG intégré au code et porteur de sens, utilise role="img" et un nom, par exemple aria-labelledby="rating-title" faisant référence à <title id="rating-title">Rated 4 out of 5 stars</title> à l’intérieur du SVG. Un SVG décoratif utilise aria-hidden="true". Un SVG chargé par img reçoit son alternative de alt, comme les autres images. Garde les avertissements porteurs de sens dans le HTML ; les arrière-plans CSS et le contenu généré ne sont pas des emplacements fiables pour les informations essentielles.

Choisis l’alternative adaptée au média

Les sous-titres pour sourds et malentendants synchronisent les paroles, les sons importants et l’identification des personnes qui parlent avec la vidéo. Les sous-titres transcrivent ou traduisent les dialogues pour les personnes qui entendent mais ont besoin d’aide pour comprendre la langue. Une transcription textuelle est un compte rendu séparé ; elle ne suit pas le temps de lecture.

<video controls src="bread.mp4">
  <track kind="captions" src="bread-en.vtt"
         srclang="en" label="English">
</video>

Le fichier WebVTT contient des repères synchronisés, comme 00:00:01.000 --> 00:00:04.000, suivis du texte des sous-titres. Vérifie les noms, les termes techniques et la ponctuation des sous-titres automatiques avant publication.

Si une démonstration montre silencieusement un réglage du four, les sous-titres des paroles ne le transmettent pas. L’audiodescription raconte les informations visuelles importantes pendant les pauses ou dans une version audiodécrite. Une alternative textuelle complète incluant les éléments visuels est une option au niveau A ; une vidéo préenregistrée nécessite une audiodescription au niveau AA selon le critère 1.2.5.

Garde la lecture utilisable

Utilise les controls natifs pour le son et la vidéo, et donne aux cadres intégrés un title descriptif, comme « Carte de l’emplacement de notre boutique ». Évite le son en lecture automatique. Un son qui démarre automatiquement et dure plus de 3 secondes doit pouvoir être mis en pause ou arrêté, ou son volume réglé indépendamment du volume général du système.

Associe le nom masqué et le texte synchronisé

Pour un bouton de suppression compact, garde ses mots dans le document :

<button type="button">
  <img src="trash.svg" alt="">
  <span class="visually-hidden">Delete item</span>
</button>

L’image est sautée parce que le texte indique déjà l’action. Applique la classe de masquage sans retirer ce texte de l’arbre d’accessibilité :

.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

Un fichier de sous-titres associe quant à lui des mots au temps de lecture. Voici un petit exemple WebVTT :

WEBVTT

00:00:01.000 --> 00:00:03.000
[Mixer whirring]

00:00:03.000 --> 00:00:06.000
Today we bake rye bread.

Le premier repère transmet un son pertinent sans dialogue. Le second transmet des paroles pendant son propre intervalle. Regarde la vidéo avec la piste activée et vérifie que chaque repère apparaît au moment où son son se produit.

Les utilisateurs du clavier ont besoin d’un parcours couvrant toute la tâche : atteindre un contrôle, le reconnaître, l’actionner et poursuivre. Les contrôles HTML standard prennent déjà en charge ce parcours. Les problèmes apparaissent souvent lorsque la mise en forme ou des contrôles personnalisés perturbent le comportement du navigateur.

Utilise les touches attendues

Tab avance entre les éléments interactifs ; Maj+Tab revient en arrière. Entrée suit les liens et active les boutons. Espace active les boutons et coche ou décoche les cases. Dans un groupe de boutons radio, Tab permet d’entrer dans le groupe ou d’en sortir et les flèches permettent de passer d’une option à l’autre. Les flèches fonctionnent aussi dans les listes de sélection natives. Échap ferme les boîtes de dialogue et de nombreux menus.

Les liens avec href, les boutons, les champs de saisie, les listes de sélection, les zones de texte multiligne, les éléments summary et les médias avec commandes peuvent recevoir le focus par défaut. Les paragraphes, les titres, les images, les conteneurs génériques et les ancres sans href ne sont pas des arrêts de tabulation ordinaires. Un lecteur d’écran possède des commandes de lecture distinctes pour le texte : ajouter chaque titre à l’ordre de tabulation ralentit donc la navigation au clavier.

Sur macOS, active la navigation au clavier pour les tests. Le réglage Safari « Appuyer sur Tab pour mettre en surbrillance chaque élément d’une page web » détermine si la navigation ordinaire avec Tab atteint les liens ; Option+Tab peut les atteindre lorsque ce réglage est désactivé.

Garde des valeurs tabindex simples

Les valeurs positives sont difficiles à maintenir parce qu’elles créent un second système d’ordre. Écris le HTML dans un ordre logique et évite-les. Un titre qui doit recevoir le focus après une mise à jour peut utiliser -1 sans devenir un arrêt à chaque parcours de la page.

Vérifie ensemble le sens et le comportement

<div role="button" tabindex="0">Save</div>

Cet élément expose un rôle de bouton et reçoit le focus, mais il lui faut encore un script pour Entrée et Espace, une action et un style de focus visible. Le remplacer par <button type="button">Save</button> fournit l’activation native au clavier sans avoir à la reconstruire. ARIA seul ne peut pas créer l’interaction.

CSS peut aussi perturber la navigation. Si l’ordre dans le code source est logo, menu, recherche, lien de connexion, la propriété CSS order: -1 peut afficher la connexion en premier alors que Tab ne l’atteint qu’en dernier. Déplace le contenu dans le HTML lorsque l’ordre de lecture doit changer. Le critère WCAG 2.4.3 Parcours du focus (A) exige un ordre qui préserve le sens et l’utilisation.

Supprime les pièges et les arrêts masqués

Teste si le focus peut quitter chaque composant au clavier. Une carte ou un lecteur qui accepte le focus mais ne permet pas d’en sortir au clavier crée un piège au clavier, interdit par le critère 2.1.2 Pas de piège au clavier (A).

Un menu fermé déplacé hors de l’écran ou doté de opacity: 0 peut encore contenir des liens pouvant recevoir le focus. Utilise hidden, display: none ou inert pour le contenu qui doit être indisponible tant qu’il est fermé. Garde toutefois accessible au focus un lien d’évitement hors écran : une règle prévue à cet effet le rend visible lorsqu’il reçoit le focus.

Le focus indique la position courante de l’utilisateur du clavier. Un contour visible lui indique quel contrôle sera actionné par Entrée ou Espace. Le contour doit rester visible sur la page et le contrôle ayant le focus doit rester à l’écran.

Garde un indicateur clair

Les navigateurs fournissent un contour de focus par défaut. Le supprimer avec outline: none fait perdre une indication essentielle, sauf si un remplacement adapté est fourni. Utilise :focus-visible pour afficher un contour lorsque le navigateur le juge utile, notamment pendant la navigation au clavier et dans les champs de texte :

:focus-visible {
  outline: 3px solid #1A73E8;
  outline-offset: 2px;
}

Le bleu présente un contraste de 4,51:1 sur blanc. Vérifie les couleurs réellement adjacentes dans la mise en page ; un contour qui fonctionne sur blanc peut se confondre avec un panneau bleu. Le critère WCAG 2.4.7 Visibilité du focus (AA) exige un focus clavier visible, tandis que 1.4.11 Contraste du contenu non textuel (AA) s’applique aux informations visuelles qui identifient un état personnalisé, notamment un indicateur de focus personnalisé, avec un rapport de 3:1.

Un contour est un choix utile pour les thèmes de contraste Windows. Les couleurs forcées peuvent remplacer les arrière-plans et supprimer les ombres de boîte, tandis que les contours restent disponibles. Une ombre seule peut donc disparaître dans un mode dont une personne dépend.

Garde le contrôle ayant le focus à l’écran

Les en-têtes adhérents, les bannières et les contrôles de discussion peuvent masquer le focus. Selon le critère 2.4.11 Focus non masqué (minimum) (AA), un contenu créé par l’auteur ne doit pas entièrement cacher le composant ayant le focus. Garder tout le composant visible facilite son utilisation ; l’exigence selon laquelle aucune partie ne doit être masquée appartient au niveau AAA.

Pour un en-tête adhérent de 5rem de haut, prévois un espace de défilement :

html { scroll-padding-top: 5rem; }

Parcours ensuite la page réelle avec Tab. Vérifie les deux directions et teste lorsqu’une bannière de cookies est présente. La règle CSS est un point de départ ; elle doit encore fonctionner avec les dimensions réelles de l’en-tête et de la zone d’affichage de la page.

Laisse aussi de la place aux utilisateurs du pointeur

Le critère Taille de la cible (minimum), 2.5.8 (AA), exige des cibles du pointeur d’au moins 24 px CSS sur 24, avec des exceptions. Une cible plus petite peut être conforme si un cercle de 24 px de diamètre centré sur elle ne croise ni une autre cible ni le cercle d’une autre petite cible. Les liens dans une phrase, les contrôles non modifiés dont le navigateur fixe la taille et les cibles ayant un contrôle équivalent conforme sur la page sont aussi exemptés. Une présentation essentielle ou légalement requise peut également être exemptée.

Pour trois boutons avec icône de 16 px sur 16 séparés par des espaces de 4 px, les cercles se chevaucheraient. Ajouter une marge intérieure de 4 px de chaque côté donne à chaque cible une taille de 24 px sur 24. Mesure toute la zone cliquable, pas seulement l’icône dessinée à l’intérieur.

La cible de 44 px CSS sur 44 du critère 2.5.5 et l’exigence de surface du focus du critère 2.4.13 sont des exigences AAA. Ce sont des améliorations utiles, mais distingue leur niveau du minimum AA lorsque tu consignes un résultat.

Les menus répétés ne devraient pas obliger les personnes à refaire le même parcours sur chaque page. Un lien d’évitement fournit un chemin court vers le contenu principal. Lorsqu’une interaction modifie la page, une gestion réfléchie du focus aide aussi à garder sa place.

Crée et teste un lien d’évitement

Place le lien d’évitement avant les contrôles répétés de l’en-tête :

<a class="skip-link" href="#main">Skip to main content</a>
<main id="main" tabindex="-1">
  <h1>Order a birthday cake</h1>
</main>

Le lien cible la région principale, et tabindex="-1" aide cette région à recevoir le focus sans ajouter un arrêt de tabulation ordinaire. La navigation par régions repères d’un lecteur d’écran aide ses utilisateurs ; le lien d’évitement aide aussi les utilisateurs voyants du clavier à passer les blocs répétés selon le critère 2.4.1 Contourner des blocs (A).

Garde le lien accessible au clavier lorsqu’il est masqué visuellement :

.skip-link { position: absolute; left: -9999px; }
.skip-link:focus { left: 1rem; top: 1rem; }

N’utilise pas display: none ou visibility: hidden, qui empêchent le focus. Recharge la page, appuie une fois sur Tab et vérifie que le lien apparaît. Appuie sur Entrée, puis de nouveau sur Tab : la navigation doit continuer au premier lien ou contrôle du contenu principal, et non au menu de l’en-tête.

Donne une position suivante adaptée au contenu modifié

Si une ligne du panier et son bouton Supprimer ayant le focus disparaissent ensemble, le focus peut revenir au début de la page. Déplace-le volontairement vers le bouton Supprimer de l’article suivant ou vers un titre du panier doté de tabindex="-1". Choisis un endroit qui permet de poursuivre la tâche. Faire simplement défiler la page jusqu’à une région ne garantit pas que le focus clavier s’y est déplacé.

Utilise une boîte de dialogue modale native

Une boîte de dialogue ouverte avec showModal() déplace le focus à l’intérieur et rend le reste de la page inerte. Tab reste à l’intérieur tant que la boîte est ouverte ; Échap la ferme. La fermeture ramène normalement le focus à l’élément qui l’a ouverte, s’il existe toujours.

<button type="button"
  onclick="document.getElementById('hours').showModal()">Opening hours</button>
<dialog id="hours" aria-labelledby="hours-title">
  <h2 id="hours-title">Opening hours</h2>
  <p>Tuesday to Saturday, 08:00–17:00.</p>
  <form method="dialog"><button>Close</button></form>
</dialog>

Le script d’une ligne trouve la boîte de dialogue par son identifiant et l’ouvre en mode modal. Le formulaire de la boîte la ferme sans autre script. Son titre lui fournit son nom. Un calque fait maison exige de recréer toutes ces règles d’interaction ; assombrir l’arrière-plan n’empêche pas le focus clavier de l’atteindre.

Attends une action volontaire

Recevoir le focus ne doit pas ouvrir une nouvelle page ni changer le contexte d’une autre façon. Modifier une sélection ne doit pas non plus le faire de manière inattendue ; les utilisateurs doivent être prévenus si ce comportement se produit. Un bouton « Aller » après un sélecteur de destination laisse aux personnes le temps d’examiner et de modifier leur choix avant de naviguer. Ces comportements répondent aux critères 3.2.1 Au focus (A) et 3.2.2 À la saisie (A).

Le contraste mesure à quel point une information au premier plan se distingue clairement de son arrière-plan. Une couleur qui semble lisible sur un écran peut être difficile à lire pour une personne malvoyante ou en pleine lumière. Mesure la paire au lieu de la juger à l’œil.

Applique le bon minimum

Un texte de grande taille mesure au moins 18 points, soit 24 px CSS, ou au moins 14 points en gras, soit environ 18,7 px CSS en gras. Un titre de 20 px en graisse normale nécessite toujours 4,5:1. Le texte indicatif, le texte du pied de page et le texte aux états de survol et de focus ne sont pas exemptés du contraste du texte. Les logos, les contrôles inactifs et le texte accessoire ou purement décoratif bénéficient d’exceptions.

Comprends le rapport

La luminance relative exprime la luminosité sur une échelle allant de 0 pour le noir à 1 pour le blanc. En prenant la luminance la plus claire pour L1 et la plus foncée pour L2, le rapport est :

Les extrêmes sont 1:1 pour des couleurs identiques et 21:1 pour du noir sur blanc. Un outil de vérification du contraste calcule la luminance à partir des canaux de couleur et compare le rapport au seuil pertinent.

Pour le gris #767676, chaque canal vaut 76 en hexadécimal, soit 118. Divise par 255 pour obtenir environ 0,4627. Comme ce nombre est supérieur à 0,04045, convertis-le en lumière linéaire :

Les trois canaux sont égaux : leur luminance pondérée est donc aussi d’environ 0,1812. Le blanc a une luminance de 1. En gardant toutes les décimales pendant le calcul, on obtient 4,54:1, ce qui est conforme pour le texte normal. Utilise un outil de vérification pour les paires de couleurs réelles afin que des valeurs intermédiaires arrondies n’influencent pas un résultat proche du seuil.

N’arrondis jamais un échec jusqu’à la conformité

Le gris #777777 sur blanc donne 4,48:1. L’afficher à une décimale sous la forme 4,5 ne le rend pas conforme. De même, #949494 sur blanc donne 3,03:1 et est conforme pour le texte de grande taille ; #959595 donne 2,99:1 et n’est pas conforme pour le texte de grande taille.

Le blanc sur #0066CC donne 5,57:1. Sur l’ambre #FFC107, le texte blanc donne seulement 1,63:1, tandis que le noir donne 12,88:1. Choisir un arrière-plan de bouton lumineux ne permet pas de savoir si son texte doit être clair ou foncé.

Vérifie les contours et chaque arrière-plan

La bordure d’un champ nécessaire pour l’identifier doit respecter le contraste du contenu non textuel. #CCCCCC sur blanc donne 1,61:1 et n’est pas conforme ; #949494 donne 3,03:1 et est conforme. La même règle de 3:1 s’applique aux icônes porteuses de sens, aux lignes des graphiques et aux indicateurs de focus personnalisés. Les contrôles inactifs et les contrôles par défaut du navigateur non modifiés bénéficient d’exceptions.

Le texte placé sur une photo ou un dégradé doit être conforme au point le moins contrasté de son arrière-plan. Ajoute un panneau uni ou suffisamment opaque, ou déplace le texte. Vérifie les couleurs obtenues avec les outils de développement ou un outil de vérification du contraste. Le critère WCAG 1.4.3 concerne le texte et 1.4.11 les informations non textuelles ; les seuils AAA pour le texte sont plus élevés : 7:1 pour le texte normal et 4,5:1 pour le texte de grande taille.

Vérifie séparément les parties d’un bouton

Supposons qu’un bouton porte un texte blanc de taille normale sur #0066CC, se trouve sur une page blanche et utilise un contour de focus personnalisé #CCCCCC. Vérifie chaque rapport :

1. L’étiquette sur le bouton bleu donne 5,57:1, au-dessus du minimum de 4,5:1 pour le texte.
2. Le bouton bleu sur la page blanche donne aussi 5,57:1 : son contour est donc distinct.
3. Le contour de focus gris clair sur la page blanche ne donne que 1,61:1. Cet indicateur d’état n’est pas conforme, même si l’étiquette l’est.

Remplace le contour par une couleur qui atteint 3:1 avec son arrière-plan adjacent, puis mesure de nouveau. Une mesure du contraste de l’étiquette du bouton ne mesure pas aussi chaque contour ou état d’interaction. Vérifie séparément les paires de couleurs du texte, du composant et de l’état personnalisé.

La couleur peut attirer l’attention, mais elle ne peut pas être le seul indice visible du sens. Les personnes peuvent avoir une déficience de la vision des couleurs, utiliser les niveaux de gris ou des réglages de contraste, ou écouter le contenu avec un lecteur d’écran qui n’annonce pas les couleurs. Associe la couleur à du texte, des formes, des motifs ou une autre indication claire.

Sépare deux vérifications

Le contraste concerne la possibilité de distinguer un premier plan de son arrière-plan. L’utilisation de la couleur, WCAG 1.4.1 (A), concerne la compréhension de l’information sans reconnaissance de la couleur. Une étiquette rouge foncé sur blanc peut respecter le contraste tout en ne permettant pas de comprendre quel champ comporte une erreur.

Commence par le message. Si la page dit « Choisis une option verte », donne aussi un nom utile à chaque option. Si un point rouge signifie qu’une boutique est fermée, ajoute « Actuellement fermé » à côté. Le texte indique l’état, tandis que la couleur aide à le remarquer.

Garde les liens reconnaissables

Le moyen le plus simple d’identifier un lien dans un paragraphe est de le souligner. Cela fournit une indication même lorsque le lien et le texte environnant sont vus en niveaux de gris.

Une différence fondée uniquement sur la couleur par rapport au texte environnant exige un contraste d’au moins 3:1 entre les deux couleurs de texte et une indication supplémentaire, comme un soulignement, au survol et au focus. Le texte du lien doit aussi respecter le contraste du texte avec son arrière-plan. Ce sont des comparaisons distinctes ; un bleu conforme sur blanc peut être trop proche du texte sombre du paragraphe voisin.

Explique les erreurs et les champs obligatoires

Pour une erreur d’adresse e-mail, affiche « Erreur : saisis une adresse e-mail au format nom@exemple.com » à côté du champ. Un contour rouge peut rester comme indication supplémentaire. Le texte identifie le problème et indique à l’utilisateur comment le corriger, tandis que le code l’associe au champ.

Pour les champs obligatoires, utilise une étiquette comme « Adresse e-mail (obligatoire) ». Un astérisque convient aussi lorsque le début du formulaire explique « * signifie obligatoire ». Ajoute l’attribut natif required pour que cette obligation soit disponible pour les technologies d’assistance et la validation du navigateur. Le texte rouge d’une étiquette ne fournit à lui seul ni explication visible suffisante ni obligation exprimée dans le code.

Donne aux graphiques un second moyen de communiquer

Un graphique de ventes comportant deux séries nécessite plus qu’une ligne rouge et une ligne verte. Des indications directes, des styles de trait ou des motifs différents permettent de suivre chaque série sans identifier sa teinte. Utilise ces indications dans le graphique et sa légende pour qu’elles correspondent.

Vérifie la page avec l’émulation des niveaux de gris ou des déficiences de la vision des couleurs dans les outils de développement. Inspecte les liens dans le texte courant, les erreurs, les champs obligatoires, les graphiques et les indicateurs de disponibilité. Demande-toi quel indice visible reste pour chaque distinction. Si une distinction disparaît, ajoute une indication qui exprime ou représente son sens ; augmenter la saturation seule ne fournira pas l’information manquante.

Agrandir une page devrait la rendre plus facile à utiliser sans masquer les contrôles ni couper les phrases. Les personnes peuvent agrandir toute la page, agrandir seulement le texte ou appliquer leur propre espacement. Des mises en page souples permettent de combiner ces choix.

Teste la taille du texte et la redistribution

Le critère WCAG 1.4.4 Redimensionnement du texte (AA) exige que le texte puisse être agrandi à 200 % sans perte de contenu ou de fonctionnalité. Le zoom du navigateur utilise Ctrl et plus sur Windows ou Cmd et plus sur macOS. Teste aussi une taille de police par défaut plus grande, qui modifie le texte sans agrandir tout le reste de la même façon.

Le critère WCAG 1.4.10 Redistribution du contenu (AA) exige que le contenu ordinaire fonctionne à une largeur de 320 px CSS sans défilement dans deux directions. Une fenêtre de 1 280 px CSS de large avec un zoom à 400 % fournit cette largeur effective. Les paragraphes doivent se répartir dans une colonne étroite, avec toutes les fonctionnalités toujours disponibles. Les tableaux de données, les cartes et les autres contenus dont le sens nécessite deux dimensions bénéficient d’exceptions.

Laisse la mise en page grandir avec le texte

Utilise des unités de police relatives comme rem et em afin que le texte suive le réglage de police par défaut de l’utilisateur. Le texte en pixels CSS réagit toujours au zoom du navigateur, mais ne suit pas ce réglage par défaut de la même façon. Les conteneurs souples et max-width permettent aux lignes de se réorganiser ; les points de rupture en em peuvent s’adapter lorsque le texte grandit.

Une hauteur fixe peut couper le contenu sans avertissement :

/* Problem when larger text needs more space */
.card { height: 200px; overflow: hidden; }

/* Content can grow beyond the minimum */
.card { min-height: 200px; }

Laisse le contenu déterminer sa hauteur. Aux petites largeurs, empile la navigation ou propose une zone dépliable accessible au lieu de supprimer des liens. Laisse un en-tête adhérent trop grand défiler hors de l’écran s’il occupe trop de place dans la zone utilisable.

Garde le zoom mobile disponible

Utilise une déclaration de zone d’affichage qui suit la largeur de l’appareil :

<meta name="viewport" content="width=device-width, initial-scale=1">

N’ajoute pas maximum-scale=1 ou user-scalable=no. Ces valeurs cherchent à bloquer le zoom par pincement, dont les personnes malvoyantes peuvent avoir besoin. Certains navigateurs ignorent ces restrictions, mais les utilisateurs ne devraient pas avoir à compter sur ce comportement.

Applique l’espacement de l’utilisateur

Le critère WCAG 1.4.12 Espacement du texte (AA) exige qu’aucun contenu ne soit perdu ni ne se chevauche lorsque les utilisateurs fixent la hauteur de ligne à 1,5 fois la taille de police, l’espacement des paragraphes à 2 fois, l’espacement des lettres à 0,12 fois et l’espacement des mots à 0,16 fois. Ce sont des réglages de test, et non des valeurs de conception par défaut obligatoires. Utilise un outil d’espacement du texte et vérifie les étiquettes, les cartes, les menus et les boutons ainsi que les paragraphes.

Une vérification pratique combine un test du texte à 200 %, un test de redistribution à 320 px CSS et la personnalisation de l’espacement. Recherche les lignes coupées, les étiquettes superposées, le défilement horizontal des paragraphes et les fonctionnalités disparues. Corrige le conteneur ou la mise en page à l’origine du problème ; réduire le texte agrandi par l’utilisateur supprime le bénéfice qu’il recherchait.

Une étiquette visible indique à une personne quoi saisir et donne un nom accessible à un champ. Les légendes de groupe ajoutent la question à laquelle plusieurs choix répondent. Les associations doivent exister dans le HTML, même lorsque les étiquettes et les champs paraissent déjà proches.

Associe une étiquette à un contrôle

Une étiquette explicite utilise for pour faire référence à l’id unique du contrôle :

<label for="email">Email address</label>
<input id="email" name="email" type="email">

Le navigateur peut annoncer « Email address » au focus. Cliquer sur le texte donne aussi le focus au champ, ce qui offre aux utilisateurs une cible plus grande. L’attribut name identifie les données envoyées ; il ne remplace pas l’id utilisé par l’étiquette.

Une étiquette implicite englobe son champ : <label>Email address <input type="email" name="email"></label>. Cela fonctionne lorsque les deux tiennent dans le même élément d’étiquette. Avec des conteneurs de mise en page séparés, l’association explicite est plus facile à maintenir.

Un texte indicatif disparaît pendant la saisie et présente souvent un faible contraste. Garde l’étiquette visible et place des exemples ou des indications de format à proximité. « Champ 1 » est techniquement un nom, mais ne décrit pas la fonction. Le critère WCAG 2.4.6 En-têtes et étiquettes (AA) exige une formulation descriptive.

Garde les mots visibles dans le nom

Une personne utilisant une commande vocale peut dire « cliquer sur Send » après avoir vu un bouton Send. Si aria-label="Submit form" remplace le texte de ce bouton, son nom accessible ne contient plus les mots visibles. Le critère WCAG 2.5.3 Étiquette dans le nom (A) exige que ces mots soient inclus, idéalement au début. Utilise le texte visible lui-même lorsque c’est possible : <button type="submit">Send message</button>.

Un champ de recherche isolé peut avoir une étiquette masquée visuellement si un bouton Rechercher à proximité rend sa fonction visuellement claire. Les étiquettes masquées ne remplacent pas de manière générale les consignes visibles dans l’ensemble d’un formulaire.

Regroupe les choix sous leur question

<fieldset>
  <legend>Delivery method</legend>
  <input type="radio" id="pickup" name="delivery" value="pickup">
  <label for="pickup">Pick up in store</label>
  <input type="radio" id="courier" name="delivery" value="courier">
  <label for="courier">Courier delivery</label>
</fieldset>

La légende fournit la question du groupe ; chaque bouton radio a toujours besoin de sa propre étiquette. Les lecteurs d’écran peuvent annoncer le contexte du groupe avec une option. Utilise le même name pour les boutons radio correspondant à des choix mutuellement exclusifs, et des légendes courtes qui restent utiles lorsqu’elles sont répétées. Des cases à cocher liées peuvent aussi utiliser un groupe de champs et une légende.

Choisis les types et vérifie les associations

Utilise email, tel, url et date pour les données correspondantes. Les types e-mail et URL fournissent une vérification du format ; les champs de téléphone peuvent proposer un clavier mobile adapté, mais ne valident pas les formats de numéro de téléphone. Utilise number pour les quantités comme le nombre d’invités, et non pour les identifiants tels que les numéros de téléphone ou de carte.

Clique sur chaque étiquette pour tester son association. Si le mauvais champ reçoit le focus, vérifie si des identifiants sont dupliqués ou si un for ne correspond pas. Inspecte aussi le nom calculé dans les outils de développement ; la proximité visuelle seule ne peut pas associer une étiquette.

Les consignes sont plus utiles lorsqu’elles arrivent avant une erreur. Un bon formulaire explique la saisie attendue, indique ce qui est obligatoire et prend en charge les outils du navigateur pour saisir les informations personnelles. Il évite aussi de faire répéter inutilement le travail aux utilisateurs.

Associe une aide sans remplacer l’étiquette

<label for="pw">Password (required)</label>
<input id="pw" type="password" required
       autocomplete="new-password" aria-describedby="pw-hint">
<p id="pw-hint">At least 12 characters.</p>

L’étiquette nomme le champ. Le paragraphe visible explique son exigence, et aria-describedby ajoute ce texte comme description. Les lecteurs d’écran peuvent l’annoncer après le nom. Pour plusieurs descriptions, liste leurs identifiants séparés par des espaces, comme dans aria-describedby="pw-hint pw-error".

Signale les champs obligatoires visiblement et avec required. Tu peux écrire « (obligatoire) » ou expliquer un astérisque au début du formulaire. L’attribut natif required prend en charge la validation du navigateur et les technologies d’assistance ; il n’a pas besoin d’un aria-required="true" supplémentaire.

Identifie la fonction des données personnelles

Selon le critère 1.3.5 Identifier la fonction des champs de saisie (AA), les champs qui recueillent les informations de l’utilisateur ont besoin de jetons autocomplete adaptés. Exemples : name, given-name, family-name, email, tel, street-address, postal-code, country-name et bday. Les champs de connexion peuvent utiliser username et current-password ; un nouveau mot de passe utilise new-password, et un code de vérification peut utiliser one-time-code.

Ces jetons permettent aux navigateurs, aux gestionnaires de mots de passe et aux outils d’assistance de reconnaître la fonction d’un champ. Utilise le jeton correspondant à l’utilisateur dont les informations sont saisies. Désigner l’adresse d’un ami comme l’adresse e-mail de l’utilisateur pour le remplissage automatique peut entraîner la saisie de mauvaises coordonnées.

Réduis les exigences de mémorisation et les saisies répétées

Autorise le collage dans les champs de mot de passe et de code de vérification et prends en charge les gestionnaires de mots de passe. Le critère WCAG 3.3.8 Authentification accessible (minimum) (AA) n’autorise les tests cognitifs lors de la connexion qu’avec une alternative ou une aide conforme, ou dans les cas prévus de reconnaissance d’objets ou de contenu personnel. Bloquer le collage crée un obstacle lorsque cela oblige à mémoriser ou à transcrire une information et qu’aucune autre méthode de connexion conforme n’existe.

Pour une commande en plusieurs étapes, reporte les informations déjà saisies. Un choix « L’adresse de facturation est identique à l’adresse de livraison » évite de les saisir à nouveau. Le critère WCAG 3.3.7 Saisie redondante (A) prévoit des exceptions lorsque la répétition est essentielle, nécessaire à la sécurité ou que l’information précédente n’est plus valide.

Prévois une protection pour les envois ayant des conséquences

Une commande peut créer un engagement financier. Avant de la finaliser, propose une étape de vérification permettant aux utilisateurs de corriger les détails. Selon le critère 3.3.4 Prévention des erreurs (juridiques, financières, de données) (AA), les envois concernés doivent pouvoir être annulés, être vérifiés avec une possibilité de correction, ou être examinés et confirmés avec une possibilité de correction. Le champ d’application comprend aussi la modification ou la suppression de données enregistrées contrôlées par l’utilisateur et l’envoi de réponses à un test.

Garde une mise en page facile à suivre lorsque le formulaire est agrandi : des étiquettes directement au-dessus des champs et une colonne principale réduisent la distance entre une consigne et l’endroit où elle s’applique.

Distingue le format de la fonction personnelle

Le type de champ et le jeton de remplissage automatique répondent à des questions différentes. Le type identifie la nature de la valeur et peut fournir une vérification du format. Le jeton identifie l’information personnelle de l’utilisateur pour le remplissage automatique :

<label for="your-email">Your email address (required)</label>
<input id="your-email" name="email" type="email"
       required autocomplete="email">
<label for="guest-email">Guest's email address</label>
<input id="guest-email" name="guest-email" type="email">

Les deux champs acceptent des adresses e-mail, mais seul le premier demande celle de l’utilisateur actuel. Le second ne doit pas être désigné comme l’adresse e-mail de cet utilisateur pour le remplissage automatique. Les étiquettes visibles maintiennent la distinction pour les personnes qui saisissent elles-mêmes les valeurs. Changer un jeton ne modifie pas ce que vérifie le type e-mail.

Un message d’erreur doit aider une personne à corriger le problème sans perdre le travail déjà accompli. Un message d’état doit signaler un changement sans lui faire perdre sa place. Les deux ont besoin d’une formulation visible et de la bonne association dans le code.

Énonce le problème et une correction utile

« Saisie invalide » aide peu. « Erreur : saisis une adresse e-mail au format nom@exemple.com » indique ce qui demande une intervention et suggère une correction. Le critère WCAG 3.3.1 Identification des erreurs (A) exige que les erreurs détectées soient décrites par écrit ; 3.3.3 Suggestion de correction d’erreur (AA) exige de proposer les corrections connues lorsqu’elles ne compromettent pas la sécurité ou l’objectif du formulaire.

<label for="email">Email address</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error">Error: Enter an email address in the format name@example.com</p>

Définis aria-invalid="true" seulement après avoir vérifié le champ et trouvé une erreur. L’attribut signale l’état invalide ; la description en explique la raison. Une bordure rouge seule ne fournit ni l’explication textuelle ni l’association.

Aide à trouver plusieurs erreurs

Après l’envoi, un long formulaire peut afficher un récapitulatif des erreurs en haut. Donne-lui un titre comme « Il y a 2 problèmes dans ta commande », puis des liens vers les champs concernés. Permets au récapitulatif de recevoir le focus avec tabindex="-1" et fais en sorte que le script lui donne le focus. Ajouter « Erreur : » au début du titre de la page aide aussi à identifier le changement d’état de la page.

Garde aussi les messages d’erreur à côté de leurs champs et conserve toutes les données déjà saisies. Un lien du récapitulatif mène au champ ; l’explication locale aide pendant la correction. Effacer tous les champs oblige à répéter un travail déjà réussi.

Les attributs de validation natifs comme required, type="email" et minlength peuvent fournir des messages du navigateur. Un système personnalisé peut utiliser novalidate et afficher ses propres messages. Dans les deux cas, les erreurs ont besoin d’un texte que les utilisateurs peuvent trouver et associer au champ concerné.

Annonce un changement sans déplacer le focus

Une mise à jour du panier se produit souvent alors que le focus doit rester sur le bouton Ajouter. Utilise une région dynamique déjà présente dans le document :

<p role="status" id="cart-status"></p>

Lorsqu’un article est ajouté, un script remplace son texte par « 1 pain au levain ajouté à ton panier ». role="status" est poli : il laisse le lecteur d’écran terminer sa lecture en cours avant d’annoncer la mise à jour. Cela répond au critère 4.1.3 Messages d’état (AA).

Réserve role="alert", une annonce prioritaire, aux messages urgents. Des interruptions continuelles rendent les achats ordinaires plus difficiles. Insère la région vide avant de mettre son contenu à jour ; créer la région et son message ensemble ne produit pas une annonce fiable dans de nombreuses configurations. Garde le focus sur la tâche pour les mises à jour ordinaires et déplace-le volontairement dans des situations comme un récapitulatif des erreurs que l’utilisateur doit examiner.

ARIA ajoute des informations à l’arbre d’accessibilité lorsque HTML a besoin d’aide pour exprimer un nom, une relation ou un état. Il ne construit pas l’interaction elle-même. Avant d’ajouter un attribut, vérifie ce que l’élément natif fournit déjà et ce qui manque réellement.

Considère un rôle comme une promesse

WAI-ARIA signifie Accessible Rich Internet Applications. La version 1.2 est devenue une recommandation du W3C en juin 2023. Ses rôles, états et propriétés influencent les informations communiquées aux technologies d’assistance. Un rôle comme button promet un comportement de bouton, mais ne rend pas l’élément apte à recevoir le focus, ne crée pas d’activation au clavier et n’ajoute pas de mise en forme.

Un div avec role="button" a toujours besoin d’une gestion du clavier et du focus. Un vrai button les fournit déjà. Le principe du guide ARIA Authoring Practices « mieux vaut ne pas utiliser ARIA que mal l’utiliser » avertit que des informations incorrectes peuvent induire les utilisateurs en erreur sur l’action d’un contrôle.

Préserve le sens natif

Utilise d’abord les éléments et attributs natifs : nav, button, un champ de case à cocher et l’attribut natif required. Évite de répéter les rôles implicites comme role="main" sur main ou role="button" sur button. Une exception utile est role="list" sur une liste dont la suppression des puces affecte les annonces de VoiceOver.

Ne remplace pas le sens d’un titre par un rôle de bouton. Imbrique un bouton à l’intérieur :

<h2>
  <button type="button" aria-expanded="false">Shipping</button>
</h2>

Le titre apparaît toujours dans la navigation par titres et son bouton expose l’action. Le script doit faire correspondre le contenu affiché et l’état déplié.

Ne place jamais aria-hidden="true" sur un contrôle pouvant recevoir le focus ni sur un ancêtre qui en contient un. Le focus pourrait arriver sur un élément retiré de l’arbre d’accessibilité. role="presentation" et role="none" fonctionnent différemment : ils retirent la sémantique, pas le contenu. Les navigateurs ignorent ces rôles sur les éléments pouvant recevoir le focus ; ils ne peuvent donc pas servir à transformer un lien actif en texte ordinaire.

Trouve la source d’un nom

Pour les contrôles ordinaires présentés ici, vérifie les sources du nom dans cet ordre de priorité :

1. aria-labelledby, qui fait référence à du texte par son identifiant.
2. aria-label, qui fournit une chaîne de texte.
3. La source native, comme une étiquette, le texte d’un bouton ou l’alternative textuelle d’une image.
4. title, en dernier recours lorsque c’est applicable.

aria-describedby ajoute une description après le nom ; il ne définit pas le nom. Un attribut prioritaire peut masquer accidentellement une formulation visible utile. <button aria-label="Close dialog">Cancel</button> est annoncé comme « Close dialog », alors que la personne voit « Cancel ». Privilégie le texte visible ou inclus-le au début d’un nom développé nécessaire.

Les sites simples ont souvent besoin d’ARIA pour les noms des régions repères répétées, les boutons avec icône, les aides et erreurs des champs, les boutons de dépliage, les liens vers la page courante et les mises à jour dynamiques. Une grande quantité d’attributs ARIA n’est pas une mesure de qualité. Inspecte le rôle et le nom calculés et utilise le clavier pour vérifier le comportement promis par le rôle.

Suis les sources de nom concurrentes

Considère un bouton doté de plusieurs attributs de nommage :

<h2 id="options-title">Delivery options</h2>
<button type="button" aria-labelledby="options-title"
        aria-label="Choose delivery">Show pickup options</button>

Suis d’abord aria-labelledby : le texte référencé fournit « Delivery options ». L’attribut aria-label et le texte visible du bouton, moins prioritaires, ne l’emportent pas. Supprimer uniquement aria-label laisse donc le même nom calculé.

Pour que « Show pickup options » nomme ce bouton, supprime les deux attributs prioritaires inutiles. Le rôle de bouton reste le même tout au long de l’opération ; seule la source de son nom change. Inspecte le nom calculé après chaque modification afin de savoir quel attribut a causé la différence. Ajouter une description ne corrigerait pas le nom erroné, car une description est une information distincte.

Une interface qui change doit communiquer la même chose visuellement et dans le code. Si un panneau est ouvert mais que son bouton indique encore « replié », un utilisateur de lecteur d’écran reçoit une information fausse. Mets l’état à jour chaque fois que l’interface change.

Garde un bouton de dépliage synchronisé

<button type="button" aria-expanded="false"
        aria-controls="main-menu">Menu</button>
<ul id="main-menu" hidden>
  <li><a href="/bread">Bread</a></li>
</ul>

Lorsque le menu s’ouvre, le script retire hidden et définit l’attribut aria-expanded du bouton sur true. Lorsqu’il se ferme, le script rétablit hidden et définit l’état sur false. L’état appartient au bouton qui commande l’ouverture et la fermeture. aria-controls identifie l’élément concerné ; sa prise en charge varie, il ne peut donc pas remplacer l’état déplié ni le comportement réel de masquage.

Choisis l’état adapté au contrôle

Pour le lien de la page courante, mets en forme le même attribut en CSS, par exemple avec une police en gras et une bordure inférieure sur a[aria-current="page"]. Cela maintient la mise en évidence visuelle liée à l’état annoncé. aria-selected concerne les composants comme les onglets et les options de liste de sélection, pas les liens ordinaires de navigation entre pages.

Un bouton à bascule peut garder l’étiquette « Couper le son » et faire passer aria-pressed de false à true. Une autre conception valide modifie l’étiquette d’un bouton d’action ordinaire entre « Couper le son » et « Rétablir le son » sans état enfoncé. Ne combine pas une étiquette d’action changeante avec le modèle d’état à bascule, qui peut produire des annonces déroutantes comme « Rétablir le son, enfoncé ».

Distingue le masquage de la désactivation

aria-hidden="true" retire un élément et ses descendants de l’arbre d’accessibilité mais les laisse visibles. Utilise-le pour les icônes décoratives ou les contenus visuels redondants. Il n’empêche pas l’accès au clavier. Utilise hidden ou display: none lorsqu’une région doit être indisponible pour tous.

L’attribut natif disabled empêche l’interaction ordinaire avec un contrôle natif. aria-disabled="true" signale un état indisponible mais ne bloque ni les clics ni l’activation au clavier. Si cet attribut est utilisé pour qu’un contrôle désactivé puisse recevoir le focus et fournir une explication, le script doit empêcher son action. Privilégie aussi les attributs natifs checked et required sur les champs natifs.

Teste dans les deux sens

Ouvre et ferme la zone dépliable au clavier en surveillant les attributs dans les outils de développement. Inspecte l’état calculé et écoute son annonce. Un changement visuel réussi ne prouve pas à lui seul que l’état a été mis à jour, et un attribut modifié ne prouve pas à lui seul que le panneau est devenu visible ou utilisable.

Les vérifications automatisées trouvent rapidement de nombreux problèmes de code dans une page affichée. Utilise leurs résultats pour localiser les obstacles et vérifier les corrections. Leurs règles peuvent inspecter certaines relations et valeurs, mais une personne reste nécessaire pour décider si le contenu a un sens.

Choisis un outil et inspecte ses résultats

Axe DevTools utilise le moteur axe-core. WAVE place des marqueurs sur la page afin que les résultats soient visibles en contexte. Lighthouse, dans les outils de développement de Chrome, donne un score d’accessibilité à partir d’une sélection de vérifications axe-core. Accessibility Insights propose une autre méthode de test. Le service de validation du balisage du W3C vérifie des problèmes HTML comme les identifiants dupliqués et les éléments non fermés.

Selon leurs règles et le contexte, les outils peuvent détecter les attributs alt manquants, les contrôles sans nom, les champs sans étiquette, le faible contraste du texte sur fond uni, l’absence de langue de page et les attributs ARIA invalides. Certains problèmes de niveaux de titre apparaissent comme des avertissements. Lis l’explication du résultat et inspecte l’élément désigné.

Une alerte ou un résultat « à vérifier » demande un jugement. Un texte en gras signalé comme titre possible peut être un véritable titre de section écrit comme paragraphe, ou simplement mettre une phrase en valeur. Examine sa fonction avant de modifier son balisage.

Comprends ce que l’analyse ne peut pas décider

Un outil peut voir alt="photo" sans savoir que l’alternative est inutile. Il ne peut pas juger de manière fiable la clarté d’un intitulé de lien, l’exactitude des sous-titres, la logique de l’ordre de focus ou l’utilité d’un message d’erreur pour corriger un problème. Un calque visuel peut piéger le clavier d’une manière que l’analyse en cours ne détecte pas. Le texte sur une photographie nécessite aussi une vérification manuelle du contraste.

Un score de 100 signifie que les règles testées n’ont trouvé aucun échec. Ce n’est pas un verdict de conformité aux WCAG. Continue à tester les tâches et les significations que ces règles ne peuvent pas évaluer.

Teste les états utilisés par les personnes

Une analyse examine l’état affiché à cet instant. Lance les vérifications sur chaque modèle de page, puis à nouveau avec les menus et les boîtes de dialogue ouverts, après des erreurs de formulaire et aux petites largeurs. Un composant fermé peut cacher des problèmes qui n’apparaissent qu’à l’utilisation.

Supposons qu’un rapport sur une boulangerie trouve une image principale sans alternative, un champ de lettre d’information sans étiquette et du texte de pied de page #999999 sur blanc. Détermine d’abord si l’image informe ou décore. Ajoute une alternative utile ou alt="" selon le cas. Associe le champ e-mail à une étiquette visible. La paire de couleurs du pied de page donne un contraste de 2,85:1 ; remplacer la couleur du texte par #595959 donne 7,00:1 sur blanc.

Corrige les causes et vérifie les résultats

Classe les obstacles selon leur effet sur la tâche. Un piège au clavier ou un contrôle obligatoire sans nom peut empêcher totalement une commande. Corrige un champ ou un composant de pied de page partagé à sa source pour améliorer toutes les pages qui l’utilisent. Relance ensuite l’analyse dans le même état et répète le test manuel pertinent. Une baisse du nombre d’erreurs est un indice utile, mais la correction doit aussi permettre à la personne d’accomplir la tâche.

Les tests manuels montrent comment une page se comporte pendant une tâche réelle. Associe l’utilisation du clavier, les vues agrandies, les vérifications avec un lecteur d’écran et l’inspection directe de l’arbre. Consigne assez de détails pour qu’une autre personne puisse reproduire un problème et confirmer sa correction.

Suis une tâche au clavier du début à la fin

Mets la souris de côté. Pars de la barre d’adresse et parcours la page avec Tab. Atteins chaque lien et contrôle, utilise Entrée et Espace selon le cas et inverse la direction avec Maj+Tab. Vérifie que le focus reste visible et n’est pas masqué par une région adhérente.

Utilise le lien d’évitement, ouvre et ferme les menus, ferme une boîte de dialogue avec Échap et vérifie où le focus revient. Recherche les arrêts invisibles dans les composants fermés et les pièges dans les lecteurs ou cartes intégrés. Sur Mac, active la navigation au clavier et le réglage Safari permettant une navigation complète avec Tab avant de considérer que les contrôles sautés sont un défaut de la page.

Agrandis et redistribue la page

Teste avec un agrandissement à 200 % sans perdre de texte ni de fonctionnalité. Utilise ensuite une fenêtre de 1 280 px CSS de large avec un zoom à 400 %, ce qui équivaut à une largeur disponible de 320 px CSS. Vérifie que les paragraphes ne présentent ni défilement horizontal, ni chevauchement, ni coupure. Garde chaque fonction disponible dans la mise en page étroite. Applique les valeurs d’espacement du texte avec un outil et inspecte les contrôles ainsi que le texte courant.

Écoute la structure et les noms

NVDA sur Windows utilise Inser comme touche NVDA par défaut ; Verr. maj. est une alternative facultative. En mode lecture, H parcourt les titres, D les régions repères, K les liens, F les champs, T les tableaux et B les boutons. NVDA+F7 ouvre la liste des éléments. Tab continue à parcourir les contrôles interactifs.

Sur macOS, Cmd+F5 active ou désactive VoiceOver. Son modificateur VO est Contrôle+Option ; VO+Flèche droite lit l’élément suivant et VO+U ouvre le rotor. Sur iPhone, un balayage vers la droite passe à l’élément VoiceOver suivant. TalkBack propose une lecture tactile similaire sur Android.

Écoute si le titre et le plan de la page sont utiles, les noms des contrôles clairs, les rôles corrects, les alternatives aux images utiles et les étiquettes des champs compréhensibles. Les états obligatoires, les aides et les erreurs doivent être disponibles sur les champs concernés. Ouvre une zone dépliable et écoute le changement de son état. Ajoute un article et écoute si une mise à jour d’état est annoncée sans déplacement du focus.

Inspecte, consigne et teste de nouveau

Le panneau Accessibilité de Chrome et l’inspecteur d’accessibilité de Firefox affichent les rôles, noms et états calculés. Ils aident à comprendre pourquoi une étiquette est incorrecte avant même de lancer un lecteur d’écran.

Un rapport utile précise l’emplacement, les étapes, le comportement observé, les utilisateurs concernés, le critère associé et une correction suggérée. Par exemple : « Champ de lettre d’information dans le pied de page : atteindre le champ avec Tab ; il est annoncé sans étiquette. Les utilisateurs de lecteurs d’écran et de commandes vocales ne peuvent pas identifier sa fonction. Ajouter une étiquette Adresse e-mail associée ; vérifier les critères 1.3.1, 3.3.2 et 4.1.2. »

Teste de nouveau avec la méthode qui a permis de trouver le problème. Les associations courantes comprennent NVDA avec Firefox ou Chrome, JAWS avec Chrome et VoiceOver avec Safari. Tester avec des personnes qui utilisent quotidiennement des technologies d’assistance peut révéler des obstacles que l’utilisation occasionnelle par un développeur ne détecte pas.

Rends une erreur d’état reproductible

Un rapport sur un bouton de dépliage peut consigner un court test complet :

1. Sur la page des pains, utilise NVDA avec Firefox et atteins « Options de livraison » avec Tab.
2. Appuie une fois sur Entrée. Le panneau devient visible, mais le bouton est toujours annoncé comme replié.
3. Inspecte le bouton : aria-expanded vaut toujours false.

L’utilisateur concerné entend que le panneau visible reste fermé. Consigne le critère 4.1.2 Nom, rôle et valeur (A) et suggère de mettre à jour l’état du bouton lorsque le panneau change. Après la correction, répète l’ouverture et la fermeture avec les mêmes touches et la même association d’outils. Vérifie que la visibilité du panneau et l’état déplié annoncé correspondent dans les deux sens ; inspecter seulement l’état initial replié ne détecterait pas cette erreur.