Site web accessible et BFSG : ce que les PME devraient vérifier et ce qu’un overlay ne permet pas

La demande n’arrive pas, et personne ne s’en aperçoit. Un visiteur parcourt le formulaire de contact avec la touche de tabulation, atteint le champ « Objet », et soudain le focus part dans le vide : la liste déroulante est un élément fait maison qui ne réagit qu’aux clics de souris. Il abandonne. Dans les statistiques, ce moment n’apparaît nulle part, il ressemble à n’importe quel autre abandon.

Supposons que ce soit la situation de départ d’un petit prestataire de services avec un site soigné et visuellement attrayant. Le design vient d’un bon modèle, les textes sont soignés, le temps de chargement est correct. Que le site soit à peine utilisable pour des personnes malvoyantes, avec un tremblement, avec une seule main ou tout simplement sans souris ne figure dans aucun rapport. Quiconque l’essaierait l’aurait probablement réparé depuis longtemps.

L’accessibilité est donc moins une question de morale qu’une question de perception : on ne voit pas les obstacles tant qu’on ne les a pas vécus soi-même. Il faut ajouter que le groupe concerné est plus grand qu’on ne le pense. Les limitations durables en font partie, mais aussi un bras cassé, une lumière solaire éblouissante sur le smartphone, une vue qui baisse avec l’âge ou un mauvais écran de portable au bureau.

Pour les petites entreprises s’ajoute une réflexion lucide : chaque demande compte. Là où une entreprise ne reçoit que quelques contacts par semaine, un formulaire qui exclut une partie des visiteurs n’est pas un sujet technique marginal, mais une commande perdue. L’ampleur de cette part ne peut pas être chiffrée de manière générale. Une seule chose est sûre : elle ne se montre pas d’elle-même et ne devient visible que par des essais ciblés.

Les types d’erreurs se répètent tellement qu’on peut bien les classer. Du texte gris sur fond gris clair, qui paraît élégant et est à peine lisible en pratique. Un menu qui s’ouvre au survol de la souris et reste inaccessible au clavier. Un contour de focus qu’un designer a supprimé en CSS « pour un rendu propre ». Des images sans description ou avec le nom de fichier en guise de description. Des champs de formulaire expliqués uniquement par un texte indicatif qui disparaît à la saisie.

S’ajoutent des erreurs de structure invisibles à l’œil. Les titres sont choisis selon la taille de police plutôt que selon leur sens, les boutons sont en réalité des blocs de texte cliquables, sans rôle et sans fonction clavier. Un lecteur d’écran lit alors « groupe, groupe, groupe » ou saute l’essentiel. Pour les visiteurs voyants, cela reste invisible, car l’œil déduit de la mise en page et de la couleur un sens que le code ne fournit pas.

Pourquoi cela reste-t-il si longtemps inaperçu ? Parce que les contrôles qualité habituels ne le détectent pas. Une revue de design évalue l’impression, un test vérifie que le bouton déclenche un clic, et l’analyse d’audience montre des abandons sans cause. L’accessibilité exige un regard que personne n’adopte au quotidien : utiliser la page sans souris, sans distinguer les couleurs ou sans image. Celui qui a entraîné ce regard une fois trouve étonnamment vite des défauts.

Les Web Content Accessibility Guidelines, WCAG en abrégé, s’articulent autour de quatre principes. Les contenus doivent être perceptibles, l’utilisation doit être possible, les contenus et l’utilisation doivent rester compréhensibles, et le code doit être assez robuste pour que des technologies différentes puissent l’interpréter. Des principes découlent des recommandations et des critères de succès vérifiables, répartis en trois niveaux : A, AA et AAA. En pratique, c’est surtout le niveau AA qui compte.

L’intérêt des principes est qu’ils structurent les questions. « Perceptible » demande si quelqu’un peut saisir le contenu par au moins un canal sensoriel. « Utilisable » demande si chaque fonction peut être employée sans maniement précis de la souris, sans contrainte de temps et sans gestes. « Compréhensible » concerne la langue, la prévisibilité et l’aide en cas d’erreur de saisie. « Robuste » signifie un balisage propre, afin que les lecteurs d’écran et autres aides techniques n’aient pas à deviner.

