Comment répondre à une plainte d'accessibilité

Pourquoi votre réponse compte plus que la plainte

Les plaintes d’accessibilité — qu’elles soient déposées via un formulaire de contact, envoyées par e-mail, soumises à un régulateur, ou délivrées sous forme de mise en demeure juridique formelle — sont rarement la fin de l’histoire. La façon dont vous répondez déterminera ce qui se passe ensuite.

Une réponse rapide, sincère et orientée vers l’action résout la plupart des plaintes sans escalade. Une réponse évasive, désinvolte ou absente est fréquemment ce qui transforme une plainte utilisateur réparable en enquête formelle ou en procès.

Ce guide couvre la gestion des plaintes d’accessibilité à chaque étape : depuis le moment où vous en recevez une jusqu’à la correction, la communication, et la mise en place de systèmes pour que la même plainte ne se reproduise pas.

Comprendre le type de plainte que vous avez reçu

Toutes les plaintes d’accessibilité ne se ressemblent pas, et la réponse appropriée varie selon le type.

Retour utilisateur

La forme la plus courante. Une personne en situation de handicap a rencontré un obstacle sur votre site — un formulaire qu’elle n’a pas pu remplir avec un lecteur d’écran, une vidéo sans sous-titres, un bouton inatteignable au clavier — et l’a signalé directement via votre page de contact, votre mécanisme de retour d’accessibilité, ou votre canal d’assistance général.

Ces plaintes constituent souvent le retour le plus précieux que votre équipe recevra jamais. Elles identifient de véritables obstacles rencontrés par de vrais utilisateurs dans des situations réelles, que les outils automatisés manquent fréquemment.

Plainte réglementaire ou gouvernementale

Au Royaume-Uni, un utilisateur peut signaler un problème au Government Digital Service (GDS) ou à l’Equality and Human Rights Commission (EHRC). Aux États-Unis, les plaintes peuvent être déposées auprès du Department of Justice (DOJ), de l’Office for Civil Rights (OCR) du Department of Education, ou d’autres agences fédérales. Dans l’UE, les plaintes sont adressées aux organismes d’application nationaux désignés au titre de la directive sur l’accessibilité du web.

Ces plaintes suivent une procédure formelle. Vous recevrez généralement une notification écrite, une description de la violation alléguée, et un délai de réponse.

Lettre de mise en demeure

Aux États-Unis, c’est souvent le premier signe qu’un plaignant a l’intention d’engager une action en justice au titre du Titre III de l’ADA. La lettre décrit les violations alléguées et propose généralement des conditions de règlement. Il s’agit d’une question juridique nécessitant un traitement distinct — voir notre guide sur les lettres de mise en demeure ADA pour une présentation détaillée.

Retour via la déclaration d’accessibilité

Si votre site dispose d’une déclaration d’accessibilité publiée avec un mécanisme de retour (obligatoire au titre du PSBAR au Royaume-Uni et fortement recommandé partout ailleurs), vous pouvez recevoir un retour structuré par ce biais. Ces retours sont souvent détaillés et précis, et méritent le même traitement que toute autre plainte.

Étape 1 : accuser réception rapidement

La chose la plus importante que vous puissiez faire lorsqu’une plainte d’accessibilité arrive est de répondre rapidement pour confirmer que vous l’avez reçue.

Cela reste vrai même si vous ne pouvez pas enquêter immédiatement sur le problème. Un accusé de réception le jour même ou le jour ouvré suivant montre que vous prenez la plainte au sérieux. Cela évite aussi que la personne à l’origine de la plainte suppose que son message a été ignoré — un déclencheur fréquent d’escalade.

Votre accusé de réception devrait :

Confirmer que vous avez reçu la plainte
Nommer une personne ou une équipe spécifique responsable du suivi
Donner un délai réaliste pour une réponse complète (voir Étape 3)
Remercier la personne d’avoir signalé le problème — elle vous aide à identifier un obstacle qui touche aussi d’autres utilisateurs

Gardez un ton professionnel et sincèrement reconnaissant. Les personnes qui signalent des obstacles d’accessibilité sont souvent des utilisateurs qui ont essayé d’autres solutions de contournement sans succès. Elles consacrent un temps qu’elles ne devraient pas avoir à dépenser.

Modèle :

Merci de nous avoir contactés. Nous avons bien reçu votre message et examinons le problème que vous avez décrit. Un membre de notre équipe reviendra vers vous dans un délai de [délai] avec une mise à jour. Nous prenons l’accessibilité au sérieux et vous remercions d’avoir porté ce point à notre attention.

Étape 2 : enquêter sur l’obstacle précis

Une fois l’accusé de réception envoyé, enquêtez sur le problème précis décrit par la personne. Résistez à la tentation de lancer un audit d’accessibilité général et de le présenter comme une réponse à la plainte spécifique — cela retarde la résolution et manque l’essentiel.

Ce qu’il faut examiner :

