WordPress Website Accessibility Guide

In this article: This guide covers everything WordPress site owners and developers need to know about web accessibility — from what WCAG requires, to the most common barriers users encounter, to practical steps you can take today. Whether you’re starting from scratch or auditing an existing site, you’ll leave with a clear roadmap for building a more inclusive WordPress site.

Picture this: a potential customer lands on your WordPress site, ready to buy. They use a screen reader. Within seconds, they hit an unlabelled button, a form with no error messages, and images with no alt text. They leave. You never know it happened.

That is not a rare edge case. WebAIM’s 2024 Million report found WCAG failures on 95.9% of the top one million home pages tested, with an average of 56.8 distinct errors per page. These are not forgotten legacy sites — they are live, actively maintained websites just like yours.

WordPress powers roughly 43% of all websites globally, making it the single biggest lever for improving — or worsening — web accessibility at scale. And with the European Accessibility Act now in force as of June 2025, and ADA litigation in the United States reaching record federal filings, the window for treating accessibility as optional is closing fast.

For the estimated 1.3 billion people worldwide living with some form of disability — approximately 16% of the global population, according to the World Health Organization — an inaccessible WordPress site is not an inconvenience. It is a door slammed shut. This guide shows you how to open it.

---

What WordPress Website Accessibility Actually Means

Web accessibility is the practice of designing and building websites so that people with disabilities can perceive, understand, navigate, and interact with them. Disabilities relevant to web use include:

• Visual impairments — blindness, low vision, colour blindness
• Hearing impairments — deafness, hard of hearing
• Motor disabilities — limited hand mobility, tremor, paralysis
• Cognitive and learning differences — dyslexia, ADHD, memory impairment
• Photosensitive conditions — epilepsy triggered by flashing or rapidly animated content

The WCAG Standard Explained in Plain Language

The global technical standard is the Web Content Accessibility Guidelines (WCAG), published by the World Wide Web Consortium (W3C). WCAG is organised around four principles, abbreviated as POUR:

• Perceivable — content can be seen or heard by all users
• Operable — all functions can be reached with a keyboard or assistive technology
• Understandable — content and interface behaviour are clear and predictable
• Robust — content works reliably with current and future assistive technologies

WCAG defines three conformance levels: A (minimum), AA (the widely accepted legal benchmark), and AAA (enhanced). Most legal frameworks — including the ADA and the European Accessibility Act — reference WCAG 2.1 Level AA as the required standard.

WCAG 2.2, released in October 2023, strengthened requirements around focus visibility, dragging interactions, and mobile usability. It is increasingly referenced in updated legal guidance and procurement requirements. If you are starting a new build today, WCAG 2.2 AA should be your target.

What an Accessible WordPress Site Looks Like in Practice

Accessibility is not a binary state. A site can pass some criteria and fail badly on others. In practice, a meaningfully accessible WordPress site:

• Can be navigated entirely by keyboard, without requiring a mouse
• Has images with accurate, descriptive alt text
• Uses colour combinations with sufficient contrast for users with low vision or colour blindness
• Has forms with clearly associated labels and helpful error messages
• Presents content in a logical heading structure that screen readers can navigate
• Provides captions for video and transcripts for audio content

---

Why WordPress Accessibility Matters Right Now

Legal Requirements Are Tightening Across Every Major Market

In the United States, ADA Title III lawsuits targeting inaccessible websites have numbered in the thousands of federal filings annually for several consecutive years, and the trend is upward. In the European Union, the European Accessibility Act — which came into force in June 2025 — extends digital accessibility requirements to a broad range of private-sector businesses for the first time, covering e-commerce, banking, transport services, and more. In the UK, Public Sector Bodies Accessibility Regulations mandate WCAG 2.1 AA compliance for government websites, and that pressure is extending to suppliers and contractors.

The direction is consistent: accessibility is becoming a legal baseline, not an optional enhancement.

The Business Case Goes Well Beyond Legal Risk

The World Health Organization estimates over 1.3 billion people globally live with some form of disability. Many of them are your potential customers, readers, or users. An inaccessible site does not just exclude them — it signals they were not considered when the site was built.

