Par où commencer l'accessibilité quand elle paraît immense

La première chose à comprendre : vous n’avez pas à tout corriger d’un coup

Lorsque les organisations découvrent les WCAG 2.2 pour la première fois, la réaction est souvent un mélange de préoccupation sincère et de sentiment d’être dépassé. Il existe 78 critères de succès répartis sur trois niveaux de conformité. La documentation des techniques associées est colossale. Les analyses automatisées produisent des listes de centaines de problèmes. On a l’impression qu’il faudrait tout mettre en pause et consacrer des mois de temps de développement avant même de pouvoir envisager de qualifier son site d’accessible.

Ce sentiment est compréhensible, mais trompeur. L’amélioration de l’accessibilité n’est pas un état binaire — accessible ou non accessible. C’est un continuum, et des progrès significatifs sont possibles à partir de là où vous êtes aujourd’hui, même si ce point de départ est « nous n’y avions jamais réfléchi auparavant ».

L’objectif de ce guide est de vous aider à démarrer.

Pourquoi se sentir dépassé est normal

L’accessibilité web paraît immense parce qu’elle l’est réellement. Les WCAG couvrent la présentation visuelle (contraste, taille du texte, espacement), le contenu auditif (sous-titres, transcriptions), l’interaction (navigation au clavier, délais, mouvement), la sémantique (structure, étiquettes, rôles) et les considérations cognitives (langage, cohérence, récupération d’erreur). Ils s’appliquent sur ordinateur, sur mobile et avec les technologies d’assistance. Ils concernent le design, le contenu, le développement et les tests.

Mais voici ce qui change la donne : la plupart des défaillances d’accessibilité se regroupent autour d’un petit nombre de schémas récurrents. Année après année, le rapport WebAIM Million (qui analyse le million de sites les plus visités) constate que les mêmes six problèmes représentent l’écrasante majorité des défaillances WCAG détectables automatiquement :

Contraste de couleurs insuffisant
Texte alternatif manquant sur les images
Étiquettes de champ de formulaire manquantes
Liens vides (liens sans texte)
Langue du document manquante
Boutons vides (boutons sans texte)

Ces six schémas à eux seuls sont présents sur plus de 95 % des pages d’accueil testées. Les corriger sur votre site ne vous rend pas pleinement accessible, mais cela supprime des obstacles qui touchent le plus grand nombre d’utilisateurs en situation de handicap. C’est un point de départ significatif.

Étape 1 : comprendre votre position actuelle

Avant de pouvoir prioriser les corrections, vous devez savoir où vous en êtes. Une analyse automatisée gratuite vous le donne en quelques minutes.

Les outils automatisés ne constituent pas une solution d’accessibilité complète — ils ne détectent de manière fiable que 30 à 40 % des défaillances WCAG, car la plupart des obstacles requièrent un jugement humain pour être décelés. Mais ils excellent à repérer les défaillances courantes et automatisables énumérées ci-dessus : contraste, texte alternatif manquant, champs non étiquetés et problèmes structurels similaires.

Lancez une analyse gratuite de votre site. Regardez ce qui remonte. Les problèmes signalés sont réels — ce ne seront pas des faux positifs pour les schémas courants — et ils constituent une liste de départ concrète.

Étape 2 : prioriser selon l’impact, pas l’exhaustivité

Une fois que vous disposez d’une liste, la tentation est de traiter chaque élément dans l’ordre. Résistez-y. Priorisez plutôt selon la combinaison de l’impact et de la fréquence :

Impact le plus élevé (à corriger en premier) :

Tout obstacle dans votre tunnel de paiement, votre inscription ou votre principal parcours de conversion — si les utilisateurs ne peuvent pas finaliser la transaction, la défaillance d’accessibilité vous coûte des affaires
Les obstacles de connexion et d’authentification — les utilisateurs qui ne peuvent pas entrer ne peuvent rien utiliser
La navigation — si les utilisateurs ne trouvent pas les pages, l’accessibilité au niveau de la page n’a plus d’importance

Impact élevé (à corriger en deuxième) :

Les pages de contenu principales : pages produits, pages d’information, le contenu que les utilisateurs visitent spécifiquement pour l’obtenir
Les champs de formulaire, leurs étiquettes et leurs messages d’erreur — les formulaires sont le lieu de l’interaction
Les défaillances de contraste — elles touchent une très large population et sont généralement des corrections simples

Important mais moins urgent (à corriger plus tard) :

Le contenu d’archive et les pages plus anciennes à faible trafic
Les interactions marginales et les critères WCAG qui concernent de plus petites populations
Les exigences de niveau AAA (qui vont au-delà de la norme légale)

Vous n’avez pas besoin d’obtenir des scores parfaits avant que vos pages à plus fort trafic et à plus forte conversion soient accessibles. Traitez celles-là correctement en premier.

