L’accessibilité web sert à rendre un site utilisable pour un maximum de personnes (navigation clavier, lecteurs d’écran, contrastes, tailles de cibles tactiles). Sur WordPress, cela améliore souvent aussi la conversion : un formulaire plus clair, un checkout plus simple, moins d’abandons. En Suisse romande, ces optimisations sont pertinentes autant à Lausanne et Nyon (Vaud) qu’à Genève et Carouge (Genève), Fribourg et Bulle (Fribourg), Sion et Martigny (Valais), Neuchâtel et La Chaux-de-Fonds (Neuchâtel), Delémont et Porrentruy (Jura).
Sources officielles : W3C (WCAG 2.2) | W3C WAI (nouveautés WCAG 2.2) | Confédération – BIT (eCH-0059 et accessibilité) | eCH (eCH-0059 v3.0 PDF) | WordPress (Block Editor accessibility) | Google Chrome (Lighthouse) | W3C WAI (Easy Checks) | EUR-Lex (Directive UE 2019/882)
1) Les référentiels à connaître : WCAG, puis le cadre suisse
WCAG 2.2 est une recommandation du W3C qui couvre un large ensemble de critères d’accessibilité. W3C publie aussi une synthèse des ajouts de WCAG 2.2 (nouveaux critères, et retrait de l’ancien critère « Parsing »).
En Suisse, la Confédération indique que, pour l’administration fédérale, la norme eCH-0059 (version 3) exige une conformité aux critères WCAG 2.1 au niveau AA. Le PDF eCH-0059 détaille le périmètre et la logique de la norme.
Si votre entreprise vend aussi à des clients dans l’Union européenne, la Directive (UE) 2019/882 (European Accessibility Act) est une référence officielle à consulter pour comprendre les obligations applicables à certains produits et services sur le marché UE.
2) WordPress : les points qui font la différence
Sur WordPress, l’accessibilité dépend de trois couches : le thème (structure HTML), l’éditeur (blocs), et vos contenus (titres, liens, images, formulaires). La documentation WordPress sur l’accessibilité du Block Editor insiste notamment sur l’usage de « landmarks » et de structures de page qui aident la navigation au lecteur d’écran.
- Hiérarchie des titres : un H1 par page, puis H2/H3 cohérents (éviter les sauts).
- Liens : libellés explicites (éviter « cliquez ici » seul), surtout dans les pages services locales.
- Images : texte alternatif utile (ou vide si pure déco), sans bourrage de mots-clés.
- Composants : menus, accordéons, popups, doivent être utilisables au clavier et annoncés correctement.
3) WooCommerce : attention au checkout et aux messages d’erreur
Une boutique peut perdre des ventes pour des raisons très simples : focus clavier qui se perd, champ obligatoire mal annoncé, erreur affichée sans lien vers le champ, bouton trop petit sur mobile. L’accessibilité, ici, rejoint directement le CRO.
- Formulaires : label associé à chaque champ, aide contextuelle courte, messages d’erreur compréhensibles.
- Clavier : parcours complet possible sans souris (panier, codes promo, paiement si applicable).
- États : chargements et confirmations visibles et annoncés (ne pas dépendre uniquement d’une couleur).
4) Audit rapide (30 minutes) : un bon début, sans se raconter d’histoires
W3C propose des « Easy Checks » pour un premier contrôle rapide. Ces vérifications ne remplacent pas un audit complet, mais elles détectent souvent des blocages majeurs (clavier, titres, formulaires, médias).
Test clavier (manuel)
- Tab : accéder au menu, aux boutons, aux champs, dans un ordre logique.
- Entrée/Espace : activer les boutons et éléments interactifs.
- Focus visible : toujours savoir où l’on se trouve (sans deviner).
Scan automatique (indicatif) avec Lighthouse
Lighthouse (dans Chrome DevTools) inclut des audits d’accessibilité. Cela aide à repérer des erreurs courantes, mais le résultat doit être complété par des tests manuels (clavier, lecteurs d’écran).
5) Plan d’action simple (priorités)
- Priorité 1 : navigation clavier, focus visible, formulaires et checkout.
- Priorité 2 : contrastes, tailles de cibles tactiles, cohérence des composants (menus, modales).
- Priorité 3 : contenu long (titres, sommaires), médias (sous-titres, transcriptions si pertinent).
- Validation : refaire un cycle « Easy Checks » et un test clavier sur les pages clés (Accueil, Services, Contact, Panier, Checkout).
FAQ Accessibilité WordPress (Suisse romande)
WCAG 2.2 remplace-t-il WCAG 2.1 ?
WCAG 2.2 ajoute des critères par rapport à WCAG 2.1, et W3C publie les détails des nouveautés. Pour un projet, viser WCAG 2.1 AA reste fréquent, notamment quand un cadre local le mentionne explicitement, tout en s’inspirant des apports de WCAG 2.2.
Quel est le cadre officiel en Suisse pour l’accessibilité web ?
Pour l’administration fédérale, la Confédération indique que la norme eCH-0059 v3 requiert la conformité WCAG 2.1 niveau AA. Le document eCH-0059 décrit le périmètre et l’intention.
Mon entreprise est en Suisse, mais vend aussi dans l’UE : dois-je m’en préoccuper ?
Si vous proposez des produits ou services concernés sur le marché UE, la Directive (UE) 2019/882 est la référence officielle à examiner (puis vérifier la transposition et l’application dans les pays ciblés).
Par où commencer si le budget est limité ?
Commencez par les pages qui génèrent des demandes ou des ventes : Services, Contact, Panier, Checkout. Appliquez les « Easy Checks » W3C, faites un test clavier, puis utilisez Lighthouse pour un premier balayage automatique.
Besoin d’un site WordPress plus accessible, sans dégrader le design ni le checkout ?
Pour prioriser les correctifs, sécuriser la structure (thème, blocs, formulaires) et améliorer l’expérience sur mobile et clavier, contactez clickclick.ch.
Note : cet article est une synthèse technique et ne remplace pas un avis juridique. Pour des obligations légales applicables à votre activité, référez-vous aux textes officiels et, si nécessaire, à un conseil spécialisé.