Un exemple le rend concret. Un menu à onglets pour les prestations est visuellement clair, mais sans rôles ni états, un lecteur d’écran ne sait pas quel onglet est actif (robuste), les touches fléchées ne font rien (utilisable), l’onglet actif ne se distingue que par une nuance de couleur (perceptible), et les libellés sont des abréviations que personne n’explique (compréhensible). Un seul composant enfreint ici les quatre principes à la fois.

Nous utilisons cette grille comme aide à la réflexion et non comme liste à cocher. Une liste de contrôle incite à traiter chaque critère isolément et à perdre l’ensemble de vue. Mieux vaut poser la question par type de page : qui pourrait échouer ici, et à quoi le remarquerait-on ? Il en résulte une vérification qui s’appuie sur l’usage réel et prend les critères comme étalon.

La voie la plus tentante est un overlay : un script qui affiche un symbole en bordure de page et promet de rendre le site accessible avec une ligne de code. Pour les petites entreprises, c’est séduisant, car c’est bon marché, rapide et cela sonne comme une solution. Le problème tient au mécanisme. Un script qui modifie des propriétés dans le navigateur à l’exécution ne peut que deviner les étiquettes manquantes et la structure erronée, sans les compléter de façon fiable.

S’y ajoute un conflit pratique. Les utilisateurs de lecteurs d’écran et de claviers ont déjà configuré leurs aides techniques, et un overlay supplémentaire peut les gêner au lieu de les aider. Que les overlays ne corrigent pas un code défectueux est largement connu des spécialistes, et plusieurs associations de personnes concernées les rejettent. Un affichage « accessible » sur le site ne remplace par ailleurs pas une vérification et ne prouve aucune conformité.

Cela ne veut pas dire que toute barre de réglages est inutile. Une fonction d’agrandissement de la police ou de changement de contraste peut apporter du confort. Mais c’est un complément, pas une fondation. L’essentiel est que la page soit proprement construite sans aucun outil additionnel. Nous recommandons donc de corriger la cause dans le code source et dans la conception, ce qui est en règle générale aussi plus rentable qu’une solution d’abonnement permanente qui ne change rien à la fondation.

Avant d’utiliser un tel produit, trois questions au fournisseur valent la peine : que modifie-t-il exactement, et où le code source reste-t-il intact ? Qui est responsable si la page contient des obstacles malgré le label ? Et que devient votre page si vous résiliez le contrat ? Si les réponses sont évasives, c’est déjà en soi une information utile.

La Barrierefreiheitsstärkungsgesetz, BFSG en abrégé, transpose une directive européenne et s’applique en Allemagne depuis l’été 2025. Elle ne vise pas tous les sites web, mais certains produits et services proposés aux consommateurs. Elle concerne notamment les boutiques en ligne et d’autres offres pour lesquelles les consommateurs peuvent conclure un contrat en ligne. Des exceptions sont prévues pour les très petites entreprises, selon la nature du service et la taille de l’entreprise.

Que votre entreprise soit concernée dépend donc de l’offre et non de la simple existence d’un site. Une entreprise artisanale dont le site présente des prestations et reçoit des demandes n’est pas dans la même situation qu’un prestataire qui conclut des contrats avec des consommateurs en ligne. Cette mise en perspective n’est pas un conseil juridique. Pour des affirmations contraignantes sur votre situation, sur les délais, les obligations et les conséquences, adressez-vous à un conseil juridique qui connaît votre offre.

Indépendamment de l’applicabilité juridique, l’étalon technique est utile. La norme européenne sur laquelle repose la loi s’appuie, pour les contenus web, sur les WCAG. Celui qui aligne son site sur le niveau AA des WCAG 2.x travaille avec un étalon largement reconnu et fait en même temps quelque chose pour tous les visiteurs. Nous séparons délibérément les deux questions : l’appréciation juridique relève d’autres mains, tandis que la qualité technique peut être améliorée indépendamment.

Les outils de contrôle automatique comme Lighthouse ou axe détectent de façon fiable une partie des erreurs : textes alternatifs manquants, contrastes insuffisants, champs de formulaire sans étiquette, ID en double, absence d’indication de langue. Mais ils ne couvrent qu’une partie des problèmes possibles. Qu’un texte alternatif soit pertinent, que l’ordre du focus soit logique ou qu’un message d’erreur soit compréhensible, un script ne peut pas l’apprécier. Un score vert ne signifie donc pas « accessible », mais « aucune erreur détectable automatiquement ».

