Une accessibilité partielle est parfois pire qu’une absence totale d’accessibilité

Une accessibilité partielle est parfois pire qu’une absence totale d’accessibilité Par Sheri Byrne-Haber (personne en situation de handicap) Experte primée en ingénierie axée sur les valeurs, accessibilité et inclusion 17 juin 2026

Pour les personnes qui n’utilisent pas de technologies d’assistance, une accessibilité partielle semble être un compromis raisonnable. “Mieux vaut un peu d’accès que pas du tout”, pense-t-on souvent. Une organisation qui résout la moitié de ses problèmes d’accessibilité serait donc meilleure qu’une autre qui n’en résout aucun. Cela paraît généreux, voire logique. Pourtant, c’est une erreur.

Les personnes dépendantes des technologies d’assistance savent, elles, faire la différence entre un site qui échoue immédiatement et un autre qui échoue à mi-parcours. Le premier est une porte fermée : on la voit, on fait demi-tour, on perd dix secondes, et on passe à autre chose. Le second, lui, vous invite à entrer, vous fait perdre du temps et de l’énergie, vous permet de vous authentifier ou de créer un compte, de commencer la tâche pour laquelle vous êtes venu… puis vous abandonne devant un mur invisible. Quand vous le heurtez, vous avez déjà investi des ressources que vous ne pourrez pas récupérer. L’accessibilité partielle ne se situe pas à mi-chemin entre le fonctionnel et le défectueux. Elle produit souvent un résultat pire qu’une inaccessibilité totale, car elle vous trahit après vous avoir fait croire qu’elle ne le ferait pas.

C’est un aspect du débat sur l’accessibilité qui n’est pas assez souligné : une accessibilité à moitié faite n’est pas une demi-victoire. C’est un message clair : vous saviez qu’il fallait rendre le site accessible, mais vous avez choisi de le livrer à moitié terminé. Et il y a une dimension juridique à cette histoire, que les organisations sous-estiment systématiquement.

Pourquoi l’accessibilité partielle est un piège juridique

L’accessibilité partielle crée une trace écrite. Les parties accessibles de votre site prouvent que votre organisation dispose des connaissances, du budget et des capacités techniques pour se conformer aux normes WCAG… parfois. Les parties inaccessibles, côtoyant les autres, montrent que l’échec ailleurs n’était pas dû à l’ignorance ou à l’impossibilité technique. C’était un choix. Cette distinction compte dans :

• une enquête au titre du Title II (ADA),
• une mise en demeure au Title III,
• une plainte pour non-respect des Sections 504/508 (financement fédéral),
• ou devant un juge.

Les cabinets d’avocats des plaignants adorent les schémas d’accessibilité partielle, car ils éliminent les défenses les plus courantes :

• “La norme n’était pas claire”
• “La correction était irréalisable”
• “L’organisation agissait de bonne foi et n’avait pas encore eu le temps”

Une déclaration d’accessibilité sur la page d’accueil, liée à une application inaccessible, n’est pas la preuve d’un engagement. C’est une preuve, point. Les organisations qui livrent une accessibilité partielle remettent souvent, sans le savoir, les arguments les plus solides contre elles-mêmes aux avocats adverses.

Où se manifeste ce problème ? Et à quel prix ?

Voici les situations où l’accessibilité partielle piège les utilisateurs, et pourquoi l’argument “un peu d’accessibilité vaut mieux que rien” ne tient pas face à ceux qui en dépendent.

1. Le login accessible… mais le tableau de bord inaccessible

L’utilisateur s’authentifie sans problème : formulaire avec étiquettes visibles, ordre de tabulation logique, gestion des erreurs accessible, champ de mot de passe compatible avec les gestionnaires de mots de passe. Puis il arrive sur la page qu’il cherchait… et tout s’effondre.

