Check-list d'accessibilité web pour TPE, PME et e-commerçants

Imaginez une cliente qui utilise un lecteur d'écran. Elle trouve les baskets qu'elle cherche, choisit sa pointure et appuie sur ce qu'elle croit être le bouton du panier. Son lecteur d'écran annonce « bouton ». Rien d'autre. Il y en a trois comme ça sur la page, aucun n'a de nom : elle s'en va, et vous ne saurez jamais pourquoi.

La plupart des problèmes d'accessibilité sur les sites internet de petites entreprises ressemblent à cela : invisibles pour le propriétaire, une impasse pour le client. Cette check-list s'adresse à celles et ceux qui gèrent un site Shopify, WooCommerce, PrestaShop, Wix ou Squarespace sans développeur dans l'équipe.

Le site de ma petite entreprise doit-il être accessible ?

Si vous vendez à des consommateurs dans l'UE, probablement. L'European Accessibility Act (s'ouvre dans un nouvel onglet) couvre les services de commerce électronique depuis le 28 juin 2025. La principale exemption vise les microentreprises prestataires de services : moins de 10 salariés et un chiffre d'affaires annuel ou un total de bilan d'au plus 2 millions d'euros.

Le commerce électronique désigne ici la vente à distance, par un site ou une appli, « à la demande individuelle d'un consommateur, en vue de conclure un contrat de consommation » (article 3, point 30). Une boutique en ligne ou un moteur de réservation entrent dans cette définition. L'exemption ne concerne que les services : qui vend des produits couverts, comme des liseuses, reste soumis aux règles sur les produits (article 4, paragraphe 5). Être établi hors de l'UE n'y change rien non plus : une boutique suisse ou britannique qui vend à des clients en France est concernée pour ces clients (article 3, point 4). Notre guide de l'European Accessibility Act détaille les lois nationales et les sanctions.

Au Royaume-Uni, l'Equality Act 2010 (s'ouvre dans un nouvel onglet) impose des aménagements raisonnables pour les personnes handicapées, sans fixer de norme technique pour les sites web. Aux États-Unis, les recommandations de mars 2022 (s'ouvre dans un nouvel onglet) du ministère de la Justice indiquent que les entreprises ouvertes au public doivent rendre accessible ce qu'elles proposent en ligne, et que des normes comme les WCAG « fournissent des repères utiles ». Quoi que dise la loi, un client qui ne peut pas finaliser sa commande n'achète pas.

Quels sont les problèmes d'accessibilité les plus fréquents sur les sites web ?

Six défauts dominent. Dans le WebAIM Million 2026 (s'ouvre dans un nouvel onglet), une analyse automatique des pages d'accueil du premier million de sites réalisée en février 2026, 95,9 % des pages présentaient des erreurs WCAG détectées, avec en moyenne 56,1 erreurs par page. Le texte trop peu contrasté était le problème le plus courant, présent sur 83,9 % des pages d'accueil.

Les WCAG (Règles pour l'accessibilité des contenus web) sont la norme derrière ces vérifications ; la plupart des lois renvoient à leur niveau AA, et notre guide des WCAG 2.2 présente la dernière version. Plusieurs points ci-dessous échappent à tout outil d'analyse automatique.

Tout le monde peut-il lire vos textes et comprendre vos images ?

Commencez par là : ces corrections coûtent peu et vous pouvez presque toutes les faire vous-même dans l'éditeur du site. Le texte doit être assez contrasté, les images porteuses d'information doivent avoir un texte alternatif, et rien ne doit reposer uniquement sur la couleur. Environ 1 homme sur 12 et 1 femme sur 200 ont un trouble de la vision des couleurs, selon Colour Blind Awareness (s'ouvre dans un nouvel onglet).

• Contraste. Le texte courant doit présenter un rapport de contraste d'au moins 4,5:1 (s'ouvre dans un nouvel onglet) avec son arrière-plan, le texte en grands caractères au moins 3:1. Testez vos couleurs, y compris le texte posé sur des photos de bannière, avec un outil gratuit. Notre guide du contraste des couleurs montre des corrections qui respectent votre charte.
• Textes alternatifs des produits. Décrivez ce qu'un acheteur a besoin de savoir : « Pull en laine bleu marine à col roulé côtelé, vue de face » vaut mieux que « image produit 1 ». Commencez par vos dix meilleures ventes.
• Images décoratives. Une arabesque en arrière-plan doit avoir un texte alternatif vide pour que les lecteurs d'écran l'ignorent. Certaines plateformes remplissent un champ alt vide avec le nom du fichier : vérifiez la vôtre.
• Couleur seule. Un « Épuisé » signalé uniquement par une pastille grisée, ou un champ obligatoire marqué seulement en rouge, n'atteindra pas tout le monde. Affichez la page avec le filtre niveaux de gris de votre téléphone et ajoutez un mot ou une icône partout où le sens disparaît.
• Zoom. Avec un zoom du navigateur à 200 %, le texte doit s'agrandir sans se chevaucher ni être coupé, et le menu doit toujours fonctionner.
• Langue de la page. N'importe quel outil gratuit signale une déclaration de langue manquante. C'est un réglage du thème ou une ligne à changer dans le gabarit.

Peut-on utiliser votre site au clavier ?

Beaucoup de gens naviguent sans souris : les utilisateurs de lecteurs d'écran, les personnes qui ont des tremblements ou une mobilité réduite des mains, et quiconque vient de voir son pavé tactile rendre l'âme. Mettez la souris de côté et appuyez sur Tab. Vous devez atteindre chaque lien, bouton et champ de formulaire dans un ordre logique, toujours voir où vous êtes, et ne jamais rester bloqué.

• Focus visible. Un contour doit indiquer l'élément actif, et un en-tête fixe ou une bulle de chat ne doit pas le recouvrir (critère 2.4.11 Focus non masqué des WCAG 2.2). Beaucoup de thèmes suppriment ce contour par souci esthétique ; un développeur peut le rétablir.
• Aucun piège. Ouvrez au clavier le menu, le sélecteur de taille, les fenêtres pop-up et la galerie d'images, choisissez quelque chose, puis essayez d'en sortir. La touche Échap doit fermer les pop-up.
• Des noms pour les icônes. Chaque lien ou bouton en forme d'icône a besoin d'un nom qu'un lecteur d'écran peut annoncer, comme « Panier, 2 articles ». Remplacez « Cliquez ici » par des mots qui disent où mène le lien.
• Lien d'évitement et titres. La première pression sur Tab devrait idéalement faire apparaître un lien « Aller au contenu ». Dans l'enquête 2024 de WebAIM auprès des utilisateurs de lecteurs d'écran (s'ouvre dans un nouvel onglet), 71,6 % des répondants disent parcourir d'abord une longue page par ses titres : utilisez de vrais niveaux de titres, pas du texte en gras.
• Cibles tactiles. Les WCAG 2.2 demandent des cibles d'au moins 24 sur 24 pixels CSS, ou assez d'espace autour (critère de succès 2.5.8 (s'ouvre dans un nouvel onglet)).

Tout le monde peut-il aller au bout de vos formulaires, du panier et du paiement ?

C'est au paiement que les problèmes d'accessibilité vous coûtent directement de l'argent : testez-le de bout en bout, y compris ce qui se passe en cas d'erreur. Chaque champ a besoin d'une étiquette visible, les erreurs doivent expliquer le problème en toutes lettres, et la connexion ne doit pas dépendre d'un test de mémoire ou d'une énigme. Les pages de votre prestataire de paiement comptent aussi.

• Des étiquettes, pas des textes indicatifs. Le texte indicatif (placeholder) disparaît dès que l'on tape et il est souvent trop pâle pour être lu. Chaque champ a besoin d'une étiquette qui reste visible.
• Messages d'erreur. Envoyez le formulaire vide. Chaque erreur doit être expliquée en toutes lettres (« Saisissez un code postal, par exemple 75011 »), placée à côté de son champ et annoncée, pas seulement signalée par une bordure rouge.
• Ne demandez pas deux fois. Proposez « L'adresse de facturation est identique » au lieu de faire retaper l'adresse de livraison. Les WCAG 2.2 en ont fait une exigence de niveau A, le 3.3.7 Saisie redondante.
• Connexion. Permettez de coller les mots de passe et les codes à usage unique, et d'utiliser les gestionnaires de mots de passe. Bloquer le collage enfreint le critère d'authentification accessible (s'ouvre dans un nouvel onglet) des WCAG 2.2, sauf si vous proposez un autre moyen de se connecter.
• CAPTCHA. Dans l'enquête 2024 de WebAIM, les utilisateurs de lecteurs d'écran classent le CAPTCHA comme l'élément le plus problématique du web. Si vous avez besoin d'une protection contre les robots, évitez les énigmes visuelles et proposez toujours une alternative non visuelle.
• Délais. Si un panier ou une réservation expire, prévenez la personne et laissez-la prolonger.

Si certaines parties du paiement appartiennent à votre plateforme ou à votre prestataire de paiement, testez-les quand même, signalez les problèmes et listez-les comme problèmes connus.

Et les bandeaux cookies, les pop-up et les widgets de chat ?

Pour vos clients, les scripts tiers font partie de votre site. Un bandeau cookies impossible à fermer au clavier bloque toutes les pages, et une pop-up newsletter qui capte le focus en plein paiement peut faire perdre une vente. Testez chaque script que vous avez ajouté, et interrogez les éditeurs sur l'accessibilité avant d'en installer un nouveau.

• Bandeau cookies. Pouvez-vous atteindre « Accepter » et « Refuser » avec Tab, les lire avec un zoom à 200 %, puis reprendre là où vous en étiez ?
• Pop-up. Le focus doit entrer dans la pop-up, y rester jusqu'à sa fermeture, puis revenir à sa place. La touche Échap doit la fermer.
• Widgets de chat. Le bouton a besoin d'un nom, la fenêtre doit s'ouvrir et se fermer au clavier, et sur téléphone elle ne doit pas recouvrir « Payer maintenant ».
• Carrousels. Tout ce qui bouge automatiquement pendant plus de cinq secondes doit pouvoir être mis en pause, arrêté ou masqué (WCAG 2.2 (s'ouvre dans un nouvel onglet), critère de succès 2.2.2).
• Contenus intégrés. Widgets d'avis, cartes et outils de réservation sont eux aussi sur votre page. Signalez les défauts au fournisseur.

Vos vidéos, vos PDF et vos menus fonctionnent-ils pour tout le monde ?

Les vidéos ont besoin de sous-titres, l'audio d'une transcription, et une information importante ne doit pas exister uniquement dans un PDF ou une image. Un restaurant dont la carte est un PDF scanné, ou une boutique dont le guide des tailles est la photo d'un tableau, exclut les utilisateurs de lecteurs d'écran et tous ceux qui ont besoin de zoomer sur leur téléphone.

• Sous-titres et transcriptions. Corrigez les sous-titres automatiques avant publication. Les podcasts ont besoin d'une version texte.
• Texte en image. Mettez cartes de restaurant, tarifs, guides des tailles et horaires sur une page web ordinaire. Si vous devez utiliser un PDF, exportez-le depuis votre traitement de texte avec titres et balises, au lieu de scanner un document imprimé.
• Anciens fichiers. L'EAA n'exige pas de corriger les documents bureautiques ni les contenus audio et vidéo préenregistrés publiés avant le 28 juin 2025, ni les archives que vous ne mettez plus à jour (article 2, paragraphe 4). Les nouveaux fichiers sont concernés.

Que puis-je corriger moi-même, et quand faut-il un développeur ou un audit ?

Vous pouvez corriger vous-même la plupart des problèmes de contenu dans le CMS : textes alternatifs, titres, intitulés de liens, couleurs, sous-titres et bon nombre d'étiquettes de formulaire. Les problèmes liés au thème, comme l'absence de styles de focus, les pièges au clavier et les listes déroulantes sur mesure, demandent un développeur. Un audit a surtout du sens une fois les bases corrigées, ou avant la mise en ligne d'une refonte.

Quelle place pour un widget comme le nôtre ? Un panneau côté visiteur comme SiteAccessible permet d'augmenter le contraste, d'agrandir le texte ou d'activer un guide de lecture. Cela aide certains visiteurs, mais ne coche aucune case de cette liste : un bouton sans nom reste sans nom, et un piège au clavier reste un piège. Corrigez d'abord le site, et considérez le widget comme un complément.

Comment garder une trace de ce que j'ai fait ?

Tenez un journal simple de ce que vous avez testé, quand, ce que vous avez corrigé et ce qui ne fonctionne toujours pas, puis publiez-en un résumé honnête dans une déclaration d'accessibilité. Si l'EAA s'applique à vous, vous devez aussi publier des informations sur la façon dont votre service respecte les exigences d'accessibilité, en général dans vos conditions générales ou un document équivalent.

Cette seconde obligation vient de l'annexe V de la directive ; la loi nationale en fixe la forme. Notre guide pour rédiger une déclaration d'accessibilité contient un modèle à adapter. Ensuite, gardez le rythme :

1. Passez la check-list sur vos trois pages clés et faites une capture d'écran de chaque défaut.
2. Corrigez vous-même les éléments de contenu cette semaine.
3. Confiez à un développeur les points liés au thème et au paiement, les plus graves d'abord.
4. Retestez chaque correction au clavier, en plus de l'outil de vérification.
5. Publiez ou mettez à jour votre déclaration, datée.
6. Recommencez à chaque nouvelle appli, changement de thème ou nouvelle page de destination.