Accessibilité web : principes fondamentaux
L’accessibilité web consiste à permettre à toute personne, quelles que soient ses capacités et ses technologies d’assistance, de percevoir, comprendre, naviguer et interagir avec un site. Ce guide présente les quatre principes POUR de WCAG, puis les recommandations clés par thème.
L’essentiel
- Quatre principes : Perceptible, Utilisable, Compréhensible, Robuste (POUR).
- Le HTML sémantique d’abord, ARIA seulement en complément.
- Les overlays automatiques ne rendent pas un site conforme.
- Les tests réels (clavier, lecteur d’écran, utilisateurs) complètent toujours l’audit automatisé.
Les quatre piliers POUR de WCAG
Chaque critère WCAG se rattache à l’un de ces principes.
- Perceivable (Perceptible)
- Transcriptions, alternatives textuelles, contraste suffisant, organisation visuelle claire.
- Operable (Utilisable)
- Navigation au clavier, ordre de tabulation logique, liens d’évitement, compatibilité mobile.
- Understandable (Compréhensible)
- Langue déclarée, retours cohérents, instructions simples, accessibilité cognitive.
- Robust (Robuste)
- Compatibilité avec les technologies d’assistance, ARIA conforme, code valide.
Navigation clavier et focus
Tout doit être utilisable sans souris : ordre de focus cohérent avec l’ordre visuel, focus toujours visible (contraste d’au moins 3:1), lien d’évitement en début de page, aucun piège clavier. Évitez les valeurs positives de tabindex. Réservez tabindex="-1" aux éléments qui reçoivent le focus par script, et non à la « sortie » d’éléments interactifs, qui deviendraient inaccessibles.
Testez avec : Tab, Maj+Tab, Entrée, Espace, flèches. Guide détaillé de la navigation clavier.
Accessibilité des formulaires
Un <label for> par champ, instructions avant le champ, erreurs explicites reliées au champ, <fieldset> et <legend> pour les groupes, alternative aux CAPTCHA, autocomplete sur les données personnelles. Guide détaillé des formulaires.
Accessibilité cognitive et neurodiversité
Langage simple, abréviations expliquées, étapes numérotées, aucune animation automatique non contrôlable, respect de prefers-reduced-motion, espacement généreux, retour immédiat après chaque action. Guide détaillé.
ARIA : bonnes pratiques
Règle d’or : « pas d’ARIA vaut mieux qu’un mauvais ARIA ». Utilisez d’abord l’élément HTML natif ; ARIA complète, il ne remplace pas. Guide détaillé ARIA.
Multimédia et contenus dynamiques
Transcription, sous-titres synchronisés (WebVTT), audio-description, aucune lecture automatique du son, contrôles accessibles. Guide détaillé.
Accessibilité mobile
Cibles tactiles larges et espacées, zoom autorisé, pas de dépendance au survol, test avec VoiceOver et TalkBack. Guide détaillé.
Overlays d’accessibilité : mises en garde
Les widgets et barres d’outils automatiques ne produisent pas la conformité WCAG ni RGAA : ils ne corrigent pas le code source et peuvent gêner les technologies d’assistance. En janvier 2025, la FTC américaine a sanctionné un éditeur d’overlay pour des affirmations trompeuses sur la conformité automatique. Corrigez le code, faites auditer par un expert et testez avec des utilisateurs.
Références : Overlay Fact Sheet et pourquoi éviter les overlays.
Tests avec des utilisateurs en situation réelle
- Incluez des personnes en situation de handicap visuel, moteur, auditif et cognitif.
- Observez la navigation réelle, puis recueillez les retours par questionnaire adapté.
- Testez au clavier seul, avec un lecteur d’écran (NVDA, JAWS, VoiceOver) et au tactile.
- Combinez audit automatisé (axe, WAVE…) et vérifications manuelles.
Intersectionnalité, localisation et langues
Déclarez la langue (lang) et ses changements, prévoyez des textes compatibles avec la traduction automatique, localisez dates, heures et devises, et testez sur plusieurs régions et langues. Référence : W3C Internationalization.
Questions fréquentes
Qu’est-ce que l’accessibilité web ?
C’est la capacité d’un site à être utilisé par tous, y compris les personnes en situation de handicap temporaire, permanent ou situationnel, avec ou sans technologie d’assistance.
Que signifie POUR en accessibilité ?
POUR désigne les quatre principes de WCAG : Perceptible, Utilisable (Operable), Compréhensible et Robuste.
Pourquoi dit-on a11y ?
C’est un numéronyme : « a », onze lettres, « y » pour « accessibility ».