Pouvez-vous reproduire le problème ? Testez-le dans l’environnement décrit par la personne : le navigateur, le système d’exploitation et la technologie d’assistance qu’elle a mentionnés (si elle en a mentionné).
L’obstacle se situe-t-il au niveau d’un composant (un bouton, un formulaire ou une fenêtre modale spécifique) ou au niveau de la page ?
S’agit-il d’un problème de code, d’un problème de rédaction de contenu, ou d’un problème lié à un composant tiers ?
Le même obstacle apparaît-il ailleurs sur le site ?
Quel critère de succès WCAG viole-t-il (le cas échéant) ?

Outils de test à utiliser :

Clavier uniquement — pouvez-vous atteindre et actionner l’élément concerné avec Tab, Maj+Tab, Entrée, Espace et les flèches ?
Lecteur d’écran — testez avec NVDA + Chrome, JAWS + Chrome, et VoiceOver sur Safari (macOS/iOS). L’élément a-t-il un nom accessible ? Est-il annoncé correctement ?
Analyseur automatisé — lancez une analyse ciblée sur l’URL concernée pour repérer d’éventuels problèmes associés
Zoom à 200 % et réorganisation à 320px — la mise en page se casse-t-elle ?

Documentez vos constats. Vous avez besoin d’un enregistrement clair de ce qu’est l’obstacle, où il se trouve, et ce qui l’a causé.

Étape 3 : corrigez-le — et fixez un calendrier réaliste

Une fois l’obstacle compris, corrigez-le. La priorité et le calendrier doivent correspondre à la gravité :

Gravité	Exemples	Délai de correction cible
Critique	Formulaire de paiement inatteignable au clavier, connexion bloquée pour les utilisateurs de lecteur d’écran	24 à 72 heures
Grave	Texte alternatif manquant sur les images produit, champs de formulaire non étiquetés dans un parcours clé	Sous une semaine
Modérée	Faible contraste de couleur sur du contenu secondaire, structure de titres manquante	Dans le sprint en cours ou sous deux semaines
Mineure	Liens non descriptifs dans un article de blog, attribut `lang` manquant	Prochaine fenêtre de maintenance planifiée

Si la correction prend du temps — par exemple, elle nécessite qu’un prestataire tiers mette à jour son composant — communiquez-le à la personne à l’origine de la plainte. Indiquez-lui :

Ce qu’est l’obstacle
Ce qui le cause
Ce que vous faites pour le corriger
Quand vous prévoyez qu’il sera résolu
S’il existe un moyen alternatif pour elle d’accomplir la tâche en attendant

Le moyen d’accès alternatif est important. Si une personne ne peut pas utiliser votre système de paiement, proposez-lui de prendre sa commande par téléphone ou par e-mail pendant que la correction est en cours. Un « nous y travaillons » sans alternative n’est pas un aménagement raisonnable — cela indique simplement à l’utilisateur qu’il ne peut pas accéder à votre service.

Étape 4 : répondez à la personne avec des précisions

Lorsque la correction est terminée (ou lorsque vous avez un plan concret si elle prendra plus de temps), répondez à la personne avec une mise à jour substantielle. Cette réponse devrait :

Décrire le problème précis qui a été identifié
Expliquer ce que vous avez découvert lors de votre enquête
Indiquer ce qui a été corrigé, ou détailler le plan de correction avec un calendrier
Confirmer que la correction a été vérifiée (retestée)
Inviter la personne à tester l’expérience mise à jour et à signaler si l’obstacle persiste
Fournir un contact direct en cas de nouveaux problèmes

Évitez les rassurances vagues comme « nous avons amélioré notre accessibilité ». Soyez précis. Une personne qui ne pouvait pas se connecter avec un lecteur d’écran mérite de savoir exactement ce qui était défaillant et que c’est désormais corrigé.

Modèle :

Merci pour votre patience pendant que nous avons enquêté sur le problème que vous avez signalé. Nous avons identifié [problème précis] sur [page/composant précis]. Ce problème a été résolu — [brève description de la correction]. Nous avons retesté [la page/le composant] mis à jour et confirmé que [élément] est désormais [comportement accessible]. Nous serions ravis d’avoir votre retour si des problèmes persistent. Vous pouvez nous contacter directement à [contact].

Étape 5 : documentez tout

Pour chaque plainte d’accessibilité que vous recevez et résolvez, conservez un enregistrement qui inclut :

La date de réception et la date d’accusé de réception
Une description de l’obstacle signalé
Vos constats d’enquête
La correction appliquée et la date de son déploiement
La confirmation que la correction a été testée
L’ensemble des échanges avec la personne à l’origine de la plainte

Cette documentation répond à trois objectifs. Premièrement, elle démontre la bonne foi — si une plainte s’aggrave jusqu’à un régulateur ou une action en justice, un dossier de correction documenté constitue une preuve solide que vous avez pris l’affaire au sérieux et agi. Deuxièmement, elle alimente votre déclaration d’accessibilité, qui devrait lister les problèmes connus et leur statut de correction. Troisièmement, elle construit une connaissance institutionnelle des modes de défaillance récurrents dans votre code ou votre flux de production de contenu.

Étape 6 : mettez à jour votre déclaration d’accessibilité

