WCAG et accessibilité web : qui est vraiment concerné en Suisse, et que faire

Pendant des années, l’accessibilité numérique a été, en Suisse, une affaire d’administration. La loi sur l’égalité pour les personnes handicapées fixe des exigences techniques aux autorités qui offrent leurs prestations sur Internet ; les entreprises privées, elles, traitaient WCAG comme une bonne pratique — quelque chose de souhaitable, pas d’obligatoire.

Le 28 juin 2025, quelque chose a bougé, mais pas en Suisse. C’est la date à partir de laquelle l’acte européen sur l’accessibilité s’applique dans l’Union européenne, à un catalogue fermé de produits et de services destinés aux consommateurs. Une entreprise suisse n’y est soumise que dans une situation précise — et c’est cette situation qu’il faut identifier avant de payer qui que ce soit.

L’ampleur du problème, elle, n’a rien de marginal. L’analyse annuelle d’un million de pages d’accueil menée par WebAIM a montré en 2026 que 95,9 % d’entre elles présentent des violations WCAG détectables — davantage qu’un an plus tôt. Le nombre moyen d’erreurs par page est passé de 51 à 56,1. Après des années de lente amélioration, la tendance s’est inversée.

Ce texte répond à trois questions, dans cet ordre : l’obligation vous concerne-t-elle, vous, que faut-il faire concrètement, et quelle part de ce travail un outil gratuit repère-t-il. Nous commençons par la première, parce que la réponse la plus répandue — « tout le monde doit s’y mettre » — est fausse dans les deux sens : trop large pour la plupart des entreprises suisses, trop étroite pour celles qui vendent dans l’Union.

Deux cadres qui ne se recouvrent pas

Une entreprise suisse a affaire à deux ensembles de règles différents, et les mélanger est la source la plus fréquente de malentendus.

Le premier est suisse : la loi fédérale du 13 décembre 2002 sur l’élimination des inégalités frappant les personnes handicapées (LHand, RS 151.3) et son ordonnance (OHand, RS 151.31). Elle vise surtout les autorités, les transports publics et les constructions, et contient pour les particuliers une règle de non-discrimination.

Le second est européen : la directive (UE) 2019/882, connue sous le nom d’European Accessibility Act. Elle ne s’applique pas en Suisse en tant que droit suisse. Elle s’applique à ce qui est fourni sur le marché de l’Union — et c’est par là qu’elle peut atteindre une entreprise établie ici.

Ce que dit le droit suisse

La LHand distingue nettement les autorités des particuliers.

• Les autorités. L’art. 14, al. 2 LHand prévoit que, dans la mesure où les autorités offrent leurs prestations sur Internet, l’accès à ces prestations ne doit pas être rendu difficile aux personnes handicapées de la vue. L’ordonnance précise, à l’art. 10 OHand, que l’information et les prestations proposées sur Internet doivent être accessibles et que les sites doivent être aménagés conformément aux standards internationaux, notamment aux directives du W3C — c’est-à-dire WCAG. La même disposition vise aussi les organisations et entreprises titulaires d’une concession fédérale, pour leur domaine d’activité.
• La norme de référence. Pour l’administration fédérale, c’est la norme eCH-0059, dont la troisième version exige le niveau de conformité AA des WCAG 2.1.
• Les particuliers. L’art. 6 LHand pose une règle plus générale et moins technique : les particuliers qui fournissent des prestations au public ne doivent pas traiter une personne handicapée de façon discriminatoire du fait de son handicap. En cas de discrimination, la loi prévoit une indemnité, plafonnée à 5 000 CHF par l’art. 11, al. 2. Rien, dans le texte que nous avons lu, n’impose à une entreprise privée un niveau WCAG déterminé.
• Les cantons. L’art. 4 LHand leur permet d’aller plus loin. Si votre entreprise travaille pour une collectivité cantonale ou communale, c’est le droit de ce canton qu’il faut regarder.

Deux précisions honnêtes. Nous citons la version consolidée de la LHand en vigueur au 1er juillet 2020, la plus récente que publie le recueil fédéral au moment où nous écrivons. Un projet de révision partielle de la loi a été mis en consultation en 2023 ; vérifiez où il en est au moment où vous lisez, parce que c’est précisément la place des prestataires privés qui y est discutée.

Ce que dit la directive européenne, et quand elle vous atteint

