Accueil › Ressources › Par système

L'accessibilité avec WordPress

WordPress lui-même peut être accessible — les problèmes viennent le plus souvent du thème, des extensions et des blocs de page.

Points fréquents

Thèmes à contraste trop faible ou sans focus visible, extensions de diaporama sans pause/navigation clavier, formulaires intégrés (Contact Form 7 et similaires) aux champs non étiquetés, blocs image sans texte alternatif, et constructeurs de pages qui transforment les titres en simples grands paragraphes. L'éditeur de base de WordPress n'est généralement pas le problème — la couche au-dessus, si.

Vérifier et choisir le thème

Un thème décide du contraste, de l'affichage du focus, de la structure des titres et de la navigation au clavier. Critères avant de choisir : parcourez la page avec la touche Tab — le focus est-il toujours visible ? Le menu est-il utilisable sans souris ? Le contraste des couleurs du texte et des boutons est-il d'au moins 4,5:1 ? Les thèmes par défaut basés sur les blocs (Twenty Twenty-Four/-Five) sont un bon point de départ ; pour les thèmes payants, regardez la démo avec le CSS désactivé et faites le test au clavier.

Travailler proprement dans l'éditeur de blocs

Utilisez les blocs de titre dans le bon ordre (un seul H1 par page, ne sautez pas de niveau) — ne vous contentez pas de mettre le texte en grand et en gras. Donnez un texte alternatif à chaque bloc image ; marquez explicitement comme décoratives les images purement décoratives. Utilisez le bloc bouton pour les actions, de vrais liens pour la navigation. Les listes en bloc liste, pas un paragraphe avec des tirets. Les tableaux uniquement pour de vraies données tabulaires, et avec une ligne d'en-tête.

Extensions et formulaires

Les extensions de formulaires (Contact Form 7, WPForms, Gravity Forms) ne produisent des formulaires accessibles que si chaque champ a une étiquette visible et liée et que les messages d'erreur sont rattachés au champ — le texte d'espace réservé seul ne suffit pas. Les diaporamas et carrousels ont besoin d'un bouton pause et ne doivent pas piéger le focus clavier ; en cas de doute, à supprimer. Les constructeurs de pages (Elementor, Divi, WPBakery) ne sont pas inaccessibles en soi, mais ils incitent à des structures de div imbriquées sans sémantique — soyez ici particulièrement attentif aux titres et au focus.

Tester

Trois tests rapides sans logiciel supplémentaire : (1) utilisez la page au clavier seul — Tab, Entrée, flèches ; peut-on aller partout et en ressortir ? (2) zoomez à 200 % dans le navigateur — tout reste-t-il lisible et utilisable ? (3) lancez une extension de navigateur comme WAVE ou axe DevTools. Le scan gratuit d'a11yglass vérifie en plus le HTML livré de votre page d'accueil pour le contraste, les textes alternatifs, les étiquettes, la langue et la structure, et indique le critère WCAG pour chaque constat.

Questions fréquentes

Une extension d'accessibilité rend-elle mon site conforme ? Non — les extensions de surcouche qui basculent le contraste et la taille de police via un widget ne corrigent pas les problèmes structurels et sont critiquées par les associations de personnes concernées. Quel thème est accessible ? Il n'y a pas de label ; ce qui compte, c'est la mise en œuvre dans le cas concret — les critères ci-dessus aident au choix. Mon site WordPress a-t-il besoin d'une déclaration d'accessibilité ? Cela dépend de savoir si le site relève du BFSG (commerce électronique) ou s'il est exploité par un organisme public — voir la page sur la déclaration d'accessibilité.

Comment a11yglass aide

Le scan gratuit vérifie le HTML et le CSS livrés à la recherche d'infractions WCAG détectables automatiquement et indique pour chaque constat le critère de succès et une mesure concrète. Il détecte environ 20 à 35 % des problèmes et ne remplace pas un audit complet.