L'accessibilité web n'est plus un bonus : c'est une obligation légale dans de nombreux pays et surtout une question d'éthique. Pourtant, trop de développeurs considèrent encore l'a11y comme une contrainte. Voici comment l'intégrer naturellement dans votre workflow.
Pourquoi l'accessibilité compte
15% de la population mondiale vit avec un handicap. Ignorer l'accessibilité, c'est exclure des millions d'utilisateurs potentiels de vos applications.
Les bonnes pratiques d'accessibilité améliorent l'expérience pour tous : navigation au clavier, contrastes lisibles, structure sémantique bénéficient à chaque utilisateur.
Le SEO et l'accessibilité sont liés. Google valorise les sites bien structurés, avec du contenu alternatif pour les images et une hiérarchie de titres claire.
Les bases WCAG 2.2
WCAG (Web Content Accessibility Guidelines) définit 4 principes : Perceptible, Opérable, Compréhensible, Robuste. Chaque critère a 3 niveaux : A, AA, AAA.
Visez le niveau AA minimum. Cela inclut : contrastes de 4.5:1 pour le texte, navigation au clavier complète, textes alternatifs pour les images, et labels pour les formulaires.
WCAG 2.2 (2023) ajoute des critères importants : taille minimale des cibles tactiles (24x24 CSS pixels), authentification accessible, et aide contextuelle cohérente.
HTML sémantique : votre premier outil
Utilisez les bons éléments HTML. Un <button> est cliquable au clavier et annoncé correctement par les lecteurs d'écran. Un <div onClick> ne l'est pas.
Structurez avec <header>, <main>, <nav>, <article>, <aside>, <footer>. Ces landmarks permettent aux utilisateurs de technologies d'assistance de naviguer rapidement.
Respectez la hiérarchie des titres. Un seul <h1> par page, puis <h2>, <h3>... sans sauter de niveau. C'est le plan de votre contenu.
<!-- ❌ Mauvais : div soup inaccessible -->
<div class="header">
<div class="nav">...</div>
</div>
<div class="content">
<div class="title">Mon titre</div>
</div>
<!-- ✅ Bon : HTML sémantique -->
<header>
<nav aria-label="Navigation principale">...</nav>
</header>
<main>
<h1>Mon titre</h1>
</main>ARIA : quand et comment l'utiliser
ARIA (Accessible Rich Internet Applications) complète HTML quand les éléments natifs ne suffisent pas. Règle d'or : n'utilisez ARIA que si nécessaire.
Les roles courants : role='button' pour un élément non-bouton interactif, role='alert' pour les messages urgents, role='dialog' pour les modales.
aria-label et aria-labelledby nomment les éléments. aria-describedby ajoute une description. aria-live annonce les changements dynamiques.
// Composant accessible avec ARIA
function SearchInput() {
const [results, setResults] = useState([]);
return (
<div>
<label htmlFor="search">Rechercher</label>
<input
id="search"
type="search"
aria-describedby="search-hint"
aria-controls="search-results"
/>
<p id="search-hint" className="sr-only">
Tapez au moins 3 caractères
</p>
<ul
id="search-results"
role="listbox"
aria-live="polite"
>
{results.map(r => (
<li key={r.id} role="option">{r.title}</li>
))}
</ul>
</div>
);
}Tests et outils
Intégrez les tests d'accessibilité dans votre CI. axe-core avec jest-axe ou Playwright détecte automatiquement les violations courantes.
Testez manuellement au clavier : Tab pour naviguer, Enter/Space pour activer, Escape pour fermer. Si vous êtes bloqué, vos utilisateurs le seront aussi.
Utilisez un lecteur d'écran. VoiceOver (Mac), NVDA (Windows gratuit) ou TalkBack (Android). 30 minutes de test révèlent des problèmes que les outils automatiques manquent.
Conclusion
L'accessibilité n'est pas une feature qu'on ajoute à la fin. C'est une approche de développement qui bénéficie à tous. Commencez par le HTML sémantique, testez au clavier, et améliorez progressivement. Chaque amélioration compte.