Cette checklist regroupe les points essentiels qu'un développeur front-end doit vérifier pour livrer un composant, une page ou une application conforme RGAA 4.1. Elle est organisée par thématique, dans l'ordre où ces points sont rencontrés pendant le développement.
1. Structure HTML sémantique
- La page a un
<!DOCTYPE html>valide <html lang="fr">est défini avec la bonne langue<title>unique et descriptif sur chaque page- Un seul
<h1>par page - Hiérarchie des titres respectée : pas de saut de niveau (
h2puish4interdit) - Utilisation des landmarks :
<header>,<nav>,<main>,<footer>,<aside> - Validation HTML OK (validator.w3.org)
2. Navigation et liens
- Un lien d'évitement ("Aller au contenu principal") en tout début de page
- Plan du site accessible depuis le pied de page
- Fil d'Ariane sur les pages profondes
- Tous les liens ont un intitulé explicite hors contexte (pas de "cliquer ici", "lire la suite")
- Les liens externes sont annoncés aux lecteurs d'écran :
<span class="sr-only">(nouvelle fenêtre)</span> - Les liens qui n'ouvrent pas de nouvelle fenêtre ne doivent pas contenir
target="_blank"
3. Images
- Toute
<img>a un attributalt alt=""si l'image est purement décorativealtdescriptif et concis si l'image porte une info- Les images complexes (graphique, schéma) ont une description longue (texte à côté ou
aria-describedby) - Les SVG décoratifs ont
aria-hidden="true" - Les SVG porteurs de sens ont
role="img"+<title>
4. Couleurs et contrastes
- Ratio de contraste texte/fond ≥ 4.5:1 (texte normal)
- Ratio ≥ 3:1 pour le texte large (≥ 18pt regular ou 14pt bold)
- Ratio ≥ 3:1 pour les éléments graphiques interactifs
- Aucune information véhiculée uniquement par la couleur (ex : indiquer "erreur" aussi par une icône ou un texte)
- États
:focusvisibles avec un contour net (pas deoutline: nonesans remplacement)
5. Clavier et focus
- Tous les éléments interactifs sont accessibles au clavier (Tab, Entrée, Espace)
- Ordre de tabulation logique (séquence visuelle = séquence DOM)
- Pas de piège au clavier (focus bloqué dans un composant)
- L'élément actif a un indicateur de focus visible (contour, couleur)
- Les modales piègent correctement le focus et le restituent à la fermeture
- Raccourcis clavier personnalisés pas en conflit avec ceux du navigateur ou des lecteurs d'écran
6. Formulaires
- Chaque champ a une
<label>explicite associée viafor/id - Les champs obligatoires sont signalés (attribut
required+ mention visuelle) - Les messages d'erreur sont associés au champ via
aria-describedby - Les erreurs sont annoncées via
aria-live="polite"ourole="alert" - Les
fieldset/legendsont utilisés pour regrouper les champs liés (adresse, radio buttons) - L'autocomplétion HTML est utilisée (
autocomplete="email",name, etc.)
7. Médias
- Les vidéos ont des sous-titres synchronisés (pas seulement auto-générés)
- Les vidéos informatives ont une audiodescription ou une transcription
- Les fichiers audio ont une transcription textuelle
- Pas de lecture automatique (
autoplay) ou alors avec bouton pause visible - Les contrôles (play, pause, volume) sont au clavier
8. ARIA (à utiliser avec parcimonie)
Règle n°1 : un HTML sémantique correct vaut toujours mieux qu'un ARIA excessif.
- Ne pas mettre
role="button"sur une<div>: utiliser<button> - Ne pas dupliquer l'info native :
<button aria-label="Envoyer">Envoyer</button>est redondant - Utiliser
aria-labelpour les éléments sans texte visible (icônes cliquables) - Utiliser
aria-current="page"pour la page active d'une navigation - Utiliser
aria-expandedpour les composants collapsibles (accordéons, menus)
9. Zoom et responsive
- Le site reste utilisable à 200 % de zoom sans perte d'information
- Pas d'interdiction du zoom dans le
<meta viewport>(pas deuser-scalable=no) - Le contenu s'adapte à l'orientation portrait/paysage
- Utilisation d'unités relatives (
rem,em,%) plutôt que fixes enpxpour la typographie
10. Intégration dans le workflow dev
- Audit automatique avec WebAudit RGAA avant chaque release
- ESLint plugin
eslint-plugin-jsx-a11yactivé en CI - Tests unitaires vérifiant les rôles et labels (Testing Library :
getByRole) - Revue de code : checklist a11y obligatoire dans le template de PR
- Tests manuels au clavier avant chaque merge
- Tests avec un lecteur d'écran (NVDA gratuit sous Windows, VoiceOver sous macOS) périodiquement
Conclusion
L'accessibilité n'est ni un ajout final ni une couche de peinture : c'est une qualité native du code que vous produisez. En internalisant cette checklist et en l'intégrant à votre processus, vous gagnez simultanément en qualité UX, en SEO et en conformité légale. Commencez par le HTML sémantique et la navigation clavier : c'est là que se gagnent 60 % des points.
Pour aller plus loin :