Checklist accessibilité pour développeurs : 25 points à vérifier avant chaque mise en production

Publié le 10 septembre 2026 · Mis à jour le · L'équipe Vérif RGAA

Une checklist d'accessibilité pour développeurs tient en 25 points, du HTML sémantique à la gestion du focus, chacun relié à un critère du RGAA 4.1 et des WCAG 2.1. Passée avant chaque mise en production, elle évite la majorité des non-conformités relevées en audit et protège des sanctions (DGCCRF 7 500 € par infraction, Arcom jusqu'à 50 000 €) et des injonctions judiciaires. Vérifiez vos couleurs en cours de route avec le test de contraste.

Structure et sémantique

# Point Critère RGAA
1 Un attribut lang correct sur html, et sur les passages dans une autre langue 8.3, 8.4, 8.7
2 Un titre de page (title) unique et descriptif 8.5, 8.6
3 Un seul h1, hiérarchie de titres sans saut 9.1
4 Régions de page : header, nav, main, footer, avec aria-label si plusieurs nav 12.6
5 Listes en ul/ol, citations en blockquote, tableaux de données en table avec th et caption 9.3, 9.4, 5.6, 5.7
6 Lien d'évitement « Aller au contenu » en premier élément focusable 12.7

Images, couleurs, médias

# Point Critère RGAA
7 Alternative pertinente pour chaque image informative, alt vide pour les décoratives, description détaillée si nécessaire 1.1, 1.2, 1.3
8 Aucune information portée par la seule couleur (icône, texte ou motif en complément) 3.1
9 Contraste 4,5:1 pour le texte, 3:1 pour le texte large et les composants 3.2, 3.3
10 Vidéos avec sous-titres synchronisés et transcription ; audiodescription si l'image porte de l'information 4.1 à 4.5
11 Pas de lecture automatique de son ; contrôles de lecture accessibles 4.10, 4.11

Formulaires

# Point Critère RGAA
12 Chaque champ a une étiquette visible reliée (label for, ou aria-labelledby) 11.1, 11.2
13 Champs obligatoires signalés autrement que par la couleur, format attendu indiqué 11.10
14 Erreurs identifiées, expliquées, associées au champ, annoncées (aria-describedby, role alert) 11.10, 11.11
15 Autocomplete renseigné pour les données personnelles (name, email, tel) 11.13
16 Groupes de champs de même nature dans fieldset avec legend 11.5, 11.6

Clavier, focus, composants

# Point Critère RGAA
17 Tout élément interactif est atteignable et activable au clavier, sans piège 7.3, 12.13
18 Focus visible sur tous les éléments (pas d'outline: none sans remplacement) 10.7
19 Ordre de tabulation cohérent avec l'ordre visuel ; pas de tabindex positif 12.8
20 Composants personnalisés : rôle, nom, état exposés (role, aria-expanded, aria-selected…) et clavier géré selon les motifs ARIA 7.1
21 Modales : focus déplacé à l'ouverture, piégé à l'intérieur, rendu à l'ouverture ; fermeture par Échap 7.1, 7.3
22 Changements de contenu annoncés (aria-live) sans voler le focus 7.1

Présentation et consultation

# Point Critère RGAA
23 Zoom à 200 % et largeur de 320 px sans perte de contenu ni défilement horizontal 10.4, 10.11
24 Contenu lisible avec les feuilles de style désactivées ; pas de texte en image 10.1, 10.2, 1.8
25 Pas de limite de temps sans contrôle ; documents en téléchargement accessibles ou avec alternative 13.1, 13.3

Comment l'intégrer au flux de travail

Les cinq erreurs les plus coûteuses

Recréer un bouton avec un div cliquable : il n'est ni focusable ni activable au clavier, et le lecteur d'écran ne l'annonce pas comme bouton. Supprimer l'outline du focus pour des raisons esthétiques sans le remplacer : les utilisateurs de clavier perdent leur position. Étiqueter un champ par son seul placeholder : l'étiquette disparaît à la saisie et n'est pas toujours lue. Utiliser la couleur seule pour signaler une erreur ou un état : invisible pour une partie des utilisateurs. Ouvrir une modale sans déplacer le focus : le lecteur d'écran continue de lire la page derrière. Ces cinq erreurs représentent une part importante des non-conformités bloquantes constatées en audit.

Composants : les motifs à connaître

Pour les composants sans équivalent HTML natif, les motifs de conception ARIA du W3C décrivent les rôles, états et interactions clavier attendus : onglets (Tab pour entrer, flèches pour changer d'onglet), menus, accordéons, boîtes de dialogue, listes déroulantes personnalisées, curseurs. Reprendre ces motifs plutôt que d'inventer un comportement évite la plupart des défauts du critère 7.1 du RGAA. La règle reste de préférer l'élément natif quand il existe : select, details/summary, dialog, input type range.

Tester en continu

Un test automatique à chaque intégration (structure, attributs, contrastes, étiquettes) attrape environ un tiers des défauts ; il est rapide et sans coût. Le reste exige un test manuel : clavier, zoom, lecteur d'écran. Réservez ces dix minutes sur chaque fonctionnalité qui touche un parcours utilisateur, et faites réaliser un audit RGAA complet à chaque évolution majeure. Depuis la décision du tribunal judiciaire de Caen du 4 juin 2026, l'obligation est de résultat : le test manuel n'est plus optionnel.

Ajoutez la checklist à la définition de « terminé » de chaque ticket, exécutez un test automatique de base dans l'intégration continue (structure, attributs, contrastes) et réservez dix minutes de test manuel au clavier et au lecteur d'écran avant chaque mise en production. Les tests automatiques ne couvrent qu'une partie des 106 critères ; les points 7, 9, 17 à 22 exigent un humain. Pour une vérification globale d'un site existant, suivez l'audit rapide en 30 minutes ; pour les documents, PDF accessible : comment faire. Puis lancez le test d'accessibilité complet.

Questions fréquentes

Faut-il utiliser ARIA partout ?

Non. La première règle d'ARIA est de ne pas l'utiliser quand un élément HTML natif fait le travail : un bouton est un button, un lien est un a, une case à cocher est un input. ARIA sert aux composants qui n'ont pas d'équivalent natif (onglets, menus, arbres).

Un site conforme à cette checklist est-il conforme au RGAA ?

Pas nécessairement : la checklist couvre les points les plus fréquents côté développement ; le RGAA compte 106 critères, dont certains portent sur les contenus, les médias et les documents. Elle réduit fortement le nombre de non-conformités à l'audit.

Comment tester sans lecteur d'écran ?

VoiceOver est intégré à macOS et iOS, le Narrateur à Windows, TalkBack à Android ; NVDA est gratuit sur Windows. Dix minutes de navigation suffisent pour repérer les défauts d'ordre de lecture et d'annonce.

Sources officielles

Faits vérifiés le 10 septembre 2026. Voir la méthodologie.