Accessibilité web (RGAA) pour les dev

L'accessibilité numérique désigne le fait de concevoir des sites et applications utilisables par toutes les personnes, y compris celles en situation de handicap. On pense spontanément aux personnes aveugles utilisant un lecteur d'écran, mais le spectre est bien plus large : personnes malvoyantes, daltoniennes, sourdes ou malentendantes, à mobilité réduite qui naviguent au clavier, atteintes de troubles cognitifs. En France, environ une personne sur cinq vit avec une forme de handicap. Ignorer l'accessibilité, c'est exclure une part énorme de tes utilisateur·ices.

L'accessibilité recouvre aussi des situations temporaires ou contextuelles : un bras cassé, un écran en plein soleil, un environnement bruyant, une connexion lente. Concevoir accessible, c'est concevoir robuste pour tout le monde. C'est l'idée du design universel : ce qui aide les personnes handicapées améliore l'expérience de tous, à l'image des rampes d'accès qui servent aussi aux poussettes et aux valises.

Une obligation légale, pas seulement morale

En France, l'accessibilité numérique est une obligation légale pour les services publics et de nombreuses entreprises (au-delà d'un certain chiffre d'affaires). Le cadre de référence est le RGAA (Référentiel Général d'Amélioration de l'Accessibilité). Le non-respect expose à des sanctions financières et à l'obligation d'afficher son niveau de conformité. Au niveau européen, la directive sur l'accessibilité renforce encore ces exigences pour les acteurs privés.

Au niveau mondial, les règles d'accessibilité sont définies par les WCAG (Web Content Accessibility Guidelines), publiées par le W3C, l'organisme qui standardise le web. Le RGAA est la traduction et l'application française de ces WCAG : il reprend leurs exigences et fournit une méthode de test précise, avec 106 critères vérifiables. En clair : les WCAG posent les principes, le RGAA dit comment les vérifier concrètement en France.

Les quatre principes : P.O.U.R.

Toutes les règles WCAG se rangent sous quatre grands principes, faciles à mémoriser avec l'acronyme POUR. Un contenu accessible doit être :

• Perceptible : l'information doit pouvoir être perçue par tous les sens (texte alternatif pour les images, sous-titres pour les vidéos, contrastes suffisants).
• Utilisable : l'interface doit être manipulable par tous (navigation au clavier, temps suffisant, pas de contenu qui provoque des crises).
• Compréhensible : le contenu et le fonctionnement doivent être clairs (langue déclarée, libellés explicites, erreurs compréhensibles).
• Robuste : le contenu doit fonctionner avec les technologies d'assistance actuelles et futures (code valide, sémantique correcte).

Ces quatre principes structurent tout le reste du cours : les chapitres qui suivent les déclinent en gestes concrets. Retiens l'acronyme POUR, il te donne une grille de lecture pour toute question d'accessibilité : « ce que je code est-il perceptible, utilisable, compréhensible et robuste ? »

Voici la meilleure nouvelle du cours : la plus grande partie de l'accessibilité s'obtient gratuitement, simplement en écrivant un HTML sémantique, c'est-à-dire en utilisant chaque balise pour ce à quoi elle sert. Un lecteur d'écran s'appuie sur ces balises pour annoncer la nature de chaque élément : « titre de niveau 1 », « bouton », « liste de 5 éléments ». Un <div> ne dit rien ; un <button> dit tout.

Les repères de la page (landmarks)

<header>...</header>          <!-- l'en-tête -->
<nav>...</nav>                <!-- la navigation principale -->
<main>...</main>             <!-- le contenu principal, unique -->
<aside>...</aside>           <!-- contenu complémentaire -->
<footer>...</footer>         <!-- le pied de page -->

Ces balises de structure créent des repères (landmarks) que les technologies d'assistance permettent de parcourir directement : une personne au lecteur d'écran peut sauter au <main> ou lister les zones de navigation. Remplacer ces balises par des <div> génériques prive l'utilisateur·ice de ces repères. La règle est simple : une seule balise <main> par page, et chaque grande zone dans sa balise sémantique.

La hiérarchie des titres

<h1>Le titre principal de la page (un seul par page)</h1>
  <h2>Une grande section</h2>
    <h3>Une sous-section</h3>
    <h3>Une autre sous-section</h3>
  <h2>Une autre grande section</h2>

Les titres (<h1> à <h6>) forment le plan de la page, comme une table des matières. Une personne au lecteur d'écran navigue de titre en titre pour comprendre la structure et accéder directement à la section voulue. La règle : un seul <h1>, puis une hiérarchie logique sans sauter de niveau (ne passe pas d'un <h2> à un <h4>). Ne choisis jamais un niveau de titre pour sa taille visuelle, c'est le rôle du CSS.

