Platform

WordPress

WordPress does not make a site compliant or non-compliant: it all depends on the theme, the plugins and the content. The good news is that almost everything can be fixed without changing platform.

WordPress core produces a sound base, and the block editor outputs reasonably clean markup. A site's real accessibility is decided elsewhere: in the chosen theme, in page builders and in publishing discipline.

What is decided in the theme

• The official directory's « accessibility-ready » label signals a vetted baseline (keyboard navigation, heading structure, default theme contrast). It is a serious starting point, not full WCAG conformance.
• Page builders add their own markup: multiple headings, removed focus outlines, carousels. Every built template deserves a keyboard check.
• Focus states are often neutralised by theme styling. Restoring them is a short, high-impact CSS fix.

What is decided at publishing time

• Alt text is entered in the media library, but text added afterwards does not propagate to images already inserted in posts: existing content must be revisited.
• Heading hierarchy breaks easily in the editor, when a level is picked for its size rather than its place in the outline.
• On WooCommerce, the sensitive spots are product galleries, variant dropdowns and add-to-cart notices: they must be keyboard operable and announced to screen readers.

Where to start

A scan of the homepage and the main templates (post, page, product page) places the site in seconds. Our July 2026 study of French e-commerce gives the scale of the problem: 94.5% of the 55 sites analysed showed at least one critical or serious non-conformity. Our panels, however, contained too few WordPress stores to publish a platform-specific breakdown: we do not publish figures our data cannot carry.