Originally published: January 1, 2022 · Last updated: August 17, 2026
WordPress can provide a strong foundation for accessible websites, but accessibility is not guaranteed by the CMS, theme or an accessibility plugin. The final site still depends on content choices, design, custom code, plugins and how interactive elements work together.
WordPress currently targets WCAG 2.2 level AA for new and updated core code. Site owners can use the same standard as a practical reference for their own themes and content.
1. Test the site with a keyboard
Put the mouse aside and move through the page using Tab, Shift+Tab, Enter, Space and arrow keys where appropriate. You should be able to reach interactive controls, understand where focus is and avoid becoming trapped inside a menu, modal or widget.
Keyboard testing often reveals problems that are invisible during normal mouse use.
2. Keep focus visible
Links, buttons and form controls need a visible focus state. Removing outlines for aesthetic reasons can make a site extremely difficult to navigate without a mouse.
A focus indicator should be easy to see against the surrounding design and should not disappear behind sticky headers or overlays.
3. Use real headings in a logical structure
Headings organize the document for everyone, including people who navigate with assistive technology. Use an H1 for the page’s main purpose and H2/H3 levels to describe real sections.
Do not choose a heading level simply because its default font size looks right. Style the correct semantic element instead.
4. Write useful alternative text
Alternative text should communicate the meaning a relevant image adds to the page. A product detail, chart or artwork may need a meaningful description. A decorative image may be better with an empty alt attribute.
Do not use alt text as a hidden keyword field. Its primary purpose is accessibility.
5. Check color contrast
WCAG 2.2 level AA requires normal text to have a contrast ratio of at least 4.5:1 against its background, with different thresholds for large text and other interface elements.
Check links, placeholders, hover states, buttons and text over images as well as normal body copy. A palette can look elegant on a designer’s monitor while becoming unreadable for someone with low vision.
6. Do not rely on color alone
If red means “error” or green means “available”, provide another visible cue such as text, an icon with an accessible label or a clear pattern. The information should remain understandable for people who do not perceive the color difference.
7. Make forms understandable
Fields need labels that remain available when someone starts typing. Placeholder text is not a replacement for a proper label.
Required fields, errors and instructions should be communicated clearly. After a submission error, help the visitor understand what needs to be corrected rather than relying only on a red border.
8. Use descriptive link and button text
“Read more” and “click here” can be ambiguous when encountered outside surrounding context. Where practical, link text should explain the destination or action.
Buttons should describe what happens, such as “Download the checklist” or “Book an appointment”.
9. Respect zoom, reflow and responsive layouts
Users may enlarge text substantially or use a narrow viewport. Content should reflow without requiring horizontal scrolling for ordinary reading, and critical controls should not overlap or disappear.
Test browser zoom as well as responsive preview. They expose different layout assumptions.
10. Treat automated accessibility scanners as a first pass
Automated testing can detect missing labels, some contrast failures and certain markup problems. It cannot determine whether alt text is meaningful, whether focus order makes sense or whether a workflow is understandable with a screen reader.
Combine automated checks with keyboard testing and, for important sites, manual assistive-technology testing.
Choose themes and plugins carefully
The WordPress theme directory includes an accessibility-ready designation for themes that have passed specified accessibility checks. That tag is useful evidence, but it is not a guarantee that the final website will meet every accessibility requirement once plugins and custom content are added.
Evaluate interactive plugins such as menus, sliders, popups, forms and booking tools because they can introduce accessibility problems even on a good theme.
Do not rely on an overlay to “make the site compliant”
A toolbar or overlay may offer useful preferences, but it does not repair inaccessible source content, keyboard traps, missing labels or poor information architecture by itself.
Accessibility should be built into the underlying interface and content.
A practical monthly accessibility review
- Navigate key pages using only the keyboard.
- Check visible focus and menus.
- Review headings and landmarks.
- Test forms and errors.
- Check contrast on new design components.
- Review alt text on newly added images.
- Zoom to 200% and inspect reflow.
- Run an automated scanner as a secondary check.
The practical rule
Accessibility is ongoing quality control. Build pages that remain understandable without perfect vision, a mouse or one specific screen size. WordPress can support that work, but the final responsibility sits with the choices made in the theme, content and plugins.
Official references: WordPress accessibility statement, WordPress Accessibility Team Handbook and WCAG 2.2.