Accessibilité web en Suisse : exigences, WCAG et plan d’action

Un visiteur doit pouvoir lire vos informations, choisir une prestation et envoyer une demande avec les moyens qu’il utilise : clavier, lecteur d’écran, zoom ou commande vocale. L’accessibilité web consiste à repérer les obstacles qui l’en empêchent, puis à corriger le contenu, les interfaces et le code.

Pour une organisation suisse, commencez par deux décisions : identifier les exigences qui concernent votre activité et choisir les parcours à tester. Les WCAG fournissent un référentiel technique. Le cadre juridique dépend de votre statut, du service proposé et des marchés concernés.

Quelles exigences concernent votre organisation ?

Administration fédérale

Point de départ — Le BFEH présente eCH-0059 version 3 et les WCAG 2.1 au niveau AA comme référence pour l’accessibilité numérique fédérale.

Action à prévoir — Inscrire les exigences applicables dans le cahier des charges et prévoir une évaluation documentée.

Canton, commune ou organisme chargé d’une mission publique

Point de départ — Vérifier le cadre cantonal, sectoriel et contractuel applicable.

Action à prévoir — Demander au responsable juridique ou au donneur d’ordre le référentiel, le périmètre et les justificatifs attendus.

Entreprise privée proposant des prestations au public en Suisse

Point de départ — L’article 6 de la LHand interdit la discrimination liée au handicap. Il n’instaure pas à lui seul une certification WCAG AA obligatoire pour chaque site privé.

Action à prévoir — Examiner les obstacles à l’accès à vos prestations et définir une cible technique adaptée.

Entreprise proposant un service couvert à des consommateurs dans l’UE

Point de départ — Examiner l’European Accessibility Act et sa transposition dans les pays concernés.

Action à prévoir — Vérifier la catégorie de service, les exemptions et les exigences nationales avant de fixer le périmètre.

Sources : BFEH, accessibilité au sein de l’administration fédérale, LHand sur Fedlex et directive européenne 2019/882.

Le cas d’un service vendu dans l’Union européenne

Depuis le 28 juin 2025, les dispositions nationales prises en application de l’EAA concernent notamment les services de commerce électronique destinés aux consommateurs. Certains services bancaires, de transport et de communication entrent aussi dans son champ. La présence de visiteurs européens sur un site suisse ne suffit pas à décrire votre situation juridique : examinez ce que vous vendez, à qui et dans quel pays.

La directive exempte les microentreprises qui fournissent des services. Elle définit une microentreprise comme une entreprise employant moins de dix personnes et dont le chiffre d’affaires annuel ou le total du bilan annuel n’excède pas deux millions d’euros. Les règles concernant les produits diffèrent. Vérifiez votre situation et les dispositions nationales avec un professionnel compétent. EAA, articles 2, 3, 4 et 31.

Choisir une cible WCAG explicite

Les Web Content Accessibility Guidelines décrivent des critères testables. Le W3C organise ces critères selon quatre principes : rendre les informations perceptibles, permettre l’utilisation de l’interface, faciliter sa compréhension et assurer sa compatibilité avec les technologies d’assistance.

Pour un nouveau projet, vous pouvez fixer WCAG 2.2 niveau AA comme cible technique, sous réserve des exigences applicables. Notez la version et le niveau dans le contrat : « accessible » sans périmètre ne permet pas de vérifier la livraison. Le W3C recommande l’utilisation de WCAG 2.2 pour les nouveaux travaux, tout en maintenant les versions précédentes. Le niveau AA comprend les critères des niveaux A et AA. WCAG 2.2, W3C.

WCAG 3.0 reste un document de travail. Ne le présentez pas comme une norme de conformité déjà adoptée pour votre site. Statut de WCAG 3.0.

Auditer des parcours complets

Commencez par les tâches qui donnent accès à votre prestation : trouver une information, sélectionner une offre, réserver, payer ou contacter votre équipe. Un contrôle de la page d’accueil ne décrit pas les difficultés d’un formulaire ouvert dans une fenêtre ou d’un paiement confié à un prestataire.