La deuxième couche est la vérification manuelle, moins lourde qu’il n’y paraît. Mettez la souris de côté et parcourez la page avec Tab, Maj+Tab, Entrée, la barre d’espace et Échap. Le focus saute-t-il de façon logique ? Est-il visible à tout moment ? Chaque menu et chaque boîte de dialogue peuvent-ils être utilisés et quittés ? Agrandissez ensuite l’affichage à 200 pour cent et vérifiez si des contenus sont tronqués ou se chevauchent.

La troisième couche est un échantillon avec un lecteur d’écran, par exemple NVDA sous Windows ou VoiceOver sur Mac et iPhone. L’effort vaut la peine pour quelques parcours clés : la page d’accueil, une page de prestation, le formulaire de contact. Celui qui a entendu une fois sa propre entreprise lue à voix haute comprend autrement la structure des titres et les textes de liens. L’échantillon ne remplace pas un test avec des personnes concernées, mais il révèle de façon fiable les erreurs grossières qu’aucun outil ne signale.

Un exemple de l’interaction entre les couches : un outil signale « l’image a un texte alternatif », et la vérification manuelle constate qu’il s’agit du nom de fichier « IMG_2043 ». Formellement satisfait, pratiquement sans valeur. À l’inverse, l’outil relève un contraste de 3,2 pour 1 sur un texte courant gris que l’œil lit encore bien au bureau. Sur un smartphone en plein air, il devient un obstacle.

Pour le contraste, les WCAG donnent comme valeurs de référence un rapport d’au moins 4,5 pour 1 pour le texte normal et de 3 pour 1 pour le grand texte, ainsi que pour les éléments de commande importants et les graphiques. On peut le vérifier avec des outils de couleur et les outils de développement du navigateur. La correction se situe le plus souvent dans les variables de conception, pas sur la page individuelle : si une valeur de gris est assombrie dans le système de couleurs, tous les endroits s’améliorent en même temps. C’est un argument pour gérer les couleurs de façon centralisée.

Pour le clavier et le focus, une règle simple s’applique : utilisez des éléments natifs chaque fois que possible. Un véritable élément bouton, un véritable lien et un véritable champ de sélection apportent avec eux la navigation au clavier, le rôle et l’état. Les constructions maison faites d’éléments div doivent tout rattraper et échouent souvent. Le contour de focus ne devrait jamais être supprimé sans remplacement. Un contour net et très contrasté coûte peu et rend la page plus facile à utiliser pour tous, y compris pour ceux qui préfèrent simplement taper.

Pour les textes d’images, c’est la fonction qui compte. Les images informatives reçoivent une brève description de ce qu’elles transmettent, les images décoratives un attribut alt vide pour être ignorées. Un logo qui sert de lien vers la page d’accueil a besoin du nom de la destination, pas de la description de l’image. Les textes de liens doivent se comprendre d’eux-mêmes : « Aperçu des prestations » plutôt que « plus ». Dans les formulaires, chaque champ doit avoir une étiquette visible et associée au champ, et les erreurs sont nommées dans le texte, pas seulement marquées en rouge.

Parmi les points les plus délicats figurent les éléments fournis par des tiers. Un bandeau de cookies qui recouvre la page sans gérer le focus peut piéger les utilisateurs du clavier ou les laisser naviguer derrière lui. Il doit être utilisable au clavier, placer le focus de façon pertinente et le restituer à la fermeture. Il en va de même pour les cartes intégrées : une carte interactive est souvent à peine utilisable au clavier, c’est pourquoi l’adresse doit figurer en plus sous forme de texte à côté.

Les vidéos et contenus audio nécessitent des sous-titres ou une transcription pour que les personnes sourdes et malentendantes puissent les utiliser, et une description lorsque l’information est purement visuelle. Les médias qui démarrent automatiquement devraient pouvoir être arrêtés. Les documents PDF tels que listes de prix, formulaires ou brochures constituent un domaine sous-estimé : un scan sans couche de texte est vide pour un lecteur d’écran. Si possible, une page avec du vrai texte est la meilleure forme, le PDF restant un complément.

