Web accessibility issues are failures in a website’s code, design, or content that prevent people with disabilities from using it effectively. On WordPress sites specifically, the most common sources are themes that output inaccessible HTML, plugins that add unlabelled interactive elements, and Gutenberg blocks that omit ARIA attributes. This guide covers what those issues look like in practice, why they create legal exposure, and how to audit and maintain an accessible WordPress site.
According to the WebAIM Million 2025 report, 94.8% of the top one million home pages had detectable WCAG 2 failures, with an average of 51 distinct accessibility errors per page. WordPress sites are not exempt from this pattern.
Table of Contents
What WCAG Is and Why It Determines Your Legal Exposure
The Web Content Accessibility Guidelines (WCAG) are the internationally recognised technical standard for web accessibility, published by the W3C. WCAG 2.1 Level AA is the conformance target cited in most legal frameworks: the US ADA, the EU Web Accessibility Directive, and Section 508.
WCAG is organised around four principles, often abbreviated as POUR:
- Perceivable: Content must be presented in ways users can perceive, including text alternatives for images and captions for video.
- Operable: All functionality must work without a mouse. Keyboard navigation, sufficient time limits, and seizure-safe content are covered here.
- Understandable: Content must be readable and predictable. Error messages must explain what went wrong.
- Robust: Code must be written so assistive technologies (screen readers, switch devices) can interpret it reliably.
WCAG 2.1 has three conformance levels: A, AA, and AAA. Level AA is the legal standard in most jurisdictions. Level AAA is aspirational. Any WCAG audit of a WordPress site targets Level AA compliance.
The legal risk is measurable. According to UsableNet’s 2024 Year-End Report, approximately 4,000 ADA digital accessibility lawsuits were filed in 2024, with 41% of federal cases targeting companies that had already been sued before.
The Most Common Web Accessibility Issues Found on WordPress Sites
WordPress sites fail the same WCAG criteria repeatedly. The issues below are the most prevalent, ordered roughly by how often they appear on WordPress-built sites.
Low Color Contrast (WCAG 1.4.3)
Text must have a contrast ratio of at least 4.5:1 against its background for normal text, and 3:1 for large text (18pt+ or 14pt bold). Many WordPress themes ship with decorative font colors (light grey on white, muted pastels, transparent overlays) that fail this threshold.
The problem compounds with customisation: when a site owner changes a theme’s primary color via the Customizer or block styles, they often do not check whether the new color passes contrast requirements.
WooCommerce sites frequently fail on “Add to Cart” button hover states, placeholder text in checkout fields, and sale badge overlays on product images.
Missing or Inaccurate Alt Text (WCAG 1.1.1)
Images without alt text are invisible to screen readers. Images with alt text that says “image” or repeats the filename are worse: they announce noise instead of meaning.
On WordPress, the problem usually comes from three sources. Images uploaded without alt text in the Media Library carry no description forward when embedded in pages. Page builders and Gutenberg blocks that insert decorative images often omit the alt="" attribute entirely (empty alt tells screen readers to skip the image, which is correct for decorative images). And product photos in WooCommerce frequently lack meaningful descriptions because they were bulk-imported.
Keyboard Navigation Failures (WCAG 2.1.1)
Any interactive element (links, buttons, form fields, dropdown menus, modal dialogs) must be reachable and operable using a keyboard alone, without a mouse.
Common keyboard failures on WordPress sites include:
- Navigation menus built with CSS hover states that do not respond to focus
- Modal dialogs (cookie banners, popups, lightboxes) that trap keyboard focus or fail to return focus to the trigger element when closed
- Slider and carousel plugins that provide no keyboard control
- “Sticky” headers that cover focused elements when a user tabs through the page
Missing Form Labels (WCAG 1.3.1, 3.3.2)
Every form field must have a programmatically associated label: not just placeholder text that disappears when the user starts typing. Placeholder text alone is not a label.
WordPress contact plugins (Contact Form 7, Gravity Forms, WPForms) generate correct labels when configured properly, but it is easy to enable “placeholder only” mode or add custom fields without labels. WooCommerce checkout forms are a regular offender: first name, last name, email, and address fields often rely on placeholder text rather than visible labels.
Heading Hierarchy Errors (WCAG 1.3.1)
Screen reader users navigate pages by jumping between headings. A correct heading hierarchy (H1 → H2 → H3) creates a navigable structure. Skipping levels (H1 → H3 with no H2) or using headings purely for visual styling breaks that structure.
WordPress-specific heading problems are usually caused by themes that hardcode heading levels in templates without regard for page context, and Gutenberg’s heading block which lets editors choose any level without enforcement.
Links With Non-Descriptive Text (WCAG 2.4.6)
Links that say “click here”, “read more”, or “learn more” are unintelligible out of context. Screen reader users frequently navigate by pulling up a list of all links on a page. A list of ten “read more” links provides no information about where each one goes.
This is a content problem as much as a code problem. WordPress themes that use “Read More” buttons on blog archive pages, and editors who write inline links as “click here”, are the most common sources.
Missing Focus Indicators (WCAG 2.4.7)
When a user navigates with a keyboard, the focused element must have a visible outline. Many WordPress themes suppress the browser’s default focus outline with outline: none or outline: 0 in their CSS, because some designers consider it visually unattractive. This makes keyboard navigation impossible to follow visually.
Inaccessible Video and Audio Content (WCAG 1.2.2, 1.2.3)
Pre-recorded video with speech or meaningful audio must have captions. Pre-recorded audio-only content must have a transcript. YouTube and Vimeo embeds in WordPress do not automatically satisfy this: the captions must exist on the video itself, and the embed must not suppress caption controls.
How WordPress-Specific Factors Introduce Accessibility Failures
Generic accessibility guides describe what is broken. For WordPress site owners, it is equally important to understand why these failures appear so reliably.
Theme quality is inconsistent. Free and premium WordPress themes ship with HTML that often fails accessibility requirements out of the box: navigation menus lacking ARIA roles, images without alt attributes in template code, and headings assigned for visual weight rather than semantic structure. A theme that passes a design review may fail an accessibility audit.
Plugin output is not controlled by the theme. A contact form plugin, a slider, a cookie consent banner, and a WooCommerce checkout flow all inject their own HTML into the page. Each is a separate accessibility risk. The theme’s accessibility quality has no bearing on the accessibility of plugin-generated markup.
Gutenberg blocks vary in accessibility. Core Gutenberg blocks have improved significantly and generally produce accessible output. Third-party block plugins are inconsistent: some include ARIA attributes and keyboard handling; many do not. Every third-party block added to a site is a new point of potential failure.
Updates can break existing compliance. A plugin update may change its output HTML, removing ARIA labels, altering heading levels, or changing how interactive elements respond to keyboard events. A theme update may introduce new CSS that suppresses focus indicators. Accessibility is not a one-time fix: it requires monitoring after each update cycle.
This is why WordPress maintenance that includes post-update testing matters for sites with accessibility requirements. An update applied without a staging test and accessibility check can silently degrade compliance.
The Legal Case for Fixing Accessibility Issues
ADA Title III applies to websites of businesses operating in the United States as “places of public accommodation.” Courts have consistently held that this includes commercial websites, not just physical premises.
The practical consequence: businesses whose WordPress sites have significant WCAG failures are potential targets for demand letters and lawsuits. Litigation is concentrated in a small number of plaintiff law firms, and their methods are systematic: automated scanners identify failing sites, and demand letters follow.
The WCAG 2.1 Level AA standard is the compliance target referenced in most ADA website cases and in DOJ guidance published in 2022. EU businesses must also consider the European Accessibility Act (EAA), which requires WCAG 2.1 AA compliance for private-sector digital products and services by June 2025.
Neither the ADA nor the EAA requires perfection: they require good-faith effort toward a recognised standard and a process for receiving and addressing accessibility complaints.
How to Audit a WordPress Site for Accessibility Issues
A complete accessibility audit combines automated scanning with manual testing. Automated tools catch about 30-40% of WCAG failures. Manual testing catches the rest.
Automated tools for WordPress:
- WAVE (WebAIM): Browser extension and web tool that overlays accessibility errors, alerts, and structural information directly on the page. Clear visual output, useful for quick scans.
- Axe DevTools (Deque): Browser extension with high accuracy and low false positives. The free version covers the most common WCAG AA criteria.
- Lighthouse (Chrome DevTools): Built into Chrome; runs an accessibility audit alongside performance. Provides a score and specific failures with links to remediation guidance.
- Sa11y: A WordPress plugin that adds a real-time accessibility checker to the admin bar, visible in the editor and on the frontend.
Manual tests every site should pass:
- Tab through the entire page using only the keyboard. Every interactive element should be reachable and show a visible focus indicator.
- Zoom the browser to 200%. Content should reflow without horizontal scrolling or overlapping elements.
- Disable CSS and check that the page still has a logical reading order and meaningful heading structure.
- Check all images for meaningful alt text in the WordPress Media Library.
- Submit every form using keyboard only and check that error messages are clearly associated with the failing field.
A WordPress maintenance audit covers site health across security, performance, and technical quality. For sites with known accessibility concerns, a dedicated accessibility review should be added to the scope.
Accessibility Failures by WordPress Component
| Component | Common accessibility failures |
|---|---|
| Theme templates | Missing ARIA landmarks, hardcoded heading levels, suppressed focus indicators |
| Navigation menus | Dropdown menus keyboard-inaccessible, no ARIA expanded/collapsed state |
| Gutenberg blocks | Third-party blocks missing ARIA labels, non-sequential heading levels |
| Contact forms | Placeholder-only labels, no error association, missing required field indicators |
| WooCommerce checkout | Unlabelled fields, inaccessible error messages, missing focus management |
| Media embeds | Videos without captions, images with filename as alt text |
| Cookie/consent banners | Focus not trapped in modal, no keyboard close mechanism |
| Sliders and carousels | No keyboard controls, auto-play without pause mechanism |
Keeping Your WordPress Site Accessible Over Time
Accessibility compliance is not a project you complete and close. Plugin updates, theme changes, new content, and added functionality all introduce new risk. A site that passed an accessibility audit in January may fail several WCAG criteria by June if updates have been applied without post-deployment checks.
The practices that keep a WordPress site accessible over time:
Test after every update cycle. Run an automated scan after plugin and theme updates. The most common regressions appear in form fields, focus indicators, and navigation markup.
Write accessible content by default. Editorial guidelines should cover link text (no “click here”), image alt text requirements, and heading usage. Accessibility failures created by content editors are as real as those created by developers.
Use a theme that meets accessibility standards from the start. Look for themes listed under WordPress.org’s Accessibility Ready tag, or commission themes built to WCAG AA. Retrofitting an inaccessible theme is significantly more work than starting correctly.
Monitor after major plugin releases. WooCommerce, page builders, and contact form plugins all have histories of accessibility regressions in major releases. Treat accessibility as a post-update check item alongside functionality testing.
For sites where accessibility compliance is a business or legal requirement, WordPress support on retainer gives you engineers who can investigate and remediate regressions as they appear, rather than discovering them months later.
FAQ
What is the difference between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 was published in October 2023. It adds nine new success criteria to WCAG 2.1, mainly focused on cognitive accessibility and mobile usability (larger touch targets, help consistency, re-entering information). WCAG 2.1 Level AA remains the most commonly referenced legal standard in 2025. WCAG 2.2 AA is backwards compatible: a site that meets WCAG 2.2 AA also meets WCAG 2.1 AA.
Do I need a lawyer or a developer to fix accessibility issues?
Most WCAG failures are technical: code-level problems in HTML, CSS, and JavaScript. A WordPress developer with accessibility knowledge can fix the majority of common issues. Legal counsel becomes relevant if you have received a demand letter or if you are building a compliance programme that includes documentation and response procedures.
How long does it take to fix web accessibility issues on a WordPress site?
For a typical WordPress site with a standard theme and a small plugin stack, resolving the most common failures (color contrast, missing alt text, form labels, focus indicators) usually takes 8-16 hours of developer time. Sites with custom themes, large plugin stacks, or significant WooCommerce functionality take longer. A baseline audit before quoting remediation work gives a more accurate estimate.
Is WordPress inherently inaccessible?
No. WordPress core is developed with accessibility guidelines, and the Gutenberg editor has improved its accessibility significantly. The accessibility of a WordPress site depends primarily on the theme and plugins used. A well-built WordPress site on an accessibility-ready theme with carefully chosen plugins can meet WCAG 2.1 AA requirements. The problem is not WordPress itself but the ecosystem around it.
What is the quickest win for improving WordPress accessibility?
Color contrast is the most common failure and often the easiest to fix: update text and background colors in the theme’s style settings until the contrast ratio meets 4.5:1. After that, add alt text to all images in the Media Library. These two changes typically resolve the highest volume of WCAG failures on most WordPress sites.
Getting Your WordPress Site to a Defensible Accessibility Standard
Most WordPress sites have accessibility issues, and most of them are fixable with a focused audit and a planned remediation cycle. The risks of not addressing them (legal exposure, excluded users, and SEO impact from structural issues) are real and growing.
If you want to understand the current state of your site before planning remediation, a WordPress maintenance audit covers technical health across security, performance, and code quality, providing the baseline you need to scope accessibility work accurately.