• Le tableau n’a pas d’en-têtes.
• Les filtres sont des boutons non étiquetés, avec uniquement des icônes.
• La modale piège le focus et ne peut pas être fermée avec la touche Échap. L’utilisateur ne peut ni quitter la session sans tout perdre, ni accomplir la tâche pour laquelle il s’est connecté.

Pourquoi c’est un problème ? Rendre les logins accessibles est simple : c’est un modèle bien documenté, présent dans toutes les checklists, et c’est la première chose corrigée, car tous les utilisateurs l’utilisent. Mais le tableau de bord, c’est là que le travail réel se fait — et c’est aussi là que se cachent les composants personnalisés, le contenu dynamique et la dette d’accessibilité de l’équipe. Corriger la porte d’entrée sans corriger les pièces derrière donne l’illusion d’un bâtiment accueillant… qui ne l’est pas.

2. Le parcours principal accessible… mais les états d’erreur inaccessibles

Tout fonctionne… jusqu’à ce que quelque chose aille mal.

• L’utilisateur remplit un formulaire, le soumet, et attend.
• La page ne progresse pas.
• Un bord rouge apparaît sur un champ, une notification éphémère disparaît sans être annoncée, ou un message en ligne n’est pas associé programmatiquement au champ en erreur. L’utilisateur sait que quelque chose ne va pas… mais pas quoi, où, ni comment avancer.

Pourquoi c’est un problème ? Les états d’erreur révèlent la profondeur des programmes d’accessibilité.

• Une correction superficielle ne traite que le contenu visible et prévisible (le “happy path”).
• Une vraie correction inclut les messages de validation, les erreurs serveur, les délais d’inactivité, les échecs réseau, et toute la liste des messages qui n’apparaissent que quand quelque chose tourne mal. Or, la plupart des utilisateurs — handicapés ou non — rencontrent des erreurs régulièrement. Et les utilisateurs handicapés en rencontrent encore plus, car le formulaire était déjà plus difficile à remplir pour eux. Un manque d’accessibilité ici les frappe donc plus durement.

3. Le site desktop accessible… mais le site mobile inaccessible

L’équipe a corrigé l’expérience desktop, a effectué un audit, s’est félicitée… puis a livré une version mobile séparée, jamais testée avec TalkBack ou VoiceOver.

• Les cibles tactiles sont trop petites pour être touchées fiablement.
• Les gestes personnalisés n’ont pas d’alternatives.
• Le menu hamburger est un <div> avec un gestionnaire de clic et aucun rôle ARIA.
• La navigation mobile piège le focus dans un tiroir hors écran dont le lecteur d’écran ne peut s’échapper.
• Les champs de formulaire zooment de manière imprévisible quand l’utilisateur agrandit l’affichage.

Résultat : un utilisateur qui peut accomplir une tâche à son bureau ne peut plus le faire dans le bus.

Pourquoi c’est un problème ? Ce schéma est particulièrement douloureux, car le mobile est souvent le principal outil des utilisateurs handicapés :

• Un utilisateur aveugle avec VoiceOver sur iOS,
• Un utilisateur malvoyant avec un zoom système sur Android,
• Un utilisateur atteint de tremblements qui dépend des ajustements tactiles,
• Un utilisateur avec des troubles cognitifs qui utilise un lanceur simplifié… Ce ne sont pas des cas marginaux. C’est la réalité quotidienne de l’accès mobile. Traiter le mobile comme une préoccupation secondaire, c’est considérer ces utilisateurs comme secondaires aussi.

4. Les pages publiques accessibles… mais les pages authentifiées inaccessibles

C’est là que le marketing obtient le budget et les délais… mais pas le produit.

• Toutes les pages qu’un client potentiel voit sont impeccables.
• Toutes les pages qu’un client réel utilise sont un désastre.

Exemples courants :

• Dans le secteur public : la page d’accueil et la déclaration ADA sont irréprochables, mais les formulaires de demande de permis, les portails de prestations, les recherches de taxes foncières, les systèmes de paiement ou les demandes de dossiers (souvent fournis par des tiers) sont inutilisables.
• Dans le secteur privé : le site marketing est conçu par une agence soucieuse d’accessibilité… mais l’application est développée par une équipe d’ingénieurs qui ne l’est pas.