Autre cas particulier : les animations et le mouvement. Les personnes sensibles au mouvement ont besoin d’un moyen de réduire les effets. Les navigateurs modernes signalent le réglage système « réduire les animations », et la conception peut y réagir en supprimant les effets de parallaxe et les carrousels automatiques. Il en va de même pour les contenus qui changent d’eux-mêmes : un carrousel qui tourne sans pause prive les gens du temps de lire.

Enfin, les widgets de tiers comme la prise de rendez-vous, le chat ou l’affichage des avis. Ils font partie de votre offre, mais ce n’est pas votre code. Il vaut la peine de vérifier avant l’intégration si le fournisseur documente l’accessibilité et, en cas de doute, de proposer une alternative, par exemple un numéro de téléphone ou un formulaire simple. C’est inconfortable, mais plus honnête que de cacher un obstacle derrière un label.

Améliorer l’accessibilité permet d’abord une chose : davantage de personnes peuvent utiliser votre site. Que cela se traduise par plus de demandes ne peut pas être dit de façon générale et dépend du nombre de visiteurs qui ont échoué jusqu’ici. Ce qui est clair, c’est qu’une structure robuste, des contrastes lisibles et des formulaires bien étiquetés aident aussi les visiteurs sans limitation, parce que les pages deviennent plus claires et plus rapides à utiliser. C’est un bénéfice secondaire, mais pas une promesse chiffrable.

Les progrès se mesurent à l’aide d’indicateurs proches du défaut. Il s’agit notamment du nombre d’infractions signalées par les outils de contrôle par type de page, du nombre de parcours clés qui peuvent être menés entièrement au clavier et des résultats de l’échantillon au lecteur d’écran, chaque fois avant et après la refonte. La part d’abandons du formulaire de contact est également révélatrice, à condition qu’il y ait assez de visiteurs pour absorber les fluctuations.

Il faut bien en voir la limite : un audit établit ce qui a été constaté à une date donnée, pas une conformité durable. De nouveaux contenus, une mise à jour ou un plugin peuvent réintroduire des barrières. De même, un audit technique ne permet pas de conclure à l’absence de tout risque juridique. C’est une affirmation que nous ne pouvons pas faire, et nous ne la faisons donc pas. Ce qui est réaliste, c’est un état documenté, avec des points ouverts clairement identifiés et une routine pour le maintenir.

Un critère pratique pour mesurer l’effet : après la refonte, une personne qui ne connaît pas le site devrait pouvoir envoyer le formulaire de contact avec le seul clavier et voir à tout moment où elle se trouve. Si c’est le cas, l’objectif le plus important de cette phase est atteint, même si d’autres points restent ouverts.

L’accessibilité coûte le moins cher quand on y pense dès le départ. Une palette de couleurs aux contrastes vérifiés, des éléments de commande natifs et une structure de titres cohérente ne coûtent presque rien à la construction, mais du temps et des nerfs quand il faut les ajouter après coup. Quiconque crée ou remanie un site web devrait donc intégrer ces critères à la conception plutôt que de les vérifier à la fin. Pour les sites existants, la règle est : les modèles d’abord, les pages individuelles ensuite.

Un deuxième point concerne la rédaction. La technique crée les conditions, mais les textes alternatifs, les intitulés de liens et un langage compréhensible naissent au quotidien. Un court mémo à l’intention de toutes les personnes qui gèrent les contenus apporte souvent plus qu’un nouveau cycle d’audit. Trois règles suffisent pour commencer : décrire les images, expliquer les liens, structurer les titres selon leur sens.

Troisièmement, il est utile d’aborder honnêtement les objectifs contradictoires. Un design très discret en gris clair et des contrastes élevés font mauvais ménage, et un carrousel sur la page d’accueil est rarement ce que cherchent les visiteurs. Ces arbitrages doivent être tranchés de façon visible : là où le design cède, la lisibilité l’emporte, et là où un compromis subsiste, il est documenté afin que la prochaine refonte ne le reproduise pas à son insu.

L’étape suivante est modeste et ne demande aucune connaissance préalable. Ouvrez votre formulaire de contact, posez la souris et essayez d’envoyer une demande avec le seul clavier. Si vous échouez, vous avez un constat concret. Si vous réussissez, vérifiez le contraste de votre texte courant, puis lancez Lighthouse. Si vous souhaitez ensuite un avis, nous examinons votre site et vous disons franchement où se trouve le plus grand levier et ce à quoi on ne peut pas répondre de manière générale.