Pourquoi l’accessibilité web concerne tous les projets

L’accessibilité web consiste à rendre un site ou une application utilisable par le plus grand nombre de personnes possible, y compris celles qui naviguent avec un lecteur d’écran, uniquement au clavier, avec un fort zoom, dans un environnement lumineux difficile, ou avec des limitations motrices, visuelles, auditives ou cognitives.

Ce n’est pas seulement une contrainte réglementaire ou un sujet réservé aux administrations. Une interface accessible est souvent une interface mieux structurée, plus lisible, plus rapide à comprendre et plus solide techniquement. Les bonnes pratiques d’accessibilité rejoignent donc naturellement celles du HTML sémantique, du responsive design, de la performance et de l’expérience utilisateur.

Pour un développeur débutant, la bonne nouvelle est simple : beaucoup d’améliorations importantes viennent d’abord de choix HTML et CSS sobres. Avant d’ajouter des attributs ARIA complexes ou des composants JavaScript sophistiqués, il faut maîtriser les fondamentaux : structure claire, textes alternatifs, contraste suffisant et navigation clavier.

Commencer par un HTML sémantique

Un site accessible commence rarement par une bibliothèque. Il commence par du HTML correctement choisi. Les balises HTML ne servent pas uniquement à afficher du contenu : elles donnent du sens à la page.

Un bouton qui déclenche une action doit être un button, pas un div cliquable. Un lien qui mène vers une autre page doit être un a. Un titre doit utiliser une balise de titre cohérente. Cette structure aide les navigateurs, les moteurs de recherche, les lecteurs d’écran et les outils d’assistance à comprendre l’interface.

<header>
  <nav aria-label="Navigation principale">
    <a href="/produits">Produits</a>
    <a href="/tarifs">Tarifs</a>
    <a href="/contact">Contact</a>
  </nav>
</header>

<main>
  <h2>Comparer nos offres</h2>
  <p>Choisissez la formule adaptée à votre usage.</p>
  <button type="button">Afficher le comparatif</button>
</main>

Ici, la structure indique clairement les zones de la page. Le main contient le contenu principal, le nav représente une zone de navigation, et le bouton est naturellement utilisable au clavier. Pour approfondir cette base, l’article HTML : construire la structure claire et solide d’une page web est un bon complément.

Écrire des textes alternatifs utiles pour les images

Les images peuvent avoir plusieurs rôles : informer, illustrer, décorer ou remplacer une information textuelle. Le texte alternatif doit être adapté à ce rôle.

Une erreur fréquente consiste à remplir systématiquement l’attribut alt avec une description littérale trop longue. Une autre erreur consiste à le laisser vide alors que l’image porte une information importante.

<img
  src="graphique-ventes.png"
  alt="Les ventes augmentent régulièrement de janvier à juin, avec un pic en juin."
/>

Ce texte alternatif ne décrit pas seulement “un graphique bleu”. Il transmet l’information utile. À l’inverse, une image purement décorative peut utiliser un alt vide afin d’être ignorée par les lecteurs d’écran.

<img src="motif-abstrait.svg" alt="" />

Pour une image complexe, comme une datavisualisation ou un schéma technique, l’attribut alt ne suffit pas toujours. Il peut résumer l’idée principale, tandis qu’un texte adjacent détaille les données importantes.

<figure>
  <img
    src="repartition-navigateurs.png"
    alt="Répartition des navigateurs utilisés par les visiteurs."
  />
  <figcaption>
    Chrome représente 58 % des visites, Safari 24 %, Firefox 9 % et les autres navigateurs 9 %.
  </figcaption>
</figure>

Cette approche améliore aussi la compréhension pour les personnes qui consultent rapidement la page ou dont la connexion charge mal les images. L’optimisation des images n’est donc pas seulement une affaire de poids de fichier ; elle concerne aussi le sens, comme expliqué dans Optimiser les images web sans sacrifier la qualité.

Vérifier les contrastes de couleurs

Un texte gris clair sur fond blanc peut sembler élégant dans une maquette, mais devenir difficile à lire pour beaucoup d’utilisateurs. Le contraste concerne les personnes malvoyantes, mais aussi les utilisateurs sur mobile en plein soleil, les écrans de mauvaise qualité ou les longues sessions de lecture.

En pratique, évitez de définir les couleurs uniquement à l’œil. Utilisez des outils de vérification de contraste, comme ceux intégrés aux DevTools des navigateurs ou les outils liés aux WCAG. Les textes importants doivent rester lisibles dans leurs différents états : normal, survol, focus, désactivé, erreur, succès.

:root {
  --color-text: #1f2937;
  --color-background: #ffffff;
  --color-link: #0645ad;
  --color-error: #b42318;
}

body {
  color: var(--color-text);
  background: var(--color-background);
}

a {
  color: var(--color-link);
  text-decoration: underline;
}

.error-message {
  color: var(--color-error);
  font-weight: 600;
}

Remarquez que le lien n’est pas distingué uniquement par sa couleur : il est aussi souligné. C’est important, car tous les utilisateurs ne perçoivent pas les couleurs de la même manière. La couleur peut renforcer une information, mais elle ne doit pas être le seul moyen de la transmettre.

