♿ WordPress website accessibility: a complete guide 2026

When a user can't read your text, click a button, or simply understand where a link leads, they leave. Not because the content is bad. Because the site isn't speaking to them.

As of June 2025, the European Accessibility Act (EAA) became mandatory. In Germany, its national Barrierefreiheitsstärkungsgesetz (BFSG). Fines, compliance orders, lost audience. But behind the legal pressure lies a simple truth: according to the WHO, ~16% of people worldwide, one in six, live with some form of disability. Ignoring them means losing every sixth visitor.

WordPress is neither an exception nor a death sentence here. The CMS provides a solid foundation, but real accessibility is the result of deliberate actions by the developer or site owner. This guide is a step-by-step breakdown: from heading structure to keyboard navigation, from theme selection to automated checks. No fluff, only what you can apply today. 💡 Quick overview:

• Check perceivability: meaningful alt text for every image, aria-label for icons, clear anchor text for every link.
• Achieve a contrast ratio of 4.5:1 for normal text and 3:1 for large text using the WebAIM Contrast Checker.
• Build a heading hierarchy: one H1 per page, then H2 and H3 with no skipped levels.
• Ensure keyboard accessibility: everything clickable with a mouse must work via Tab and Enter.
• Check forms: an explicit label for every input field; a placeholder is not a substitute for a description.
• Run WAVE or Lighthouse: an automated audit will find most issues in half a minute.

What web accessibility is and why it's mandatory in 2026

Web accessibility is the practice of designing and developing websites that can be used by people with any physical and cognitive abilities. Screen readers for blind users, keyboard navigation for people with motor impairments, sufficient contrast for low-vision users, captions for deaf users.

The de facto standard is WCAG 2.2 (Web Content Accessibility Guidelines) from the W3C consortium. Three levels: A (minimum), AA (the target for most), and AAA (highest). EU and US legislation requires level AA.

The European Accessibility Act (EU Directive 2019/882) came into force on June 28, 2025, covering e-commerce, banking, transport, and media. In Germany, the BFSG applies in parallel. Fines vary: up to €100,000 in Germany, up to €250,000 in France. WordPress sites of commercial companies fall directly under the regulation.

Perceivability: how to make content understandable for screen readers

The starting point for accessibility: information must be presented so the user can perceive it through at least one channel: sight, hearing, touch.

Images and alt text. Every img tag must have an alt attribute. For meaningful images, a description of what's happening in them (5-8 words, without "picture" or "image"). For decorative images, alt="" (empty, but present). The screen reader skips an empty alt and doesn't distract the user.

1
/* functions.php — forced alt for post thumbnails */
2
add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3
    if (empty($attr['alt'])) {
4
        $attr['alt'] = get_the_title($attachment->ID);
5
    }
6
    return $attr;
7
}, 10, 2);

Empty links and buttons. A magnifying glass icon without text is a mystery to a screen reader. Always add aria-label to icon buttons:

1
<button aria-label="Open search">
2
    <span class="dashicons dashicons-search"></span>
3
</button>

Title attributes. Useful for additional context, but don't duplicate the link text in them; the screen reader will read the same thing twice. WordPress duplicates link text in the title by default; this should be disabled.

Color contrast: basic numbers and checking tools

Insufficient contrast between text and background is the most widespread problem. According to the WebAIM Million 2025, low contrast was found on 81% of scanned sites.

Minimum WCAG 2.2 AA requirements:

• Normal text (less than 18pt): contrast 4.5:1
• Large text (18pt and above or 14pt bold): contrast 3:1
• Icons and UI elements: contrast 3:1

Check it in a minute using the WebAIM Contrast Checker: enter the text and background colors in HEX and get a verdict: Pass / Fail for each level.

Typical problem areas in WordPress: gray text on a white background in the footer, light buttons with white labels, text over photos without a darkening overlay. Fixed by editing CSS, most often by darkening the text a couple of shades.

Heading structure: a hierarchy everyone understands

Screen readers build a "table of contents" for the page from headings; the user jumps through H2s and H3s, bypassing navigation. If the hierarchy is broken, navigation breaks.

Rules:

• One H1 per page, typically the post title
• H2 for main sections, H3 for subsections within an H2
• Headings don't skip: H2 → H4 (skipping H3) is an error
• Don't use h* tags just for font size; use CSS for that

A typical problem in WordPress: plugins and themes that insert H2/H3 for their own blocks (sliders with a heading, a subscription form, sidebar widgets). Three solutions: find the tag setting in the plugin, customize the output via a filter, or switch to a more careful plugin. Putting up with a broken hierarchy "because it looks nice" is not an option.

Navigation and landmarks: signposts for the screen reader

