Start with the reality
WordPress is a tool. It does not guarantee accessibility and it does not prevent it.
The outcome depends on theme markup, plugin UI, content workflows, and whether the supplier tests properly.
What to verify before you sign
1) The theme output
The theme controls your base markup. If it is poor, you start with a disadvantage.
- Navigation works with keyboard only, including any submenu behaviour.
- Focus states are visible across the whole site.
- Heading structure makes sense and follows a logical order.
- Landmarks exist and are consistent, header, main content, footer, navigation.
- Buttons are real buttons. Links are real links.
- Modals, if used, trap focus and return focus correctly when closed.
2) Forms and error handling
Forms are where most accessibility failures become business failures.
- All fields have visible labels.
- Required fields are explained.
- Errors appear in a helpful way, and tell the user what to do next.
- Errors are announced to assistive technology and connected to the relevant fields.
- You can complete the form using keyboard only.
3) Plugin UI and widgets
Plugins often inject UI elements that do not match your theme patterns.
- Any slider, modal, filter, or calendar plugin works with keyboard only.
- Plugin controls have clear labels.
- Plugin UI does not introduce focus traps.
- Plugin markup does not break headings and landmarks.
- You avoid adding plugins for cosmetic features that add risk.
4) Editor workflow and governance
Even a good build can degrade if the editor experience encourages inaccessible content.
- Editors can add headings correctly, without guessing.
- Editors understand how to write link text and alt text.
- Reusable blocks are provided for common patterns, so people do not invent their own.
- Page structure stays consistent across templates.
- There is a simple publishing checklist for content authors.
5) Testing evidence and deliverables
The fastest way to assess a claim is to ask for evidence from a recent project.
- A sample audit report with issues, severity, and steps to reproduce.
- Confirmation of manual keyboard testing across key journeys.
- A description of which assistive technology checks were run.
- A clear definition of scope. Pages, templates, and journeys.
- Retesting after fixes, with closure notes.
Red flags in WordPress accessibility claims
- They rely on an automated tool as the audit.
- They say WordPress is accessible by default.
- They recommend an overlay to fix accessibility.
- They cannot explain focus management or keyboard journeys.
- They avoid sharing sample reports or testing artefacts.
Quick tests you can run on any WordPress demo
You do not need admin access for these.
- Use Tab to navigate the homepage, then a long content page, then the contact form.
- Open the full navigation with keyboard only, then close it again.
- Submit the form with empty required fields and read the errors.
- Zoom to 200% and check usability, especially navigation and forms.
- Check whether focus is always visible.
What a safe WordPress approach looks like
- A theme chosen for clean markup and predictable patterns, not for flashy demos.
- A minimal plugin set with a written reason for each plugin.
- Standardised components for forms, navigation, and content blocks.
- A content author checklist and training on headings, links, and alt text.
- Manual testing and retesting baked into delivery.
Next step
If you are buying a WordPress build, request a short accessibility review of the theme and key plugins before content build starts. It is cheaper to choose the right foundations than to retrofit fixes after launch.