La directive s’applique, selon son art. 2, aux services fournis aux consommateurs après le 28 juin 2025. Son art. 3 définit le prestataire de services comme toute personne qui fournit un service sur le marché de l’Union ou propose de fournir un service aux consommateurs dans l’Union. Le lieu où votre société est inscrite au registre du commerce n’est donc pas le critère ; le critère, c’est à qui vous vendez et quoi.

Côté sanctions, la directive ne fixe aucun montant : l’art. 30 laisse chaque État membre déterminer un régime « effectif, proportionné et dissuasif ». Les chiffres qui circulent sur les amendes sont donc ceux d’un pays donné, et ne se transposent pas d’un pays à l’autre. Comment un État membre fait appliquer ces règles à un prestataire établi hors de l’Union, c’est une question pour un juriste du pays où vous vendez — pas pour nous.

Les dates à retenir

La dernière ligne compte pour qui a signé avant l’été 2025 : un contrat de services conclu avant le 28 juin 2025 peut courir sans modification jusqu’à son terme, mais pas plus de cinq ans après cette date. Ce n’est pas un délai de grâce pour les nouveaux sites.

L’obligation européenne vous concerne-t-elle ?

La directive couvre un catalogue fermé de produits et de services destinés aux consommateurs. Pas « les entreprises » en général.

Dans le catalogue des services, on trouve notamment :

• le commerce électronique — boutiques en ligne, places de marché, systèmes de réservation, c’est-à-dire tout service fourni à distance en vue de conclure un contrat de consommation
• les services bancaires aux consommateurs
• certains éléments des services de transport de voyageurs — sites internet, applications mobiles, billetterie électronique, informations de voyage
• les services de communications électroniques
• les livres numériques et les logiciels spécialisés

S’y ajoute un catalogue de produits : ordinateurs grand public et systèmes d’exploitation, terminaux de paiement et bornes en libre-service, téléphones, liseuses numériques.

La distinction entre produit et service n’est pas une formalité. La directive impose d’autres obligations au fabricant, à l’importateur et au distributeur d’un produit, et d’autres au prestataire d’un service. Une entreprise qui vend en ligne son propre appareil à des consommateurs de l’Union peut être concernée des deux côtés à la fois : comme boutique, et comme opérateur qui met un produit sur le marché.

L’exception pour les microentreprises, et son piège

Les microentreprises qui fournissent des services sont exemptées. La directive les définit comme les entreprises qui emploient moins de dix personnes ET dont le chiffre d’affaires annuel ou le total du bilan n’excède pas 2 millions d’euros. Les deux conditions — effectif et seuil financier — doivent être remplies ensemble.

Mais l’exemption a une limite facile à manquer : elle vaut pour la fourniture de services, pas pour la mise de produits sur le marché. Une microentreprise qui tient une boutique en ligne est exemptée en tant que prestataire. Une microentreprise qui fabrique ou importe un terminal ou une liseuse bénéficie seulement d’obligations allégées — pas d’une exemption.

Le tableau à envoyer à la direction

La ligne B2B et les deux lignes « non » sont les plus importantes de ce texte, parce qu’elles disent ce que le secteur n’aime pas dire : beaucoup de lecteurs n’ont aucune obligation technique. Un fabricant de machines qui vend exclusivement à d’autres entreprises n’entre pas dans l’acte européen. Il peut vouloir un site accessible pour d’autres raisons — nous y venons — mais il n’y est pas tenu.

WCAG, c’est-à-dire comment l’accessibilité se mesure

La directive ne décrit pas à quoi doit ressembler un site accessible. En pratique, la conformité se démontre par la norme européenne EN 301 549, dont le volet web reprend les critères WCAG de niveau AA. Côté suisse, eCH-0059 renvoie au même référentiel. Autrement dit, les deux cadres juridiques diffèrent, mais l’instrument de mesure est le même.

WCAG repose sur quatre principes, connus sous l’acronyme POUR :