Le principe Perceptible impose que toute information non textuelle ait un équivalent texte. Pour une image, c'est l'attribut alt : une description textuelle que le lecteur d'écran énonce et qui s'affiche si l'image ne charge pas. Bien rédiger un alt est un art : il doit décrire l'information portée par l'image, pas l'image en elle-même, et rester concis.

<!-- Image porteuse d'information : alt descriptif -->
<img src="graphique.png"
     alt="Ventes en hausse de 20 % entre janvier et juin 2026" />

<!-- Image purement décorative : alt VIDE (mais présent) -->
<img src="ornement.svg" alt="" />

<!-- Logo cliquable : l'alt décrit la destination -->
<a href="/"><img src="logo.png" alt="Accueil de Mon Entreprise" /></a>

Cas crucial souvent raté : l'image décorative. Une image qui n'apporte aucune information (un ornement, un fond) doit avoir un alt vide (alt=""), mais présent. Ainsi, le lecteur d'écran l'ignore poliment. Un alt totalement absent, à l'inverse, pousse certains lecteurs à lire le nom du fichier (« ornement point s v g »), ce qui pollue l'écoute. Vide pour le décoratif, descriptif pour l'informatif : c'est la règle.

Vidéos et sons

• Sous-titres : toute vidéo parlée a des sous-titres synchronisés, pour les personnes sourdes ou malentendantes.
• Transcription : un équivalent texte complet (audio et vidéo) permet de tout consulter sans le son ni l'image.
• Audiodescription : pour les contenus visuels essentiels, une description audio de ce qui se passe à l'écran.
• Pas de lecture automatique avec du son : elle perturbe et peut masquer un lecteur d'écran.

De nombreuses personnes naviguent sans souris : au clavier (par handicap moteur), avec un lecteur d'écran, ou avec des dispositifs adaptés. Le principe Utilisable exige que toute action réalisable à la souris le soit aussi au clavier. La touche Tab déplace le focus d'un élément interactif au suivant, Entrée ou Espace active, Échap ferme. Si tu as utilisé des éléments HTML natifs (chapitre 3), tu es déjà accessible au clavier presque partout.

Le focus visible, non négociable

Quand on navigue au clavier, il faut voir où l'on se trouve : c'est le rôle de l'indicateur de focus, ce contour qui apparaît autour de l'élément actif. Les navigateurs l'affichent par défaut, mais une erreur fréquente le supprime en CSS pour des raisons esthétiques : outline: none. C'est catastrophique pour l'accessibilité, l'utilisateur·ice au clavier est alors perdu·e. Si tu retires le style par défaut, tu dois en fournir un autre, bien visible.

/* ❌ Interdit : supprime le focus sans rien mettre à la place */
button:focus { outline: none; }

/* ✅ Recommandé : un focus personnalisé et bien visible */
button:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
}

Le lien d'évitement

Sur chaque page, un menu de navigation se répète en tête. Sans aide, une personne au clavier devrait tabuler à travers tous ces liens à chaque page avant d'atteindre le contenu. Le lien d'évitement (skip link) résout ça : un lien, souvent caché jusqu'à ce qu'il reçoive le focus, qui permet de sauter directement au contenu principal.

<body>
  <!-- Premier élément focalisable : le lien d'évitement -->
  <a href="#contenu" class="lien-evitement">Aller au contenu principal</a>
  <nav>...long menu...</nav>
  <main id="contenu">...</main>
</body>

Un formulaire inaccessible bloque l'utilisateur·ice au moment le plus important : celui de l'action. Le point de départ, tu le connais déjà du cours Opquast : chaque champ a une étiquette associée. En accessibilité, c'est vital : sans <label> correctement lié, le lecteur d'écran annonce « champ de saisie » sans dire de quoi il s'agit. La personne ne sait pas quoi taper.

<!-- Étiquette liée au champ par for/id : le lecteur annonce "Adresse e-mail" -->
<label for="email">Adresse e-mail</label>
<input type="email" id="email" name="email" required
       aria-describedby="aide-email" />
<p id="aide-email">Nous ne partagerons jamais votre adresse.</p>

L'attribut aria-describedby relie un champ à un texte d'aide ou d'explication, que le lecteur d'écran énonce en plus de l'étiquette. Le type="email" aide aussi : il déclenche le clavier adapté sur mobile et une validation de base. Utiliser les bons types de champ (email, tel, date) est un geste d'accessibilité et d'ergonomie.

Grouper avec fieldset et legend