HTML5 landmarks give the screen reader a map of the page. Four key tags: header for the header, nav for navigation, main for the main content, and footer for the footer. The user presses a hotkey and jumps straight to the main content.

1
<header role="banner">
2
<nav role="navigation">
3
<main role="main">
4
<footer role="contentinfo">

The role="main" role must appear exactly once per page. Most modern WordPress themes use these tags out of the box; check with WAVE: the "Structure" section will show all landmarks.

Another required element, "Skip to Content", is an invisible link as the first element on the page that lets users jump past the menu and go straight to the content. In WordPress it is added via a filter or an accessibility plugin.

Forms without barriers

Contact form, newsletter signup, checkout: every field must be labeled and reachable via keyboard.

*Every input needs its own label (explicit or via aria-label):*

1
<label for="user-email">Email</label>
2
<input id="user-email" name="email" type="email">

A placeholder does not replace a label; it disappears on input and is poorly read by screen readers. Use placeholder only as a format hint, not as the field name.

Grouping: wrap radio buttons and checkboxes in a <fieldset> with a <legend>. Required fields: mark them with the text "(required)", not just an asterisk or color.

Keyboard navigation: your page without a mouse

Some users never use a mouse: tremor, spasticity, paralysis. Everything must work via Tab, Shift+Tab, Enter, Escape, and arrow keys.

Quick test: open the page and navigate it using only the Tab key. Every interactive element must receive a visible focus indicator. A modal must close on Escape. A dropdown menu must expand on Enter.

Typical WordPress site failures:

• Custom dropdowns without tabindex and aria-expanded
• outline: none in CSS (removes the focus indicator; don’t do this)
• Infinite focus trap in popups
• Sliders that are not keyboard-operable

Never disable the default :focus style entirely. If you dislike the browser outline, replace it with a custom :focus-visible style that has a high-contrast ring.

Zoom: don’t prevent users from enlarging text

Many mobile versions of WordPress sites block pinch-zoom via a meta tag:

1
<!-- INCORRECT — do not do this -->
2
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3
 
4
<!-- CORRECT -->
5
<meta name="viewport" content="width=device-width, initial-scale=1">

WCAG 2.2 requires the ability to zoom to 200% without loss of content or functionality; this is Success Criterion 1.4.4. Check that text does not get clipped or overlap other blocks when zoomed.

WordPress themes and accessibility: what to look for when choosing

No theme is "fully accessible out of the box", too much depends on content and settings. But the starting foundation matters.

When choosing a theme, pay attention to:

• The description says "accessibility ready", this is a tag on WordPress.org that means basic compliance with requirements
• Correct HTML5 structure with landmarks
• Navigation menus, native <nav> with <ul>, not a div construction with JS
• Presence of :focus styles for links and buttons
• Absence of maximum-scale=1.0 in the viewport

The standard WordPress themes (Twenty Twenty-Four, Twenty Twenty-Five) are a decent starting point. Commercial themes with visual builders are a risk zone: the more visual "magic", the higher the chance of broken accessibility.

Tools for auditing: from a quick check to professional testing

WAVE Evaluation Tool. A browser extension WAVE from WebAIM, it overlays icons directly on the page: red for errors, yellow for warnings, green for good. Ideal for a first audit. It shows contrast, alt texts, heading structure, ARIA attributes.

Google Lighthouse. Built into Chrome DevTools (F12 → Lighthouse → Accessibility). It gives a numeric score of 0-100 and a list of specific elements to fix. Convenient for regular monitoring.

Accessibility Checker (Equalize Digital). A WordPress plugin, Accessibility Checker checks content right in the editor (Gutenberg and Classic). The free version scans a post before publishing, Pro adds a full site audit.

WP Accessibility. A veteran among accessibility plugins, WP Accessibility by Joe Dolson. It adds skip links, ARIA landmarks, removes duplicate link title attributes, fixes :focus styles, removes tabindex from forms and target from links. Not a silver bullet, but it closes a dozen typical problems in one go.

One Click Accessibility. A plugin with a toolbar, One Click Accessibility lets the user switch contrast, increase font size, and underline links on their own. This is not a replacement for native accessibility, but an additional layer for those who need specific settings.

NVDA. A free screen reader for Windows, NVDA. Go through your site with the monitor turned off. You will hear what a blind user hears. VoiceOver (built into macOS/iOS) is the equivalent for the Apple ecosystem.

Ten steps to an accessible WordPress site

Here is the distilled takeaway from the whole guide, a checklist. Go through it after any redesign or new project launch.

• Write alt text for every image. In the WordPress media library, fill in the "Alternative Text" field. For decorative images, use alt="".

• Describe links. The link text should communicate where it leads. "Click here" and "Read more" are bad anchors. "Download the Accessibility Checker plugin" is a good one.