Résultat : une marque qui affiche son inclusion à l’entrée… et dresse des barrières une fois à l’intérieur. Les utilisateurs handicapés apprennent vite à se méfier de ces signaux. Ils anticipent l’écart, planifient en conséquence, et dévaluent le marketing. Les organisations qui maintiennent cet écart le plus longtemps sont souvent celles qui sont les plus surprises par une plainte ou un procès… car elles pointent leur page d’accueil accessible comme preuve de leur engagement, sans réaliser que ce n’est pas là que leurs utilisateurs bloquent.

5. L’application web accessible… mais le PDF inaccessible

L’interface est propre. L’utilisateur navigue jusqu’à la ressource dont il a besoin. La ressource est une image scannée de document, sans OCR, sans balises, sans ordre de lecture, sans lien vers un format alternatif. Tout ce qui précède n’était qu’un prélude à une impasse. L’utilisateur a fait l’effort pour accéder au document… et c’est le document qui comptait.

Pourquoi c’est un problème ? Ce schéma est endémique dans l’administration et l’éducation, où des décennies de notes de service, de comptes-rendus, de formulaires et de rapports ont été produits comme des documents papier, scannés et publiés sans remédiation. L’enveloppe web peut être accessible… mais cela ne garantit pas que le contenu qu’elle est censée livrer le soit aussi. Les travaux de conformité au Title II mettront ce problème en lumière à grande échelle, car le contenu derrière les portails apparemment accessibles contient souvent les plus gros retards de correction.

6. Le site accessible ce trimestre… inaccessible le prochain

Une refonte est livrée. Le nouveau framework a été choisi pour la rapidité de développement, la nouvelle bibliothèque de composants pour leur finition visuelle. Personne dans l’équipe de mise en œuvre n’a l’accessibilité dans ses objectifs de performance.

• Les corrections de l’audit précédent ont disparu.
• Les nouveaux composants réintroduisent d’anciens problèmes.
• Les menus déroulants personnalisés ont perdu leur support clavier.
• Le nouveau système d’icônes a supprimé les étiquettes textuelles.
• Le carrousel enfin accessible est maintenant un défilement CSS sans contrôles.

Les utilisateurs qui avaient appris à naviguer sur le site doivent tout réapprendre… et la mémoire institutionnelle des corrections apportées s’est évaporée avec l’équipe qui les avait faites.

Pourquoi c’est un problème ? L’accessibilité n’est pas un projet ponctuel. La traiter comme tel garantit une régression à la prochaine mise à jour majeure.

• Les organisations qui maintiennent leurs acquis sont celles qui ont intégré l’accessibilité dans :
  • les systèmes de design,
  • les bibliothèques de composants,
  • la définition de “terminé”,
  • les checklists de revue de code,
  • les contrats d’achat,
  • les évaluations de performance.
• Les organisations qui ont fait une correction ponctuelle et déclaré victoire sont celles dont les audits, deux ans plus tard, ressemblent étrangement à ceux d’il y a deux ans.

7. Le site parent accessible… mais le widget tiers inaccessible

Le site a été construit avec soin. Puis un widget de chat, un lecteur vidéo, un outil de sondage, un iframe de paiement, une bannière de cookies, une superposition d’analytique, une visite guidée, un overlay d’accessibilité ou une popup de feedback client a été ajouté… et il ne respecte pas les mêmes normes. Les utilisateurs en tiennent le site pour responsable, et ils ont raison. Le propriétaire du site a choisi le fournisseur, signé le contrat, accepté l’utilisation open source, et ajouté la balise <script>.

Pourquoi c’est un problème ? Ce schéma est le plus facile à corriger en théorie… et le plus difficile en pratique.

