WordPress Development
WordPress Accessibility Plugins Compared: What Works, What Doesn’t, and What to Do Instead
Accessibility overlays do not make sites accessible. Here is what actually works for WordPress — the plugins that fix real issues, the themes that provide accessible foundations, and how to test.
Making a WordPress site accessible is not a single plugin click — it is a combination of theme selection, correct content practices, and where genuinely needed, specialised tools. This guide cuts through the confusion around WordPress accessibility plugins: what they can realistically do, what they cannot, and which combination produces the most accessible result.
The accessibility plugin landscape — what to know first
WordPress accessibility has two categories of plugin: those that fix genuine code-level issues (missing form labels, incorrect ARIA attributes, keyboard navigation gaps) and those that add an overlay widget giving users the ability to adjust visual presentation (font size, contrast, spacing). These categories solve different problems and have very different reputations in the accessibility community.
Overlays such as accessiBe, UserWay, and similar tools are the subject of a public statement signed by hundreds of accessibility professionals stating they do not make websites accessible. The issues they claim to fix (incorrect ARIA, keyboard traps, screen reader incompatibility) require code-level solutions, not a JavaScript overlay. Overlays may help some users with visual preferences (larger text, higher contrast) but do not substitute for genuinely accessible code.
Plugins that fix genuine accessibility issues
Accessible theme selection
The most impactful accessibility decision is theme selection. An accessible theme provides the foundation that plugins build on. Themes with the ‘Accessibility Ready’ tag on WordPress.org have been reviewed for basic WCAG compliance:
- GeneratePress: one of the most accessibility-tested WordPress themes. Keyboard navigable, correct focus states, semantic HTML structure.
- Astra: strong accessibility defaults with extensive options for skip links, focus states, and ARIA landmark configuration.
- Twenty Twenty-Four: the official WordPress block theme is developed with accessibility as an explicit requirement of every new feature.
- Kadence: accessible defaults, comprehensive keyboard navigation, and correct heading hierarchy support.
Content-level accessibility — what plugins cannot fix
Many accessibility issues are not fixable by plugins because they are content problems, not code problems:
- Missing alt text: a plugin can warn you, but only you can write the correct description of each image. Accessibility Checker by Equalize Digital flags missing alt text per post.
- Incorrect heading hierarchy: skipping from H1 to H4, or using multiple H1s, is an author error. Plugins can detect it; authors must fix it.
- Poor link text: links labelled ‘click here’, ‘read more’, or ‘learn more’ are inaccessible to screen reader users who navigate by links. Authors must rewrite them.
- Colour contrast: insufficient contrast between text and background must be fixed in your theme or custom CSS. The WebAIM Contrast Checker identifies failing combinations; your designer fixes them.
- Form labels: missing or incorrect form labels require fixing in your form plugin’s configuration (WPForms, Gravity Forms) or in custom HTML.
Testing accessibility on WordPress
Install Equalize Digital Accessibility Checker free. Visit each key page of your site. The plugin reports issues in the post editor sidebar. Address all errors (high priority) and as many warnings as possible.
Go to wave.webaim.org and enter your URL. WAVE provides a visual overlay of accessibility issues on your page. The red errors are WCAG failures; yellow alerts are warnings worth investigating.
Put your mouse aside. Use Tab to move through every interactive element on the page. Every link, button, and form field must be reachable and have a visible focus indicator.
Mac: enable VoiceOver with Cmd+F5. Windows: download NVDA (free). Navigate your site with the screen reader active. Listen for missing alt text announcements, incorrectly labelled buttons, and heading structure.
Use the WebAIM Contrast Checker (webaim.org/resources/contrastchecker/) for every text/background combination. WCAG 2.1 AA requires 4.5:1 for normal text, 3:1 for large text.
Accessibility for WooCommerce
WooCommerce checkout and product pages have specific accessibility requirements beyond standard content pages:
- Error messages on checkout must be descriptive and associated with the specific field that has an error
- Product images must have descriptive alt text that communicates what a screen reader user cannot see
- The Add to Cart button must be keyboard accessible and clearly labelled with the specific product name
- Payment form fields must have explicit labels that screen readers can announce correctly
- Order confirmation pages must include the complete order summary for screen reader users
Need a WordPress accessibility audit or accessible site built?
Simple Automation Solutions performs WCAG 2.1 AA accessibility audits and builds accessible WordPress sites for organisations worldwide.
Frequently asked questions
What is the difference between WCAG 2.1 AA and WCAG 2.2?+
WCAG 2.1 (2018) is the current legal standard referenced in most accessibility laws and regulations. WCAG 2.2 (2023) adds nine new success criteria, primarily addressing cognitive accessibility and mobile usability. The new criteria include: visible focus indicators must meet minimum size and contrast requirements (Focus Appearance), authentication must not rely on cognitive function tests (Accessible Authentication), and redundant entry of previously submitted information must be avoided. WCAG 2.2 AA supersedes 2.1 AA — achieving 2.2 compliance requires meeting all 2.1 criteria plus the new ones. Most legal frameworks have not yet updated to require 2.2, but building to 2.2 standard is considered best practice for new projects.
Do I need to hire an accessibility specialist to make my WordPress site compliant?+
For most standard WordPress business sites, a systematic approach using WP Accessibility, Accessibility Checker, an accessible theme, and manual testing covers the majority of WCAG 2.1 AA requirements without specialist involvement. A specialist becomes valuable when: you have complex custom functionality (interactive data visualisations, custom web applications, document processing tools), you need formal certification or a Voluntary Product Accessibility Template (VPAT), you have received a formal accessibility complaint, or you are building for a sector with specific compliance requirements (US federal government, EU public sector). For standard marketing sites and e-commerce, the self-serve approach with the right plugins gets you most of the way there.
Can an accessibility overlay plugin get my site sued under the ADA?+
Several high-profile ADA lawsuits have targeted websites that used accessibility overlays while claiming compliance. The legal risk from overlays comes from the gap between the compliance claims some overlay providers make and the actual accessibility of the underlying site. An overlay does not make an inaccessible site accessible, and representing it as such may expose you to liability. The safer legal position is to invest in genuine code-level accessibility improvements rather than an overlay, and to maintain a good-faith documented effort toward WCAG compliance.