Étape 3 : ajouter des tests manuels pour ce que l’automatisation manque

Une fois vos problèmes automatisés maîtrisés, la couche suivante est le test manuel. C’est là que vous trouverez :

Les défaillances de navigation au clavier — les utilisateurs peuvent-ils parcourir tout votre site à la tabulation sans souris ?
Les problèmes de gestion du focus — après l’ouverture d’une fenêtre modale, le focus se déplace-t-il à l’intérieur de celle-ci ? Après sa fermeture, revient-il ?
Le comportement du lecteur d’écran — votre menu déroulant personnalisé annonce-t-il son état ? Votre carrousel indique-t-il quelle diapositive est active ?
L’ordre de lecture logique — si vous retirez le CSS, la page a-t-elle encore du sens ?

La façon la plus rapide de se lancer dans les tests manuels est la suivante :

Débranchez votre souris et essayez de réaliser le principal parcours utilisateur de votre site en utilisant uniquement votre clavier (Tab, Maj+Tab, Entrée, Espace, Échap, touches fléchées). Notez tout ce qui ne fonctionne pas.
Téléchargez un lecteur d’écran gratuit (NVDA pour Windows est gratuit ; VoiceOver est intégré à Mac et iOS). Parcourez vos pages les plus importantes. Écoutez ce qui est annoncé. Est-ce cohérent ?
Utilisez les outils d’accessibilité du navigateur — Chrome et Firefox disposent tous deux d’inspecteurs d’accessibilité qui affichent l’arbre d’accessibilité, les rôles ARIA et les noms accessibles calculés pour chaque élément.

Ces tests demandent du temps pour être maîtrisés, mais ne coûtent rien, et ils révéleront des problèmes qu’aucun outil automatisé ne trouvera.

Étape 4 : l’intégrer à votre flux de travail

La façon la plus coûteuse de faire de l’accessibilité est de la traiter comme un exercice de remédiation — corriger le site, crier victoire, puis regarder de nouveaux obstacles s’accumuler à chaque nouvelle version de fonctionnalité.

Une accessibilité durable signifie changer votre façon de travailler :

Revue de design — le design respecte-t-il les exigences de contraste ? Les états interactifs sont-ils visibles ?
Développement — utilise-t-on des éléments HTML natifs là où c’est possible ? Les champs de formulaire sont-ils étiquetés ? Les composants personnalisés ont-ils les bons attributs ARIA ?
Contenu — chaque image a-t-elle un texte alternatif approprié ? Les liens sont-ils descriptifs ?
Tests — l’intégration continue bloque-t-elle en cas de régression d’accessibilité ? Existe-t-il une étape de test manuel avant les versions majeures ?

Notre guide sur l’accessibilité dans le cycle de développement logiciel approfondit ce à quoi cela ressemble en pratique. Notre service d’intégration CI/CD fait de la couche automatisée une partie de chaque build.

Fixer des attentes réalistes

Pour un site web qui n’a jamais fait l’objet d’une revue d’accessibilité, atteindre la conformité WCAG 2.1 niveau AA sur chaque page est généralement un projet de plusieurs mois — plus long pour les sites vastes et complexes comportant un code hérité important.

Cela ne signifie pas que vous ne pouvez pas faire de progrès significatifs au cours des deux prochaines semaines. Corriger les six problèmes les plus courants que j’ai énumérés ci-dessus rend votre site sensiblement plus accessible pour une population importante, même si cela ne vous met pas en conformité légale.

Le cadre que je trouve le plus utile : visez l’amélioration continue plutôt que la conformité comme destination. À chaque cycle de sprint, résolvez un ensemble de problèmes identifiés. Effectuez des vérifications automatisées sur les nouvelles fonctionnalités avant leur mise en production. Planifiez des tests manuels chaque trimestre. Rédigez une déclaration d’accessibilité qui reflète honnêtement votre état actuel et votre feuille de route.

Les organisations qui abordent l’accessibilité de cette manière tendent à progresser globalement plus vite que celles qui attendent de pouvoir mobiliser un projet de remédiation complet.

Par où commencer aujourd’hui

Si vous n’avez encore rien fait : lancez une analyse gratuite. Vous aurez une véritable liste de problèmes réels en deux minutes, priorisés par gravité. C’est votre point de départ.

Si vous avez lancé des analyses mais n’êtes pas passé aux tests manuels : essayez le test au clavier uniquement sur votre tunnel de paiement dès aujourd’hui. Si vous trouvez des obstacles, vous avez trouvé votre prochaine priorité.

Si vous faites des tests manuels mais ne les avez pas intégrés à votre flux de travail : lisez notre guide sur l’accessibilité dans le processus de développement et identifiez un point de votre flux de travail actuel où une vérification d’accessibilité pourrait être ajoutée.

Le progrès vaut mieux que la perfection. Commencez quelque part.