• Solution pour les widgets tiers :
  • Exiger un Rapport de Conformité Accessibilité (ACR) à jour lors de l’achat,
  • Imposer des délais de correction contractuels,
  • Prévoir un droit de résiliation en cas de non-conformité.
• Solution pour l’open source :
  • Éviter d’utiliser des produits open source inaccessibles si leur UI est exposée,
  • Sauf si vous prévoyez de les corriger (et, idéalement, de contribuer la correction en retour).

Le problème ? Les personnes qui choisissent ces widgets sont souvent des responsables marketing, support ou produit… qui ne savent pas ce qu’est un ACR, n’en demandent pas, et ne découvrent le problème d’accessibilité que lorsqu’un utilisateur se plaint ou qu’une plainte est déposée. Combler ce fossé nécessite que l’accessibilité soit présente dans les processus d’achat… et pas seulement dans le développement.

8. Le contenu accessible… mais le CAPTCHA inaccessible

L’utilisateur lit l’article. Il clique sur “S’abonner”. Un puzzle visuel l’arrête net :

• Aucune alternative audio,
• Ou une alternative audio incompréhensible,
• Ou une grille “cliquez sur tous les bus” qui expire avant qu’un utilisateur avec un grossissement puisse la parcourir,
• Ou un reCAPTCHA invisible qui le marque comme un bot parce que son technologie d’assistance produit un schéma d’interaction inhabituel.

Tout ce qui précède est gâché. L’utilisateur est bloqué à la dernière étape, et ce blocage est invisible pour le propriétaire du site, car les analytiques montrent un “clic sur le bouton S’abonner”… et non un “humain bloqué par une barrière anti-humaine”.

Pourquoi c’est un problème ?

• Chaque CAPTCHA inaccessible gaspille au moins 20 minutes du temps d’un utilisateur handicapé.
• C’est assez pour le mettre en colère… et l’inciter à chercher un avocat ou à envisager de déposer plainte.
• Le CAPTCHA est un cas rare où le problème d’accessibilité est aussi un problème de sécurité, d’utilisabilité et de fraude.
• Les alternatives existent. La raison pour laquelle le CAPTCHA persiste sous une forme inaccessible ? L’inertie, pas la nécessité.

Ce que dit l’accessibilité partielle au monde

Voici la partie qui fait mal au-delà de l’expérience utilisateur : L’accessibilité partielle signale au monde que vous êtes conscient de l’accessibilité.

• Vous saviez assez pour étiqueter le héros de la page d’accueil.
• Vous saviez assez pour ajouter des liens de saut.
• Vous saviez assez pour corriger le produit phare.
• Vous saviez assez pour publier une déclaration d’accessibilité.

Cela signifie que les parties inaccessibles ne sont pas une négligence… mais des décisions nées de la paresse ou d’une mauvaise priorisation. Ces décisions envoient un message silencieux sur quels utilisateurs comptent pour vous… et lesquels ne comptent pas.

• Les avocats des plaignants savent lire ce message. La plainte citera :

  • votre déclaration d’accessibilité comme preuve que vous étiez informé,
  • vos pages corrigées comme preuve que vous aviez les moyens de vous conformer,
  • vos pages non corrigées comme preuve d’un choix délibéré d’exclure certains utilisateurs.

• Les régulateurs savent le lire. La règle du Title II du DOJ ne récompense pas la conformité partielle. WCAG 2.1 Niveau AA est la norme, et elle s’applique :

  • au contenu web,
  • aux applications mobiles (au pluriel),
  • aux documents,
  • aux réseaux sociaux. Pointer du doigt les parties que vous avez corrigées n’excuse pas celles que vous n’avez pas corrigées.

• Les utilisateurs handicapés savent le lire aussi. Car ils lisent cette histoire d’inachèvement depuis toujours. L’utilisateur qui ne peut pas accomplir une tâche sur votre site ne se demande pas si vous avez essayé. Il sait pertinemment que vous avez essayé à certains endroits… et pas à d’autres. Et il porte un jugement sur votre organisation en fonction de là où vous avez tracé la limite.

