Accessibilité clavier et ARIA : l'obligation légale qui devient avantage commercial

Depuis juin 2025, l'European Accessibility Act impose l'accessibilité numérique à la plupart des services en ligne. Le test #35 détecte les problèmes de navigation clavier qui mettent les sites en danger.

L'accessibilité clavier fait partie de ces sujets que la plupart des professionnels du web reconnaissent comme importants — puis ignorent aussitôt. Le raisonnement est toujours le même : « nos utilisateurs utilisent une souris. » Mais cette hypothèse est fausse, et depuis juin 2025, elle est aussi illégale pour un nombre croissant d'entreprises dans l'Union européenne.

L'European Accessibility Act (EAA, Directive 2019/882) exige que les produits et services vendus aux consommateurs — y compris les sites web et applications mobiles — soient accessibles aux personnes handicapées. La navigation clavier est l'un des piliers fondamentaux de l'accessibilité web. Si un utilisateur ne peut pas tabuler dans l'interface, activer des boutons ou naviguer dans les menus sans souris, le site échoue au critère d'accessibilité le plus basique.

Le test #35 d'Orilyt analyse les signaux HTML statiques pour détecter les problèmes d'accessibilité clavier les plus courants : valeurs tabindex négatives qui retirent des éléments de l'ordre de tabulation, styles de focus désactivés en CSS, skip links manquants et attributs ARIA en conflit avec des éléments focalisables. Ce n'est pas un audit WCAG complet — mais il détecte les problèmes qui comptent le plus.

Test #35 : que vérifie Orilyt ?

Le test #35 effectue une analyse statique du HTML et du CSS inline de la page pour détecter les signaux d'accessibilité clavier. Il vérifie six indicateurs spécifiques :