<fieldset>
  <legend>Choisissez votre formule</legend>
  <input type="radio" id="mensuel" name="formule" />
  <label for="mensuel">Mensuelle</label>
  <input type="radio" id="annuel" name="formule" />
  <label for="annuel">Annuelle</label>
</fieldset>

Pour un groupe de champs liés (des boutons radio, une série de cases), on les rassemble dans un <fieldset> avec une <legend> qui donne le sens du groupe. Le lecteur d'écran annonce alors « Choisissez votre formule, Mensuelle » : la question et l'option, au lieu d'un « Mensuelle » isolé et incompréhensible.

Des erreurs accessibles

• Message explicite : « Le format de l'e-mail est invalide », pas juste « Erreur » ou un champ rouge.
• À proximité du champ : l'erreur est affichée près du champ concerné et lui est reliée (aria-describedby).
• Pas seulement la couleur : un texte et une icône accompagnent le rouge, jamais la couleur seule.
• Annoncée : une zone « live » (aria-live) permet au lecteur d'écran d'énoncer l'erreur dès son apparition.

Un texte gris clair sur fond blanc est illisible pour beaucoup de monde, pas seulement les personnes malvoyantes : pense à un écran en plein soleil. Le principe Perceptible impose un contraste suffisant entre le texte et son fond. La règle WCAG de niveau AA : un rapport de contraste d'au moins 4,5:1 pour le texte normal, et 3:1 pour les grands textes. Ce ratio se mesure avec des outils gratuits.

<!-- ❌ L'information passe par la seule couleur -->
<span style="color: green">Disponible</span>
<span style="color: red">Rupture</span>

<!-- ✅ Un texte et une icône, en plus de la couleur -->
<span class="ok">✔ Disponible</span>
<span class="ko">✘ Rupture de stock</span>

ARIA : à utiliser avec prudence

ARIA est un ensemble d'attributs (role, aria-label, aria-live...) qui ajoutent de l'information d'accessibilité là où le HTML ne suffit pas, typiquement pour des composants complexes (onglets, fenêtres modales). Mais ARIA est un outil à double tranchant : mal employé, il rend un site moins accessible qu'un HTML simple. D'où la première règle d'ARIA, un brin provocatrice : « la meilleure règle ARIA, c'est de ne pas utiliser ARIA » quand une balise HTML native fait le travail.

<!-- Inutile : le bouton natif est déjà annoncé comme bouton -->
<button role="button">Valider</button>   <!-- role redondant -->

<!-- Usage légitime : un bouton icône sans texte visible -->
<button aria-label="Fermer la fenêtre">✕</button>

L'usage le plus courant et légitime d'ARIA pour un junior est aria-label : donner un nom accessible à un élément qui n'a pas de texte visible, comme un bouton icône (une croix de fermeture, une loupe de recherche). Sans lui, le lecteur d'écran annoncerait « bouton » sans plus. Au-delà de ces cas simples, privilégie toujours le HTML natif, et n'ajoute ARIA que si tu sais précisément pourquoi.

On ne « devine » pas l'accessibilité, on la teste. La bonne approche combine trois niveaux : les outils automatiques (rapides mais partiels), les tests manuels (clavier, zoom) et, idéalement, l'écoute au lecteur d'écran. Les outils automatiques ne détectent qu'environ 30 % des problèmes : ils sont un point de départ, pas une garantie.

• axe DevTools ou Lighthouse : des extensions qui analysent une page et listent les erreurs (contrastes, alt manquants, labels).
• Le test clavier : navigue toute la page avec Tab, sans souris. Le test le plus rentable.
• Le zoom : agrandis la page à 200 %, tout doit rester lisible et utilisable.
• Un lecteur d'écran : VoiceOver (Mac), NVDA (Windows, gratuit) pour entendre ta page comme un utilisateur·ice.

Intégrer plutôt que corriger

Comme pour la qualité web, l'erreur est de reléguer l'accessibilité à la fin. Corriger un site inaccessible coûte cher ; concevoir accessible dès le départ ne coûte presque rien. Le secret est d'intégrer les réflexes à chaque étape : HTML sémantique quand tu structures, alt quand tu ajoutes une image, label quand tu crées un champ, test clavier avant chaque livraison. L'accessibilité devient alors une habitude, pas une contrainte de dernière minute.

Enfin, la loi impose aux organismes concernés de publier une déclaration d'accessibilité indiquant leur niveau de conformité au RGAA, et un plan d'amélioration. En tant que dev, tu contribues à ce niveau de conformité par chaque ligne de code accessible que tu écris. C'est une responsabilité concrète, et un argument fort en entretien comme devant un jury RNCP.