• Arrange headings in order. One H1, then H2, and H3 inside H2. Check in WAVE: Structure → Heading Outline.

• Bring contrast to 4.5:1. Run the WebAIM Contrast Checker over the theme's main colors: text, headings, buttons, links, footer.

• Enable visible focus. Make sure :focus is not set to outline: none without a replacement. Custom focus is done via :focus-visible.

• Check keyboard navigation. Tab through all links and buttons, Enter to activate, Escape to close modals. If you get stuck, that's a bug.

• Label forms. Every field needs its own <label>. Required fields need a text indicator. Groups go in a <fieldset>.

• Do not block zoom. Viewport without maximum-scale and user-scalable=no. Check at 200% zoom, content should not be cut off.

• Add a skip link. A "Skip to content" link as the first element of <body>. WP Accessibility does this automatically.

• Run WAVE or Lighthouse. An automated audit won't replace manual testing, but it will find the vast majority of problems in a minute.

⁉️🤔 Frequent questions

Does my WordPress site have to comply with WCAG?

If your site represents a business in the EU, yes, starting June 2025. The European Accessibility Act covers e-commerce, finance, transportation, and media. In the US, similar requirements apply: ADA + Section 508 for government agencies and their contractors. A personal blog is not formally required to comply, but a significant share of users have disabilities, a strong commercial argument.

Yes, commercial sites in the EU must comply with WCAG 2.2 AA starting June 28, 2025 under the European Accessibility Act. Fines are set by member states: amounts can reach hundreds of thousands of euros depending on the jurisdiction. In the US, similar requirements apply through the ADA and Section 508. For personal non-commercial blogs there is no legal obligation, but accessibility expands the audience.

Is installing a plugin like One Click Accessibility enough?

A toolbar plugin is an assistive layer, not a solution. It lets the user change contrast or font size, but it won't fix missing alt text, broken heading hierarchy, or keyboard-inaccessible popups. Start with native accessibility in code and content, add the toolbar as a final touch.

No. A toolbar (One Click Accessibility, UserWay) is only an additional "overlay." It does not replace native accessibility: it won't fix alt text, heading hierarchy, keyboard traps, or unlabeled form fields. Start by fixing code and content, the toolbar is the last touch.

How do I test a site without buying expensive tools?

A full cycle using free tools: WAVE Extension (first quick scan) → Google Lighthouse (numeric score + list of issues) → manual keyboard walkthrough (Tab/Enter/Escape) → NVDA on Windows or VoiceOver on Mac (go through the site with the monitor turned off). This is enough to address the vast majority of issues.

Free cycle: WAVE Extension for the browser → Google Lighthouse in Chrome DevTools → manual keyboard walkthrough → NVDA (Windows) or VoiceOver (macOS/iOS) for screen reader testing. These four tools cover 90% of tasks. Paid services are only needed for regular audits of large projects.

Can a site built with a visual builder (Elementor, WPBakery) be made accessible?

It can, but it's harder. Builders generate HTML dynamically, and some widgets break heading hierarchy or insert div wrappers without semantics. Check each block individually with WAVE. Elementor Pro version 3.15+ added aria attribute settings for widgets, use them.

It can, but it will require more manual work. Visual builders tend to break heading hierarchy and generate excessive div wrappers. Check the result with WAVE after every change. Elementor Pro (3.15+) lets you set ARIA attributes for widgets, which partially solves the problem.

How often should I recheck a site's accessibility?

After every significant update: a new theme, a new plugin, a redesign, a major content publication. Minimum cycle: run Lighthouse and walk through key pages with the keyboard once a quarter. Automated monitoring via Accessibility Checker Pro is justified for sites with regular content.

At a minimum, after every major change (theme switch, new plugin, redesign) and quarterly as a preventive measure. For sites with regular publications, automated monitoring via Accessibility Checker Pro is justified. A screen reader test is sufficient once every six months if the codebase hasn't changed.

What to do about WordPress site accessibility right now

Don't wait for the perfect moment. WCAG 2.2 AAA is a goal, not a starting point. Begin with three actions today:

• Run WAVE on your homepage. Fix the red errors (usually 5-10 of them), they close the most severe barriers.
• Navigate the site with a keyboard. Tab, Tab, Tab. If you get stuck, fix it. If focus isn't visible, add :focus-visible.
• Check the contrast of three colors: text color, button color, link color. Bring them up to 4.5:1.

These three steps, half an hour of work, and the lion's share of the result. The rest, plugins, screen readers, ARIA, tackle gradually.

If the site is commercial and operates in the EU, don't put it off. The EAA gives supervisory authorities real leverage starting in 2025. It's better to face an audit with a green Lighthouse score than with a letter from a regulator.