WordPress accessibility: checking themes, content and plugins
A practical workflow for WordPress teams: choose suitable themes, keep content accessible and test changes on the real user journey.
In short
A WordPress website's accessibility comes from the theme, the editorial content, the plugins and how they work together. A theme tagged “accessibility-ready” is a helpful starting point, but it does not prove that the finished website conforms to WCAG. So test the published result and complete processes.
Assign responsibility to the right places
The theme determines the navigation and page structure, for example. The editorial team chooses headings, link texts and image descriptions. Plugins add forms, shops or booking processes. Make a short list: which component provides which visible area, and who can change it? An error in the form plugin usually cannot be fixed by formatting the text of a post.
WordPress states explicitly that “accessibility-ready” refers to the review criteria for themes and does not automatically mean WCAG AA for the entire offering. So test a demo with the content and extensions you will actually use.
Use real structure in the editor
Use the Heading block for section titles and choose a level that fits the outline. A bold paragraph is not a heading. Use List blocks for lists and describe links by their purpose: “Registration form for the workshop” is easier to understand than a repeated “Click here”.
Check that longer posts have subheadings and short paragraphs. The order in the editor should still make sense without the column layout added later. What counts is the content output on the front end, not just the view in the back end.
Assess images in each post
The Image block has a field for alternative text. Describe the image's relevant message in its specific context there. A photo of the same building can set the mood on the home page and show the entrance on a directions page. The right text may therefore differ. After inserting an image, check that individual Image block; don't rely on later changes to a media library entry updating every existing use accordingly.
Test plugins against a task
- Build a representative test page with navigation, an image, a download and your most important form.
- Operate menus, accordions, dialogs and forms entirely with the keyboard.
- Check zoom, narrow viewports and error messages on the actual front end.
- Also test the main form or the purchase journey with a screen reader.
- Document problems together with the responsible theme or plugin and repeat the test after a change.
Use the Accessonaut plugin as a complement
With the Accessonaut WordPress plugin, you can embed the visitor menu and adjust its appearance centrally in the project or locally in WordPress. When installing it, check whether the launcher clashes with other fixed elements and stays reachable on mobile devices. The menu offers personal display settings; fixing an unlabelled form field or an unsuitable theme structure remains a task at the relevant source.
Establish a small sign-off routine
Before major theme or plugin updates, set up a suitable test environment. Note three to five typical tasks, such as “Book an appointment”, “Use search” and “Send a contact message”. Repeat these tasks after the update and add automated checks. Give the editorial team a short checklist for new posts. That way, accessibility becomes part of day-to-day operations and does not depend on a one-off plugin installation.
Sources & review status
Here you’ll find the original sources for this article. Last checked on .
- WordPress Theme Handbook: accessibility and accessibility-ready
- WordPress: Heading block
- WordPress: Image block and alternative text
- W3C WAI: first checks for websites
Legal requirements depend on the country, the provider and the specific offer. This article explains the basics and practical steps. Test results apply to their documented scope and date.