Votre déclaration d’accessibilité devrait refléter l’état actuel connu de votre site. Après avoir résolu une plainte :

Retirez l’obstacle de toute liste de problèmes connus (s’il y figurait)
Mettez à jour la date de « dernière révision »
Si la plainte a révélé une catégorie de problèmes que vous n’aviez pas identifiée auparavant, ajoutez-la et notez son statut de correction

Une déclaration d’accessibilité qui reflète fidèlement les problèmes connus — y compris ceux qui ne sont pas encore corrigés, avec des délais réalistes — inspire davantage confiance qu’une déclaration prétendant à une conformité totale que les utilisateurs savent inexacte.

Gérer les plaintes que vous ne pouvez pas résoudre immédiatement

Parfois, un obstacle ne peut pas être corrigé rapidement : le composant appartient à un prestataire tiers qui n’a pas encore publié de correctif, la correction nécessite une migration de plateforme, ou le contenu se trouve dans un système ancien qui exige un effort important pour être mis à jour.

Dans ces cas :

Proposez un moyen d’accès alternatif. Cela est légalement requis dans la plupart des juridictions en tant qu’« aménagement raisonnable » ou équivalent. Il doit être véritablement équivalent — pas un substitut dégradé. Si un PDF est inaccessible, proposez de fournir l’information dans un format accessible par e-mail. Si un formulaire de réservation est bloqué pour les utilisateurs de lecteur d’écran, proposez de prendre les réservations par téléphone.

Soyez honnête sur le calendrier. Une personne à qui l’on dit « cela sera corrigé au troisième trimestre » n’est pas bien servie. Engagez-vous sur des jalons précis et respectez-les.

Faites remonter l’affaire en interne. Les plaintes concernant des parcours essentiels (connexion, paiement, gestion de compte, formulaires clés) doivent être traitées comme des problèmes d’ingénierie hautement prioritaires, pas comme de simples ajustements de contenu. Assurez-vous que les bonnes personnes en sont informées.

Répondre aux plaintes réglementaires

Si une plainte a été transmise à un régulateur — le GDS au Royaume-Uni, le DOJ ou l’OCR aux États-Unis, ou un organisme d’application national dans l’UE — la procédure est plus structurée.

Vous recevrez généralement :

Une notification formelle de plainte décrivant les allégations
Une demande de réponse formelle avant une date limite précisée
Dans certains cas, une invitation à participer à une médiation ou à une résolution informelle

Ne manquez jamais les délais. Une plainte réglementaire restée sans réponse, ou traitée en retard, signale un manque de coopération et renforce la position du plaignant.

Répondez précisément aux allégations formulées. Les régulateurs attendent une réponse qui traite les problèmes précis soulevés, pas une déclaration générale sur votre engagement envers l’accessibilité.

Fournissez des preuves de correction. Lorsque vous avez corrigé les obstacles signalés, fournissez de la documentation : captures d’écran, rapports d’audit, confirmation des dates de déploiement. Un régulateur qui constate que le problème a été résolu a nettement moins de raisons de poursuivre une action formelle.

Faites appel à un conseil juridique. Pour les plaintes réglementaires formelles, en particulier aux États-Unis où les enquêtes du DOJ peuvent avoir une portée large, il est conseillé de consulter un conseil juridique familier de l’accessibilité numérique.

Prévenir la prochaine plainte

Chaque plainte d’accessibilité est la preuve qu’un obstacle a atteint un utilisateur réel. L’objectif n’est pas seulement de résoudre les plaintes individuelles, mais de construire des systèmes qui empêchent l’apparition de nouveaux obstacles.

Intégrez l’accessibilité dans votre flux de développement. Des vérifications d’accessibilité automatisées dans votre pipeline CI/CD détectent les problèmes détectables avant qu’ils n’atteignent la production — pas après qu’un utilisateur les signale. Notre intégration CI/CD de l’accessibilité fait de cela une partie de chaque build.

Planifiez des audits réguliers. Les outils automatisés détectent 30 à 40 % des défaillances WCAG. Les audits manuels utilisant des lecteurs d’écran et une navigation uniquement au clavier trouvent le reste. Des audits trimestriels ou semestriels font apparaître les problèmes avant les utilisateurs.

Formez votre équipe. Les développeurs, designers et rédacteurs de contenu qui comprennent l’accessibilité créent moins d’obstacles. Une formation ponctuelle est moins efficace que l’intégration d’une revue d’accessibilité dans les critiques de design, les revues de code et les flux de publication de contenu.

Rendez votre mécanisme de retour véritablement facile à utiliser. Une déclaration d’accessibilité avec un mécanisme de contact fonctionnel et accessible offre aux utilisateurs une voie directe vers vous plutôt que vers un régulateur. De nombreuses plaintes s’aggravent précisément parce que le canal de retour du site était lui-même inaccessible.

Si vous souhaitez comprendre la position actuelle de votre site en matière d’accessibilité avant la prochaine plainte, une analyse automatisée gratuite est le point de départ le plus rapide. Pour une vision complète, contactez-nous pour discuter d’un audit complet.