• Perceptible — l’information se reçoit quel que soit le sens utilisé. La photo d’un produit a une description, la vidéo a des sous-titres, et le prix barré a un contraste suffisant pour être lu par une vue faible. Test pratique : désactivez les images et vérifiez que la page dit toujours ce qu’elle devait dire.
• Utilisable — l’interface se commande sans souris, sans limite de temps et sans piège. Test pratique : parcourez le processus d’achat avec la seule touche Tab, de la fiche produit jusqu’à la confirmation de commande.
• Compréhensible — le contenu et le comportement de la page sont prévisibles. Un champ a une étiquette qui ne disparaît pas, un message d’erreur dit quoi corriger, et le menu se présente de la même façon sur chaque page.
• Robuste — le code est suffisamment correct pour que les technologies d’assistance s’en sortent. C’est le seul des quatre principes qu’un outil automatique vérifie bien — et c’est pour cela que la plupart des équipes le maîtrisent.

Il existe trois niveaux de conformité : A, AA et AAA. La référence juridique est AA — le niveau A est un minimum que personne ne juge suffisant à lui seul, et AAA est parfois impossible à atteindre pour un site entier.

WCAG 2.1 ou 2.2 ?

La référence juridique, en Suisse comme dans la norme européenne actuelle, est WCAG 2.1 AA. Mais depuis 2023, la recommandation en vigueur du W3C est WCAG 2.2, qui ajoute neuf critères de succès — dont six de niveau A ou AA, les seuls qui comptent en pratique (les trois autres sont AAA) :

Il y a aussi un changement dont presque personne ne parle : le critère 4.1.1 Parsing a été supprimé dans la version 2.2. Les attributs id en double ne sont plus une violation. Si vous recevez un rapport qui les compte encore comme des erreurs, ce rapport est plus ancien que la norme.

Pour un nouveau site, nous viserions directement 2.2 : l’effort supplémentaire est faible, et c’est cette version qui servira de référence dans quelques années.

Six erreurs qui font presque tout

Le plus intéressant dans les données de WebAIM n’est pas que 95,9 % des pages aient des erreurs. C’est que six types de violations représentent 96 % de toutes les erreurs détectées.

C’est une bonne nouvelle habillée d’une mauvaise statistique. La réparation n’est pas un puits sans fond — six chantiers règlent presque tout ce que les outils savent détecter. Un deuxième résultat de la même étude le confirme : 20,5 % des pages ont cinq erreurs ou moins, et 30,4 % n’en ont pas plus de dix.

Trois familles d’obstacles

Visuels. Sans texte alternatif, la photo d’un produit devient « image », et c’est tout ce qu’entendra la personne qui utilise un lecteur d’écran. Un contraste trop faible exclut non seulement les personnes malvoyantes, mais quiconque regarde son écran en plein soleil. Une catégorie à part : l’information transmise uniquement par la couleur — un cadre rouge autour d’un champ ne dit rien à la personne qui ne distingue pas cette couleur.

De navigation. Un site qu’on ne peut pas parcourir au clavier est entièrement fermé à une partie des utilisateurs. Un piège de focus — une fenêtre modale dont on ne peut pas sortir avec la touche Tab — peut bloquer une session pour de bon. S’y ajoute la structure des titres : si H1, H2 et H3 sont choisis pour leur apparence et non pour la hiérarchie, le lecteur d’écran perd la carte de la page, parce que les titres lui servent de table des matières.

Multimédias. Une vidéo sans sous-titres exclut les personnes sourdes, mais aussi tous ceux qui regardent sans le son — c’est-à-dire l’essentiel du trafic mobile. L’audiodescription est plus difficile et moins souvent exigée, mais un contenu dont l’information clé n’apparaît qu’à l’image ne fonctionne pas sans elle.

À quoi cela ressemble dans une boutique en ligne

Quatre endroits où le commerce en ligne trébuche le plus souvent :

• Un champ décrit uniquement par un texte indicatif. <input placeholder="E-mail"> sans étiquette a l’air propre et disparaît dès que l’utilisateur commence à taper. Correct : <label for="email">E-mail</label> à côté du champ.
• Un bouton sans contenu. Une icône de corbeille dans un <button> sans texte et sans aria-label est, pour un lecteur d’écran, « bouton ». Impossible de savoir s’il supprime le produit ou ouvre le panier.
• Un focus sans contour. outline: none dans la feuille de style, sans remplacement, fait qu’une personne qui navigue au clavier ne sait plus où elle se trouve.
• Un message d’erreur par la seule couleur. Un cadre rouge autour d’un champ n’est pas un message. Il faut, à côté, une phrase qui dit exactement ce qui ne va pas.