Que faire à la place ?

Si vous faites de l’accessibilité, faites-la pour toute l’expérience.

• Chaque page, chaque état, chaque appareil, chaque fournisseur, chaque version.

Intégrez l’accessibilité dans le système de design, pas par-dessus.

• Un composant accessible dans la bibliothèque l’est partout où il est utilisé.
• Un composant corrigé dans une fonctionnalité et cassé dans une autre garantit l’incohérence que vous essayez d’éviter.

Testez les conditions limites, pas seulement le parcours idéal.

• Les erreurs, les états vides, les états de chargement, les délais d’attente, les refus d’autorisation et les cas particuliers ont besoin des mêmes tests avec les technologies d’assistance que les parcours de succès.

Testez sur mobile ET desktop.

• Avec de vrais lecteurs d’écran, loupes, interrupteurs, commandes vocales et paramètres d’accessibilité sur les appareils mobiles.
• Les tests automatisés sont un point de départ, pas une ligne d’arrivée.

Tenez les tiers aux mêmes normes que vous.

• Exigez des ACR lors des achats,
• Intégrez des délais de correction dans les contrats,
• Abandonnez et continuez à chercher si les fournisseurs refusent.

Traitez les régressions d’accessibilité comme des bugs.

• Si une version réintroduit un problème d’accessibilité qu’une version précédente avait corrigé, c’est un bug.
• Il doit être priorisé comme une erreur fonctionnelle grave, car c’en est une pour un utilisateur handicapé.

Planifiez la parité, pas les communiqués de presse.

• L’objectif n’est pas de rendre certaines parties accessibles.
• L’objectif est d’offrir une expérience accessible.

Tout le reste est un piège déguisé en progrès… et les personnes que vous piégez sont précisément celles que vous prétendez vouloir inclure.

Le piège du “Mieux vaut un peu que rien”

“Progress over perfection” (“Mieux vaut progresser que viser la perfection”) est devenu le laissez-passer de l’industrie de l’accessibilité pour s’arrêter avant la fin. Cette phrase est répétée dans :

• les conférences,
• les notes de direction,
• les arguments commerciaux des fournisseurs,
• les justifications internes que les organisations se donnent quand le budget de correction est épuisé.

Elle sonne humble et pragmatique… mais elle n’est ni l’un ni l’autre.

• Elle présente un travail inachevé comme une vertu,
• et traite les utilisateurs toujours exclus comme un coût acceptable de la raison.

Le cadre honnête, c’est “Progress toward perfection” (“Progresser vers la perfection”). Aucune organisation n’atteindra jamais l’état parfait.

• Les normes WCAG continueront d’évoluer,
• vos produits continueront de changer,
• de nouveaux contenus seront créés,
• de nouveaux fournisseurs seront intégrés,
• de nouveaux handicaps et technologies d’assistance entreront dans la conversation.

La perfection n’est pas une destination, mais une direction.

• Cette direction compte.
• L’engagement à continuer dans cette direction est ce qui distingue :
  • les organisations qui essayent vraiment,
  • de celles qui ont décidé que leur niveau actuel d’exclusion était suffisant.

Progresser vers la perfection signifie :

• Vous ne vous arrêtez pas quand les victoires faciles sont acquises.
• Vous ne déclarez pas la victoire parce que votre page d’accueil est conforme au niveau AA… alors que le reflow ne fonctionne pas.
• Vous ne traitez pas le prochain composant inaccessible, le prochain PDF inaccessible, le prochain fournisseur inaccessible comme le problème de quelqu’un d’autre ou de l’année prochaine.

Vous continuez… … car les personnes pour qui vous faites cela ne cessent pas d’être handicapées quand votre feuille de route est épuisée. Elles ne devraient pas avoir à attendre un nouveau cycle budgétaire pour utiliser vos services.

L’objectif n’est pas d’être parfait. L’objectif est de ne jamais abandonner l’objectif de la perfection.