Préparez un échantillon comprenant les modèles de page, les composants réutilisés, les états d’erreur et les étapes connectées. Incluez les versions FR et EN. Ajoutez les documents nécessaires à la démarche, tels qu’un tarif PDF ou un formulaire à télécharger.

Combiner les méthodes

Un outil automatisé aide votre équipe à détecter des problèmes dans le code et certaines combinaisons de couleurs. Un score élevé ne prouve pas que le site respecte l’ensemble du référentiel. Le W3C recommande de combiner les outils avec une évaluation humaine ; aucun outil ne peut établir seul l’accessibilité d’un site. Évaluer l’accessibilité, W3C.

Organisez les contrôles autour de questions observables :

Clavier

pouvez-vous atteindre les commandes, voir où se trouve le focus, ouvrir et fermer les fenêtres, puis terminer la tâche ?

Lecteur d’écran

entendez-vous les intitulés, les champs obligatoires, les erreurs et la confirmation ?

Zoom et affichage étroit

pouvez-vous lire et utiliser les commandes sans masquer le contenu essentiel ?

Contenu

les titres décrivent-ils les sections ? Les liens annoncent-ils leur destination ? Les images utiles ont-elles une alternative pertinente ?

Médias

les personnes qui ne perçoivent pas le son ou l’image disposent-elles des alternatives requises pour comprendre le contenu ?

Faites participer des personnes handicapées lorsque vous évaluez les usages. Leurs observations complètent les tests techniques ; quelques séances utilisateur ne remplacent pas une évaluation de conformité sur le périmètre annoncé. Pour préparer les premiers essais, consultez notre checklist de navigation au clavier.

Exemple : une demande de rendez-vous en FR et EN

Le scénario suivant est fictif. Une PME propose un formulaire bilingue avec choix de date et confirmation. Le tableau montre comment transformer un obstacle en tâche vérifiable, sans attribuer ces résultats à un client EWM.

Le calendrier ne fonctionne qu’à la souris.

Conséquence pour le visiteur — Un visiteur au clavier ne peut pas choisir sa date.

Correction et contrôle — Le développeur rend le composant utilisable au clavier ; le testeur vérifie la sélection, la fermeture et le retour du focus.

Le formulaire signale une erreur uniquement en rouge.

Conséquence pour le visiteur — Le visiteur peut ne pas identifier le champ concerné ni comprendre la correction attendue.

Correction et contrôle — Le développeur associe un message textuel au champ ; le testeur vérifie son annonce et la conservation des autres valeurs.

Le bouton contient un texte gris trop clair.

Conséquence pour le visiteur — Un visiteur malvoyant peine à lire l’action proposée.

Correction et contrôle — Le designer ajuste les couleurs, puis contrôle le contraste du texte dans les différents états.

La page anglaise conserve une déclaration de langue française.

Conséquence pour le visiteur — Un lecteur d’écran peut prononcer le texte avec les mauvaises règles linguistiques.

Correction et contrôle — Le développeur corrige l’attribut HTML lang et le testeur contrôle les deux versions.

Après l’envoi, seule une petite coche apparaît.

Conséquence pour le visiteur — Le visiteur ne sait pas si sa demande a abouti.

Correction et contrôle — L’équipe ajoute une confirmation explicite et vérifie sa perception avec les technologies d’assistance.

Pour le texte courant, WCAG AA prévoit en règle générale un contraste d’au moins 4,5:1, ou 3:1 pour le grand texte défini par le critère. Ces seuils comportent des exceptions ; les composants et informations graphiques ont leurs propres exigences. Ne validez pas toute l’interface avec un seuil unique. Critère 1.4.3 et explications du W3C.

La langue du contenu se déclare avec lang, par exemple <html lang="fr"> et <html lang="en">. Identifiez aussi les passages dans une autre langue quand le critère le demande. Les annotations SEO hreflang ne remplacent pas cette déclaration. Déclarer la langue en HTML, W3C.

Prioriser et chiffrer les corrections

Classez d’abord les obstacles qui empêchent une tâche essentielle : connexion, commande, réservation ou prise de contact. Examinez ensuite les composants partagés, car une correction du menu ou d’un champ de formulaire peut concerner plusieurs pages. Réservez un travail éditorial aux textes alternatifs, documents et contenus multimédias.