Le cinquième endroit, c’est le contraste, en tête du tableau avec 83,9 % — le plus souvent sur le texte d’aide gris, les prix promotionnels et les étiquettes sous les champs.

Ce qu’un outil gratuit repère

C’est ici que commence la partie dont les textes qui vendent des audits ne parlent pas.

Nous avons passé Lighthouse 13.4.1 — l’outil intégré à Chrome, fondé sur le moteur axe-core — sur notre propre site. Une page a obtenu 100 sur 100, le blog 96.

Le score fait plaisir, mais il ne veut pas dire ce qu’on croit. La catégorie accessibilité de Lighthouse compte 76 contrôles. Sur notre page, 24 ont été réussis, 42 marqués « non applicables », et 10 marqués `manual` — c’est-à-dire des contrôles que Lighthouse n’effectue pas lui-même et laisse à un humain.

Parmi eux, sur notre page :

• les éléments interactifs sont-ils atteignables au clavier
• l’ordre de tabulation est-il logique
• l’ordre visuel correspond-il à l’ordre dans le code
• le focus évite-t-il les pièges
• le focus passe-t-il au contenu qui vient d’apparaître
• les contrôles personnalisés ont-ils des étiquettes et des rôles
• le contenu hors écran est-il masqué aux technologies d’assistance

Cent sur cent dans Lighthouse ne veut pas dire « conforme à WCAG ». Cela veut dire « la partie automatisable est passée ». L’outil calcule très bien le contraste et les alt manquants. Il ne vous dira pas si l’on peut acheter un produit sans souris.

Quatre pièges qui vous feront réparer ce qui fonctionne

Lors du même audit sur notre propre site, sur quatre constats manuels, trois se sont révélés de fausses alertes une fois vérifiés dans la documentation. Nous les listons, parce que quiconque fait un audit par ses propres moyens tombera dans les mêmes :

• `<label for>` fonctionne sur un `<button>`. Le bouton est un élément étiquetable ; un composant avec role="checkbox" peut donc être correctement décrit sans avoir d’aria-label.
• Un élément avec `aria-hidden="true"` et `tabindex="-1"` est masqué exprès. Le champ caché sous un composant d’une bibliothèque d’interface n’est pas un champ sans étiquette.
• Le `placeholder` compte comme nom accessible. L’outil l’accepte et ne signale pas d’erreur — c’est pourtant une mauvaise pratique, puisque le nom disparaît au premier caractère saisi.
• Le critère 2.4.1 est satisfait par des repères de régions ou par des titres. Un lien « aller au contenu » est recommandé pour les personnes au clavier, mais il n’est pas exigé si la page a une structure correcte.

La mise en œuvre, étape par étape

Étape 1 — l’audit. Un outil puis un humain, dans cet ordre. Gratuitement : Lighthouse dans Chrome, l’extension axe DevTools, WAVE. Ensuite, le test au clavier — la seule touche Tab sur tout le processus d’achat — et un lecteur d’écran : NVDA sous Windows, VoiceOver sous macOS, TalkBack sous Android. Un audit commercial va du survol rapide à l’audit technique d’un site, jusqu’à l’audit d’expérience avec des tests auprès d’utilisateurs ; les écarts de prix entre ces trois formats sont d’un ordre de grandeur, et nous n’avons pas de relevé de prix du marché suisse à vous donner. Demandez toujours lequel des trois on vous propose.

Le test au clavier paraît banal et c’est la partie la plus révélatrice de tout l’audit. Posez la souris et parcourez au Tab le chemin de la page d’accueil jusqu’à la confirmation de commande. Notez trois choses : où l’on ne voit pas sur quoi se trouve le focus ; où Tab saute ailleurs que prévu ; et où vous êtes resté bloqué. Un quart d’heure de ce parcours donne généralement plus de concret que tout un rapport automatique.

Étape 2 — la correction. L’ordre découle du tableau de WebAIM : contraste, textes alternatifs, étiquettes de champs, noms des liens et des boutons, déclaration de la langue. Ce sont des modifications du HTML, des attributs ARIA et des styles — dans la plupart des cas des jours de travail, pas des mois.

