Accessible on WordPress

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 [2]Source 2 .

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 [1]Source 1 .

• Navigation works with keyboard only, including any submenu behaviour [1]Source 1 .
• Focus states are visible across the whole site [1]Source 1 .
• Heading structure makes sense and follows a logical order [1]Source 1 .
• Landmarks exist and are consistent, header, main content, footer, navigation [1]Source 1 .
• Buttons are real buttons. Links are real links [1]Source 1 .
• Modals, if used, trap focus and return focus correctly when closed [1]Source 1 .

2) Forms and error handling

Forms are where accessibility failures become business failures [4]Source 4 .

• All fields have visible labels [4]Source 4 .
• Required fields are explained [3]Source 3 .
• Errors appear in a helpful way, and tell the user what to do next [3]Source 3 [5]Source 5 .
• Errors are announced to assistive technology and connected to the relevant fields [3]Source 3 .
• You can complete the form using keyboard only [1]Source 1 .

3) Plugin UI and widgets

Plugins often inject UI elements that do not match your theme patterns. Each one adds accessibility risk unless it is tested and governed [2]Source 2 .

• Any slider, modal, filter, or calendar plugin works with keyboard only [1]Source 1 .
• Plugin controls have clear labels [1]Source 1 .
• Plugin UI does not introduce focus traps [1]Source 1 .
• Plugin markup does not break headings and landmarks [1]Source 1 .
• You avoid adding plugins for cosmetic features that add risk.

4) Editor workflow and governance

A good build can degrade if the editor experience encourages inaccessible content. Put guardrails in place [2]Source 2 .

• Editors add headings correctly, without guessing [1]Source 1 .
• Editors understand link text and alt text basics [1]Source 1 .
• Reusable blocks exist for common patterns, so people do not invent their own.
• Page structure stays consistent across templates [1]Source 1 .
• A short publishing checklist exists for content authors.

5) Testing evidence and deliverables

The fastest way to assess an accessibility claim is to ask for evidence from a recent project [2]Source 2 .

• A sample audit report with issues, severity, and steps to reproduce.
• Confirmation of manual keyboard testing across key journeys [2]Source 2 .
• A description of which assistive technology checks were run [2]Source 2 .
• A clear definition of scope. Pages, templates, and journeys.
• Retesting after fixes, with closure notes [2]Source 2 .

Red flags in WordPress accessibility claims

• They rely on an automated tool as the audit [2]Source 2 .
• They say WordPress is accessible by default.
• They recommend an overlay to fix accessibility [6]Source 6 [7]Source 7 [8]Source 8 .
• They cannot explain focus management or keyboard journeys [1]Source 1 .
• 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 [5]Source 5 .
• Zoom to 200% and check usability, especially navigation and forms [1]Source 1 .
• Check whether focus is always visible [1]Source 1 .

What a safe WordPress approach looks like

• A theme chosen for clean markup and predictable patterns, not flashy demos [1]Source 1 .
• 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 [2]Source 2 .

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.