Accessibility improvements also benefit everyone: cleaner heading structure improves search engine indexing, better colour contrast helps users reading in direct sunlight, and keyboard navigation improvements benefit power users who rarely reach for a mouse.

---

The Most Common Accessibility Failures on WordPress Sites

WebAIM’s Million report has tracked the same failure categories at the top of its findings for six consecutive years. Understanding these patterns is the most efficient way to prioritise where to start.

Missing or Inadequate Image Alt Text

Screen readers — software used by people who are blind or have low vision — read alt attributes aloud to describe images. When alt text is missing, auto-generated as a filename, or vague (“image1.jpg”), visually impaired users lose access to that content entirely.

Every meaningful image needs a descriptive alt attribute that conveys its purpose in context. Decorative images should use alt="" so screen readers skip them silently. This directly addresses WCAG 1.1.1 Non-text Content.

<!-- Avoid -->
<img src="team-photo.jpg" alt="photo">

<!-- Better -->
<img src="team-photo.jpg" alt="The AccessYes team gathered at our 2025 offsite in Edinburgh">

<!-- Decorative image — screen reader will skip this -->
<img src="divider-wave.svg" alt="">

Insufficient Colour Contrast

Low contrast between text and background is the single most frequently detected WCAG failure in WebAIM’s annual testing — present on 81% of home pages in the 2024 report.

WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). WCAG 2.2 further strengthened requirements around focus indicator contrast under criteria 1.4.11 and 2.4.11.

Audit body text, headings, links in all states (default, hover, focus, visited), button labels, placeholder text, and text overlaid on images using the WebAIM Contrast Checker.

Inaccessible Forms

Forms without visible labels, placeholder-only instructions, or unclear error messages create significant barriers for screen reader users and people with cognitive disabilities.

Every input needs a properly associated <label> — not just visually positioned nearby, but linked via the for/id pairing or aria-labelledby. Error messages must identify the specific field and explain what went wrong. This covers WCAG 1.3.1, 3.3.1, and 3.3.2.

<!-- Avoid — placeholder only, no label -->
<input type="email" placeholder="Email address">

<!-- Better — explicit label association -->
<label for="user-email">Email address</label>
<input type="email" id="user-email" name="email" autocomplete="email">

Broken or Invisible Keyboard Navigation

Every action on your site — clicking buttons, opening menus, submitting forms, playing media — must be reachable and operable using a keyboard alone. This matters for users with motor disabilities who cannot use a mouse, and for screen reader users who navigate sequentially through content.

Test it yourself: put your mouse aside and use Tab, Shift+Tab, Enter, Space, and arrow keys to navigate your site. Common failures include:

• No visible focus indicator showing which element is currently active
• Focus trapped inside a modal with no keyboard escape route
• Interactive elements that only respond to mouse click events
• No skip navigation link at the top of each page

WCAG 2.1.1 requires all functionality to be keyboard accessible. WCAG 2.4.11 (introduced in WCAG 2.2) requires that focus indicators are not entirely hidden by author styling.

Poor Heading Structure

Screen reader users navigate pages by jumping between headings — the same way a sighted user scans a page visually. When headings are chosen for their visual size rather than structural meaning, or when levels are skipped arbitrarily, the page becomes difficult to parse.

Rules to follow:

• One H1 per page, describing its main topic
• H2s for major sections
• H3s for subsections within those sections
• Never skip levels (for example, jumping from H2 directly to H4)

This relates to WCAG 1.3.1 and 2.4.6.

Inaccessible Video and Audio Content

Video without captions excludes deaf and hard-of-hearing users. Audio without a transcript does the same. Auto-generated captions from YouTube or similar platforms are a starting point but are rarely accurate enough to meet WCAG 1.2.2 without review — particularly for proper nouns, technical terms, or speakers with regional accents.

---

How to Audit Your WordPress Site for Accessibility

A thorough audit combines automated scanning with manual keyboard testing and screen reader review. No single method catches everything — automated tools reliably detect around 30–40% of WCAG failures. Manual testing is not optional.

Step 1: Run Automated Scans First

Use automated tools across a representative sample of pages: the home page, a standard content page, a blog post, a contact form page, and any custom template types.

Recommended tools:

• WAVE by WebAIM — browser extension and web tool with strong visual feedback on errors and structural features
• axe DevTools — browser extension with detailed per-issue WCAG references
• Lighthouse — built into Chrome DevTools, includes a scored accessibility audit alongside performance and SEO

Step 2: Test Keyboard Navigation Manually

Navigate your site using only Tab, Shift+Tab, Enter, Space, and arrow keys. Confirm that:

• Every interactive element receives a visible focus indicator
• Tab order follows a logical reading sequence
• No keyboard traps exist in any modal, dialog, or widget
• A skip navigation link appears at the top of each page

Step 3: Test With a Screen Reader

Testing with a screen reader gives you the closest approximation to a blind user’s experience. Start with one combination:

• NVDA (free, Windows) — use with Firefox or Chrome
• VoiceOver (built into macOS and iOS) — use with Safari
• TalkBack (built into Android)

Navigate using headings, landmarks, the links list, and form controls. Listen to how images are announced, how errors are communicated, and whether interactive components make sense without any visual context.

Step 4: Check Colour Contrast Systematically

Audit contrast across your full design system: body text, headings, links in all states, button labels, placeholder text, captions, and text over images. Pay particular attention to focus indicators, which have explicit contrast requirements under WCAG 2.2.

---

Practical Fixes for a More Accessible WordPress Site

Choose a Theme Built on Accessible Foundations

Your theme determines the structural baseline of your site. Look for themes that:

• Use semantic HTML5 elements (<nav>, <main>, <header>, <footer>, <article>)
• Have visible, high-contrast focus styles on all interactive elements
• Pass keyboard navigation tests out of the box
• Carry the accessibility-ready tag in the WordPress theme directory

The WordPress Theme Handbook accessibility requirements define what that tag should mean in practice.

Write Meaningful Link Text

Avoid links labelled “click here”, “read more”, or “learn more” in isolation. Screen reader users often pull up a list of all links on a page to navigate — so link text must make sense out of context:

<!-- Avoid -->
<a href="/guide">Click here</a> to read our accessibility guide.

<!-- Better -->
Read our <a href="/guide">complete WordPress accessibility guide</a>.

Use ARIA Landmarks Where Your Theme Falls Short

ARIA (Accessible Rich Internet Applications) landmarks help screen reader users understand and navigate page structure. If your theme does not already use semantic HTML5 elements for key regions, add ARIA landmark roles:

<div role="main">...</div>
<div role="navigation" aria-label="Primary navigation">...</div>
<div role="contentinfo">...</div>

Check first whether your theme already includes the corresponding semantic elements — duplicate landmark roles can cause confusion for screen reader users.

Use an Accessibility Plugin to Address Common Barriers Quickly

A plugin like AccessYes can address a range of common barriers — skip navigation links, focus management improvements, adjustable text size, and contrast settings — without requiring custom development work. This is especially useful while deeper structural fixes are still in progress.

---

Building Accessibility Into Your Ongoing WordPress Workflow

The most effective approach treats accessibility as a continuous practice, not a one-time audit. A single remediation sprint has a short shelf life — every new page, plugin update, or theme change can introduce new barriers if there is no process to catch them.

Here is what a sustainable accessibility workflow looks like in practice:

• Add accessibility criteria to your QA process — check every new page, post, or feature before it goes live, not after
• Train content editors to write meaningful alt text, use heading structure correctly, and choose accessible colour combinations from your design system
• Specify accessibility in design briefs — contrast ratios, focus states, and interaction patterns should be defined before development begins, not retrofitted after
• Schedule quarterly audits combining automated tools with keyboard and screen reader testing
• Gather feedback from users with disabilities — lived experience surfaces barriers that automated tools and sighted testers routinely miss

---

Your WordPress Accessibility Action Plan: Where to Start Today

Building a WCAG-compliant WordPress site is achievable for any team willing to approach it systematically. The key is prioritisation. Focus on the barriers that affect the most users first:

1. Run an automated audit using WAVE or axe DevTools across your most-visited page types
2. Fix the highest-impact issues first — alt text, colour contrast, form labels, and keyboard navigation account for the majority of failures detected in large-scale research
3. **Test manually