Étape 3 — la documentation. L’administration fédérale publie une déclaration d’accessibilité. Un prestataire soumis à l’acte européen doit, selon l’art. 13 de la directive, établir des informations sur la manière dont son service satisfait aux exigences d’accessibilité et les rendre publiques, y compris sous une forme accessible. Dans les deux cas, ce n’est pas une formalité à cocher : c’est le document par lequel un contrôle commence.

Étape 4 — l’entretien. L’accessibilité se dégrade à chaque modification de contenu, et c’est la partie qu’on oublie le plus souvent. Le rédacteur qui insère une photo sans description défait le travail du développeur. La personne qui ajoute une bannière avec un texte incrusté dans l’image fait disparaître ce texte pour le lecteur d’écran. Un nouveau composant arrive dans la boutique sans étiquettes, parce que personne ne les a exigées dans la tâche.

Trois choses empêchent cette dérive : une courte formation de l’équipe éditoriale aux textes alternatifs et à la structure des titres, une ligne « accessibilité » dans la liste de contrôle avant chaque mise en ligne, et une vérification automatique dans le processus de construction du site, pour que les erreurs évidentes n’atteignent pas la production. Aucune n’est coûteuse. Toutes le sont moins qu’un deuxième audit dans un an.

Ce qu’on peut faire la première semaine

Si vous n’avez pas encore de budget pour l’ensemble, voici l’ordre :

• vérifiez le contraste du texte d’aide, des prix et des étiquettes — c’est statistiquement l’erreur la plus fréquente et la moins chère à corriger
• ajoutez des descriptions alternatives aux photos qui portent une information ; laissez les images décoratives avec un alt vide
• parcourez au Tab le formulaire de contact et le panier, et rétablissez un contour de focus visible s’il a été supprimé dans les styles
• vérifiez que la balise <html> porte un attribut lang — et, sur un site en plusieurs langues, que chaque version déclare la sienne

Ce sont quatre des six lignes du tableau de WebAIM. Elles ne donnent pas la conformité, mais elles retirent l’essentiel de ce que les outils et les utilisateurs verront en premier.

La référence publique en Suisse est le Bureau fédéral de l’égalité pour les personnes handicapées (BFEH), qui publie les informations sur l’accessibilité dans l’administration fédérale, et la norme eCH-0059 pour le détail technique.

À quoi cela sert, quand l’obligation ne vous concerne pas

Si le tableau ci-dessus vous a placé du côté « en principe non », il reste trois raisons de s’en occuper malgré tout.

Le marché. Selon l’enquête SILC 2023 de l’Office fédéral de la statistique, 1,8 million de personnes de 16 ans et plus vivant à domicile en Suisse ont un handicap au sens de la loi sur l’égalité — un problème de santé durable qui les limite dans les activités de la vie courante. Parmi elles, 340 000 font état de limitations fortes. Et ce chiffre n’inclut ni les enfants ni les personnes vivant en institution. Ce n’est pas une niche.

Le confort de tous. Les limitations sont parfois temporaires ou situationnelles. Un écran en plein soleil, c’est un problème de contraste. Le bruit dans un train, c’est un besoin de sous-titres. Une seule main libre, c’est une navigation au clavier. Les solutions conçues pour les personnes handicapées servent aussi dans toutes ces situations.

Le référencement. Une structure de titres correcte, des textes alternatifs sensés, des liens descriptifs et la déclaration de la langue sont à la fois des exigences WCAG et des signaux sur lesquels repose l’indexation. Sur un site en plusieurs langues, la déclaration de langue par version compte doublement. Il n’y a là aucune magie : l’accessibilité impose une sémantique, et la sémantique aide le moteur de recherche.

Et ensuite

Si vous voulez savoir où vous en êtes et que vous prévoyez des changements dans les prochains mois, parlons-en : nous regardons ensemble si l’obligation vous concerne, puis ce qu’il faudrait corriger en priorité — et si la réponse est « rien pour l’instant », nous vous le disons.

Si vous préférez d’abord vérifier vous-même, deux outils sans inscription : la liste de contrôle pour un auto-audit et le test de vitesse de site web, qui affiche les Core Web Vitals de votre adresse.

Si vous n’en êtes qu’à planifier votre site, c’est au stade du projet que l’accessibilité coûte le moins — nous décrivons ce stade dans le texte sur la création d’un site internet. Ce que l’expérience utilisateur et l’interface changent au quotidien est traité dans notre texte sur l’UX et l’UI, et les outils de test dans le guide du test de site web.