Pour chaque anomalie, conservez la page, l’état testé, les étapes de reproduction, le critère concerné, la conséquence utilisateur et la personne responsable. Ajoutez un contrôle d’acceptation. « Améliorer le formulaire » reste trop vague ; « annoncer l’erreur du champ e-mail et permettre sa correction sans perdre les autres valeurs » donne une tâche à votre équipe.

Le coût dépend du nombre de modèles, des composants, des parcours, des documents et des intégrations. Un calendrier tiers peut nécessiter un changement de fournisseur ; un défaut dans un composant partagé peut demander une seule correction suivie de plusieurs contrôles. Séparez dans le devis : audit, corrections, reprise des contenus et vérification après intervention. Demandez les hypothèses de périmètre plutôt qu’un prix de certification présenté comme universel.

Examiner les outils tiers et les signalements

Incluez les bannières de consentement, calendriers, paiements et outils de chat dans vos essais. Avant de choisir un fournisseur, demandez ses résultats d’évaluation, les versions concernées et sa procédure de correction. Une réservation inutilisable reste un obstacle pour votre client, même si votre équipe ne développe pas le calendrier. Prévoyez les responsabilités et les possibilités de remplacement dans le contrat.

Proposez un moyen accessible de signaler une difficulté. Indiquez les informations utiles : page, tâche, problème rencontré et moyen de contact. Pour une organisation soumise à des obligations de déclaration d’accessibilité, vérifiez le contenu et le format exigés. Le BFEH publie une déclaration avec les limites connues et les coordonnées de contact sur son propre site. Exemple du BFEH.

Prévenir les régressions après la mise en ligne

Attribuez des responsabilités durables. Le designer prévoit les états de focus et d’erreur. Les développeurs vérifient les composants et les interactions. Les personnes qui publient les contenus renseignent les alternatives utiles et maintiennent les documents. Le responsable produit conserve la liste des parcours à contrôler après une modification.

Intégrez les contrôles automatisables à vos livraisons, puis retestez les parcours sensibles lors d’un changement de formulaire, de navigation ou de prestataire. Formez les éditeurs sur des exemples tirés de leur CMS. Un composant conforme peut perdre sa clarté si quelqu’un remplace son intitulé par « cliquez ici » ou publie un document inutilisable.

Questions fréquentes

Faut-il viser le niveau AAA ?

Définissez la cible selon votre public, le service et les exigences applicables. Vous pouvez retenir certains critères AAA utiles sans revendiquer une conformité AAA globale. Demandez à l’évaluateur de distinguer les obligations du périmètre et les améliorations supplémentaires.

Une extension d’accessibilité suffit-elle ?

Avant de retenir un outil, vérifiez les problèmes qu’il corrige et ceux qui restent dans le code, les contenus et les parcours. Ne considérez pas son installation comme une preuve de conformité. Testez le service obtenu avec les mêmes méthodes que le reste du site.

Peut-on annoncer une conformité après un audit partiel ?

Décrivez le périmètre évalué, la date, la méthode et les limites. La conformité WCAG concerne notamment des pages complètes et des processus complets. Une revue d’échantillon aide à organiser les corrections ; elle ne justifie pas une promesse plus large que ses résultats. Exigences de conformité WCAG 2.2.

L’accessibilité améliore-t-elle le SEO et les conversions ?

Des titres clairs, des liens explicites et un contenu compréhensible aident vos visiteurs. Mesurez les demandes, les abandons et les difficultés avant et après intervention, en tenant compte des autres changements du site. Vous ne pouvez pas déduire un pourcentage de gain ni une hausse de classement de la seule conformité WCAG.

Préparer votre prochain audit

Rassemblez vos parcours prioritaires, les langues, les prestataires externes et les contraintes applicables. Vous pourrez ensuite décider quelles corrections intégrer au site existant et lesquelles prévoir dans une refonte. Nos prestations de design UI/UX et de création de sites web permettent de cadrer ces travaux avec la conception et le développement.