Cette logique rejoint les préoccupations de design system : des couleurs accessibles devraient être définies dans des tokens réutilisables, plutôt que corrigées composant par composant. L’article Design tokens en CSS et TypeScript : construire une interface cohérente et maintenable approfondit cette organisation.

Ne jamais casser la navigation clavier

Un site doit pouvoir être utilisé sans souris. La navigation au clavier repose principalement sur la touche Tab, Entrée, Espace et les flèches selon les composants. Les éléments interactifs natifs comme button, a, input, select et textarea sont déjà compatibles clavier lorsqu’ils sont utilisés correctement.

Le problème apparaît souvent lorsque l’on remplace ces éléments par des div ou span avec des gestionnaires JavaScript.

<!-- À éviter -->
<div class="card-button" onclick="openDetails()">
  Voir les détails
</div>

<!-- Préférable -->
<button type="button" class="card-button">
  Voir les détails
</button>

Le second exemple reçoit automatiquement le focus, s’active avec le clavier et expose un rôle correct aux technologies d’assistance. Il demande moins de code et produit une interface plus fiable.

Il faut aussi rendre le focus visible. Supprimer l’outline sans alternative est une erreur classique.

.button:focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
}

Le pseudo-sélecteur :focus-visible permet d’afficher un indicateur clair lorsque l’utilisateur navigue au clavier, sans forcément afficher le même style après un clic souris. Cela améliore l’expérience sans masquer l’état de focus.

Structurer les formulaires avec des labels explicites

Les formulaires sont souvent les zones les plus sensibles d’un site : inscription, paiement, recherche, contact, configuration. Un champ sans label clair devient vite inutilisable avec un lecteur d’écran ou difficile à comprendre pour n’importe quel utilisateur.

<label for="email">Adresse e-mail</label>
<input id="email" name="email" type="email" autocomplete="email" />

Le placeholder ne remplace pas un label. Il disparaît quand l’utilisateur saisit du texte et peut être difficile à lire. Pour les messages d’aide ou d’erreur, il est préférable d’associer explicitement les textes au champ.

<label for="password">Mot de passe</label>
<input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-help"
/>
<p id="password-help">Utilisez au moins 12 caractères.</p>

Pour aller plus loin sur ce sujet, consultez Formulaires accessibles : concevoir des interfaces web vraiment utilisables, qui détaille les labels, les groupes de champs, les erreurs et la validation progressive.

Utiliser ARIA avec parcimonie

ARIA permet d’ajouter des informations d’accessibilité quand le HTML natif ne suffit pas. Mais ARIA ne répare pas une mauvaise structure HTML. Une règle pratique : si un élément natif existe, utilisez-le d’abord.

Par exemple, ceci est rarement nécessaire :

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

Il vaut mieux écrire :

<button type="submit">Envoyer</button>

ARIA devient utile pour des interfaces dynamiques : messages de statut, composants personnalisés, panneaux ouverts ou fermés, notifications. Pour annoncer des changements dynamiques aux lecteurs d’écran, les live regions peuvent être pertinentes, comme expliqué dans ARIA live regions : rendre les interfaces dynamiques compréhensibles.

Tester avec des gestes simples

L’accessibilité ne se valide pas uniquement avec une checklist. Quelques tests manuels rapides détectent déjà beaucoup de problèmes.

Essayez de parcourir votre page uniquement avec le clavier. Pouvez-vous atteindre tous les liens, boutons et champs ? Voyez-vous toujours où se trouve le focus ? Les modales bloquent-elles correctement la navigation à l’intérieur ? Les menus peuvent-ils être fermés sans souris ?

Augmentez ensuite le zoom du navigateur à 200 %. Le contenu reste-t-il lisible ? Les boutons se superposent-ils ? Des textes disparaissent-ils ? Ce test rejoint les bonnes pratiques du responsive design, abordées dans Introduction au responsive design : créer des sites adaptés à tous les écrans.

Enfin, utilisez les outils automatiques comme Lighthouse, axe DevTools ou les audits intégrés au navigateur. Ils ne trouvent pas tout, mais ils repèrent vite des erreurs fréquentes : absence de label, contraste insuffisant, attribut alt manquant, ordre de titres incohérent.

Intégrer l’accessibilité dès le début

L’accessibilité coûte cher lorsqu’elle est traitée comme une correction tardive. Elle devient beaucoup plus simple lorsqu’elle guide les choix de base : HTML sémantique, composants natifs, couleurs vérifiées, focus visible, textes clairs, formulaires bien associés.

La bonne approche n’est pas de viser une perfection abstraite dès le premier commit. Il faut plutôt installer des réflexes durables : tester au clavier, vérifier les contrastes, documenter les composants, éviter les interactions dépendantes uniquement de la souris et conserver une structure HTML compréhensible.

Un site accessible n’est pas un site moins créatif. C’est un site dont la créativité ne bloque pas l’usage. Que vous construisiez une page simple, une application React ou Vue, une interface immersive ou un tableau de bord complexe, les mêmes principes restent valables : le contenu doit être perceptible, l’interface utilisable, l’information compréhensible et le code suffisamment robuste pour fonctionner dans des contextes variés.