1. Tabindex négatif — les éléments avec tabindex="-1" sont retirés de l'ordre naturel de tabulation. C'est parfois intentionnel (modales, éléments hors écran), mais l'abus crée des barrières invisibles. Toute occurrence abaisse le score à 60
2. Tabindex positif — des valeurs comme tabindex="5" forcent un ordre de tabulation personnalisé qui casse presque toujours le flux de lecture logique. Le test signale ces cas comme un avertissement
3. Outline de focus désactivé — si le CSS contient outline: none sans règle :focus ou :focus-visible correspondante fournissant un style alternatif, les utilisateurs clavier ne peuvent pas voir où ils se trouvent sur la page. Le score chute à 60
4. Détection du skip link — un lien « Aller au contenu » (ciblant #main, #content ou des ancres similaires) permet aux utilisateurs clavier de contourner la navigation. Sa présence est un signal positif qui augmente la confiance
5. Conflits ARIA-hidden — les éléments marqués aria-hidden="true" contenant des enfants focalisables (liens, boutons, champs) créent un piège dangereux : les lecteurs d'écran masquent l'élément, mais le focus clavier peut toujours s'y poser
6. Présence de CSS focus — le test vérifie si la page inclut des règles CSS :focus ou :focus-visible, indiquant que le développeur a pensé au style de la navigation clavier

Une page sans problème évident obtient 80. Le test ne peut pas dépasser 80 car l'analyse HTML statique seule ne peut pas valider complètement la navigation clavier — un test de tabulation réel reste nécessaire. Si des problèmes sont trouvés, le score descend à 60 ou 55 selon la gravité.

L'European Accessibility Act : ce qui a changé en juin 2025

L'EAA a été adopté en 2019 mais les États membres avaient jusqu'au 28 juin 2025 pour le transposer en droit national. Depuis cette date, les entreprises fournissant des services aux consommateurs dans l'UE doivent se conformer à des exigences d'accessibilité alignées sur le WCAG 2.1 Niveau AA.

Le périmètre est large : sites e-commerce, services bancaires, billetterie de transport, livres numériques, et tout service numérique vendu aux consommateurs. Les micro-entreprises (moins de 10 employés et moins de 2 millions d'euros de chiffre d'affaires) sont exemptées, mais le seuil est bas — la plupart des clients d'agences sont concernés.

Les sanctions varient selon les États membres mais incluent amendes, injonctions et actions correctives obligatoires. Plus important encore, la réglementation crée un marché de la conformité : les entreprises ont besoin d'audits, de plans de remédiation et de suivi continu — des services que les agences peuvent vendre.

La navigation clavier n'est pas le seul critère WCAG, mais c'est celui qui échoue le plus spectaculairement. Un utilisateur qui ne peut pas tabuler au-delà de la navigation, ou qui se retrouve piégé dans une modale sans gestion de la touche Échap, subit une panne totale de l'interface. C'est la première chose que les auditeurs vérifient.

Les 5 erreurs d'accessibilité clavier les plus courantes

En pratique, la plupart des problèmes d'accessibilité clavier se répartissent en cinq catégories. Chacune est détectable et corrigeable :

1. Composants personnalisés sans support clavier — menus déroulants, accordéons, carrousels et modales construits avec <div> et JavaScript mais sans gestionnaires d'événements clavier. Ils fonctionnent au clic souris mais sont totalement invisibles à la navigation Tab. Correction : utiliser du HTML sémantique (<button>, <details>) ou ajouter des gestionnaires keydown et des rôles ARIA appropriés
2. Indicateurs de focus manquants — des resets CSS ou des design systems qui incluent outline: none globalement sans fournir un style alternatif :focus-visible. Les utilisateurs clavier ne voient littéralement pas où ils sont. Correction : définir un anneau de focus visible dans le CSS — un outline solid de 2px dans une couleur contrastée suffit pour la plupart des designs
3. Pièges de tabulation — des modales ou widgets embarqués qui capturent le focus sans offrir de moyen de s'échapper au clavier. L'utilisateur est bloqué. Correction : implémenter un piégeage de focus qui cycle dans la modale et libère le focus sur Échap
4. Ordre de tabulation incorrect — des valeurs tabindex positives (tabindex="1", tabindex="99") qui écrasent l'ordre naturel du DOM. La séquence de tabulation devient imprévisible. Correction : supprimer toutes les valeurs tabindex positives et s'appuyer sur l'ordre du DOM
5. Skip links manquants — sur les pages avec une navigation complexe, les utilisateurs clavier doivent tabuler à travers tous les liens de l'en-tête avant d'atteindre le contenu principal. Un lien « Aller au contenu » en haut de page résout ce problème en une ligne de HTML

Comment corriger les problèmes d'accessibilité clavier

La bonne nouvelle : la plupart des corrections d'accessibilité clavier sont simples et ne nécessitent pas de refonte. Elles se répartissent en trois catégories :

1. Utiliser du HTML sémantique — remplacer <div onclick="..."> par <button>, utiliser <a> pour la navigation, utiliser <details>/<summary> pour les sections dépliables. Les éléments sémantiques sont accessibles au clavier par défaut
2. Ajouter des styles de focus — définir une règle :focus-visible dans le CSS. Un simple outline: 2px solid #2563EB avec un offset assure la visibilité sans affecter les utilisateurs souris. Ne jamais utiliser outline: none sans alternative
3. Tester avec la touche Tab — le test d'accessibilité le plus efficace ne coûte rien : débranchez la souris et naviguez sur votre site avec Tab, Maj+Tab, Entrée et Échap. Si vous êtes bloqué, vos utilisateurs le seront aussi

Pour les sites WordPress en particulier, le coupable le plus fréquent est le thème. Les thèmes premium privilégient souvent le design visuel au détriment de l'accessibilité. Vérifiez les menus de navigation du thème, les formulaires de contact et tous les composants animés par JavaScript (sliders, lightboxes, méga-menus).

L'accessibilité comme opportunité commerciale pour les agences

Pour les freelances et agences, l'EAA a créé un marché de la conformité qui n'existait pas avant juin 2025. L'argumentaire commercial est convaincant :

1. Obligation légale = demande garantie — chaque client avec un site e-commerce ou un service grand public dans l'UE a besoin d'un audit d'accessibilité. Ce n'est pas optionnel. C'est la loi
2. Revenus récurrents — l'accessibilité n'est pas une correction ponctuelle. Les sites évoluent, de nouvelles pages sont publiées, les plugins sont mis à jour. Un suivi continu et des ré-audits périodiques sont nécessaires pour maintenir la conformité
3. Faible concurrence — la plupart des agences web ne proposent pas encore de services d'accessibilité. Être en avance crée un avantage de positionnement. Les agences qui bougent maintenant domineront ce segment

Dans le rapport Orilyt, le test #35 génère une recommandation FIA claire lorsque des problèmes sont trouvés. Un score de 55 ou 60 en accessibilité clavier est un démarreur de conversation avec n'importe quel client. La recommandation explique ce qui a été trouvé (ex : « Outline de focus désactivé sans alternative »), où cela se produit et quoi faire.

De la contrainte légale à l'avantage concurrentiel

L'accessibilité clavier n'est pas un sujet de niche. Elle concerne les utilisateurs à mobilité réduite, les power users clavier, les utilisateurs de lecteurs d'écran, et quiconque a un trackpad cassé un mardi après-midi. L'EAA en a fait une obligation légale pour des millions d'entreprises européennes.

Le test #35 ne remplace pas un audit WCAG complet — mais il détecte les signaux qui indiquent si l'accessibilité clavier a été prise en compte. Des styles de focus manquants, un abus de tabindex négatif et des conflits ARIA-hidden sont les signaux d'alerte qui prédisent des problèmes plus profonds.

Pour les agences, c'est une opportunité de marché avec un argument de vente intégré : « Votre site est légalement tenu d'être accessible. Voici ce que notre audit a trouvé. Voici comment nous le corrigeons. » La loi a fait la vente pour vous.