Accessibility with WordPress

WordPress itself can be accessible — the problems usually come via the theme, the plugins and the page blocks.

Common places for findings

Themes with too low contrast or no visible focus, slider plugins without pause/keyboard control, embedded forms (Contact Form 7 and the like) with unlabelled fields, image blocks without alt text, and page builders that turn headings into mere large paragraphs. The WordPress core editor is usually not the problem — the layer above it is.

Check and choose the theme

A theme decides contrast, focus display, heading structure and keyboard operation of the navigation. Criteria before you choose: tab through the page — is the focus always visible? Is the menu operable without a mouse? Is the colour contrast of text and buttons at least 4.5:1? Block-based default themes (Twenty Twenty-Four/-Five) are a solid starting point; for purchased themes, look at the demo with CSS turned off and run the keyboard test.

Work cleanly in the block editor

Use heading blocks in the right order (one H1 per page, don't skip a level) — don't just make text big and bold. Give every image block an alt text; mark purely decorative images explicitly as decorative. Use the button block for actions, real links for navigating. Lists as list blocks, not a paragraph with dashes. Tables only for genuine tabular data, and with a header row.

Plugins and forms

Form plugins (Contact Form 7, WPForms, Gravity Forms) only produce accessible forms if every field has a visible, linked label and error messages are tied to the field — placeholder text alone is not enough. Sliders and carousels need a pause button and must not trap keyboard focus; when in doubt, leave them out. Page builders (Elementor, Divi, WPBakery) are not inaccessible per se, but they invite nested div structures without semantics — pay particular attention to headings and focus here.

Testing

Three quick tests without extra software: (1) operate the page with the keyboard only — Tab, Enter, arrow keys; can you reach everything and get back out? (2) zoom to 200% in the browser — does everything stay readable and operable? (3) run a browser extension like WAVE or axe DevTools. a11yglass's free scan additionally checks the delivered HTML of your home page for contrast, alt texts, labels, language and structure, and names the WCAG criterion for each finding.

Frequently asked questions

Does an accessibility plugin make my site compliant? No — overlay plugins that toggle contrast and font size via a widget do not fix the structural problems and are criticised by disability advocacy groups. Which theme is accessible? There is no seal; what matters is the implementation in the specific case — the criteria above help with the choice. Does my WordPress site need an accessibility statement? That depends on whether the site falls under the BFSG (electronic commerce) or is run by a public body — see the page on the accessibility statement.

How a11yglass helps

The free scan checks the delivered HTML and CSS for automatically recognisable WCAG breaches, and names per finding the success criterion and a concrete step. It finds roughly 20–35% of issues and does not replace a full assessment.

Read on

General information to the best of our knowledge, not legal advice. For an individual case, contact a law firm specialising in IT law.