Making Your WordPress Website Accessible: The Technical Guide (2026)

WordPress is not accessible ‘out of the box’. Whilst the core team does its utmost to ensure the CMS complies with modern WCAG standards, as soon as you install your own theme, use a page builder or add plugins, the foundations often crumble.

The Accessibility Enhancement Act (BFSG) has been in force since mid-2025. An accessible – or at least largely accessible – website is no longer an optional quality feature, but a legal requirement for many web projects.

Key points at a glance

• Themes & Page Builders: Accessibility stands or falls on the code base. Modern Full Site Editing themes offer native, streamlined HTML5, whilst classic page builders often generate unstructured nested divs that block screen readers.
• HTML semantics & forms: HTML5 landmarks and a chronological heading hierarchy (H1–H6) form the backbone for screen readers. Forms require unique tags and text-based error messages.
• Keyboard navigation: The website must be fully navigable without a mouse. This requires visible focus rings in the CSS, functional skip links and effective focus management in mobile menus to prevent keyboard traps.
• Contrast & Media: Text contrast must comply with WCAG (at least 4.5:1). Images require contextual ALT text, videos require subtitles, and audio content requires a text transcript.
• Plugins & Overlays: Front-end widgets and code fixers improve usability, but they are not a cure-all. They can neither repair faulty theme code in the background nor replace editorial tasks such as image descriptions.
• Measurement & Testing: A reliable check combines automated tools (Lighthouse, WAVE) with manual checks and a self-assessment using a system screen reader.

The 4 pillars of accessibility

Accessibility isn’t achieved simply by installing a single plugin. It is the result of the interplay of four levels:

• The code level: This is all about clean, semantic HTML5. This includes functional landmarks, a chronological heading hierarchy (H1 to H6) and the correct programmatic linking of elements (e.g. in forms). This ensures that assistive technologies can interpret the page’s structure without error.
• The technical level: This level is based on the code and determines how the website behaves. The key requirement is that the entire website – including all forms, pop-ups and mobile menus – can be navigated using the keyboard without the need for a mouse.
• The design layer: This defines the global styles within the theme. This includes mathematically precise colour contrasts in accordance with WCAG guidelines, which remain consistent even when elements are hovered over or focused on, as well as flexible, infinitely scalable fonts and responsive layouts that do not break when zoomed in.
• The editorial level: This refers to the content-related work carried out in the WordPress editor. This includes adding contextual ALT text for images in the media library, providing subtitles and transcripts for videos and podcasts, and writing texts in accessible, clear language.

How a screen reader reads your website

A screen reader is a programme that reads out the content of a website to blind people or those with visual impairments. For this to work smoothly, your website’s code must be clearly structured.

Screen readers cannot see your CSS layout. They read the raw HTML code linearly from top to bottom and filter out the actual content for the user. If your code does not clearly define what, for example, the main navigation (<nav>) and the main content (<main>) are, a blind user will get lost on your page.

---

Roadmap: 6 steps to get started

If you want to make an existing WordPress site accessible, you’ll probably feel a bit overwhelmed at first. Don’t panic. Here’s how to get started:

Step 1: Setting objectives

Before you make any changes to your website, define your objective. Do you need to meet the strict requirements of the BFSG because, for example, you run a WooCommerce shop or a booking platform for end customers (B2C)? Or, as a purely B2B company, are you legally exempt and are you undertaking this project because inclusion is a quality feature for you?

Clarify this point first so that you can accurately assess the necessary budget and the scope of the measures required. If you are subject to legal requirements, your goal should be genuine WCAG compliance.

Step 2: Status Quo Check

Now it’s time to take stock. Run your homepage and your most important subpages through free tools such as Google Lighthouse (available directly in Chrome DevTools) or the WAVE extension. This will help you find out, for example, whether your grey text on a light grey background falls below the minimum contrast thresholds, or whether there are any links without recognisable text.

Step 3: Theme analysis

Check your website’s technical foundation. Is your current theme modern and does it support semantic HTML? Or are you using a severely outdated custom theme consisting of countless, unstructured <div> containers?

Example: If your old theme doesn’t support the basic HTML5 landmark roles (<header>, <main>, <nav>), manually retrofitting it often consumes a lot of resources. In this case, a complete switch to a modern FSE block theme (such as the free Twenty Twenty-Five theme) is usually the more cost-effective option.

Step 4: Low-hanging fruits

Now it’s time to get started. First, sort out the things you can do yourself as an editor in the WordPress backend.

• Organise the heading hierarchy (H1 to H6) in your posts in a logical way.
• Add any missing ALT text (image descriptions) to the media library.
• Use the global styles in your theme or page builder to increase the contrast between body text and buttons. If the testing tool from Step 2 indicates that your menu text is too pale, you can adjust the colour in the WordPress editor until the contrast ratio is correct.

It won’t cost you any of your development budget, but it will bring you significantly closer to your goal.

Step 5: More in-depth code optimisations

This is where most website operators need external help. It’s all about complex usability and semantics.

Example: Can a blind user open the drop-down menu on your website without using a mouse? Does the navigation work smoothly if you navigate through the page using only the Tab key? This is where developers need to step in to set focus rings via CSS or embed hidden ARIA labels in the code.

Step 6: Assistance tools & overlays

Once the foundations are in place in the code, you can maximise convenience for your users. This is where solutions such as accessibility widgets come into play. These overlays provide visitors with a visual interface through which they can increase contrast, enlarge fonts or stop animations. They are not a substitute for the code work carried out in step 5, but a useful addition to make usability customisable.

---

WordPress Themes & Page Builders

The theme forms the static and dynamic foundation of your accessibility. If the theme generates messy code, it doesn’t matter how many ALT texts you add in the WordPress editor – the page won’t pass the accessibility stress test.

The problem with traditional page builders: DOM bloat

To enable complex visual layouts using drag-and-drop, many popular page builders (such as Elementor or Divi) nest countless meaningless <div> containers within one another.

From a performance and SEO perspective, this unnecessarily inflates the DOM (Document Object Model) size. For a screen reader, this jumble of code is a nightmare: a <div> tag has no semantic meaning whatsoever. The software doesn’t know where the layout ends and the actual content begins. Furthermore, many older page builder modules fall short when it comes to native keyboard accessibility for complex elements such as sliders, accordions, or pop-ups.

The solution: Modern block themes (Full Site Editing)

When you’re setting up a new client project or planning a relaunch, you should opt for FSE (Full Site Editing) themes that are natively built on the WordPress Block Editor (Gutenberg). Modern FSE themes such as Ollie or the standard Twenty Twenty-Five theme are, by design, developed to comply very closely with the official W3C guidelines (WCAG).

Other themes, such as Kadence, Astra and Blocksy, also come with a wide range of built-in features designed to improve accessibility.

These modern themes do away with unnecessary code, use lean, semantic HTML5 and ensure that core functions such as the main navigation can be accessed and operated directly using the keyboard – without you having to write error-prone JavaScript workarounds./

---

Headings & Structure

A screen reader does not read a website the way the human eye does, which scans for patterns and font sizes. It operates within a linear framework. Blind users often start by having all the headings on a page listed so they can jump to where the desired information is located, just as they would in a book’s table of contents.

The <title tag: The first point of orientation

Before the content loads, the screen reader reads aloud the <title tag in the page header. This is the most important initial cue for the user to know which subpage they are on. Make sure your SEO plugins (such as Yoast or Rank Math) are configured to generate unique, descriptive titles (e.g., “Shopping Cart – Online Store” instead of just “Store”).

The logical heading hierarchy

The H structure (H1 to H6) is often misused to quickly impose a visual style (e.g. ‘Make the text a bit smaller – use an H3’). This is disastrous for accessibility.

• H1: Appears exactly once per page (the main heading).
• H2 to H6: Must be nested chronologically. An H2 must be followed by an H3, not an H4. If the design calls for a smaller font size, this is achieved using CSS, not the HTML structure.

Anchoring HTML5 landmark roles

To enable assistive technologies to understand the structure of a WordPress site, the key sections in the theme template must be wrapped in the appropriate HTML5 tags. Make sure your theme uses these landmarks:

<header> <!-- This is where the logo and the main navigation are located --> </header>
<nav aria-label="Main Menu"> <!-- The Navigationlinks --> </nav>
<main id="content"> <!-- The unique content of this specific page --> </main>
<footer> <!-- Privacy Policy, Legal Notice etc.--> </footer>

---

Keyboard navigation & menus

One of the key requirements of the Accessibility Enhancement Act (BFSG) is that the website must be fully operable without a mouse. This applies to people with visual impairments as well as users with motor disabilities.

The ‘Tab’ test for your website

Put your mouse aside and try navigating your WordPress website using only the Tab key (to move forwards) and Shift + Tab (to move backwards). Can you activate every link? Can you access the drop-down menu? If not, you need to take action.

The focus ring (:focus-visible)

When you navigate through a website using the Tab key, a visual border (the focus ring) shows where you are at that moment. Many web designers remove this border in CSS using `outline: none` for aesthetic reasons. This is a mistake.

Instead, use the :focus-visible pseudo-element to make the focus ring extremely visible to keyboard users, whilst keeping it invisible to those who use a mouse. Here’s how that looks in CSS:

/* Visible focus only for keyboard users */
button:focus-visible, 
a:focus-visible {
    outline: 3px solid #ff5a5f; /* eye-catching color matching the brand */
    outline-offset: 2px;
}

Set up skip links (jump marks)

Without assistive technology, a keyboard user must laboriously tab through all menu items every time they navigate to a new page before reaching the actual content. Skip links can help here. These are invisible links at the very top of the DOM that become visible only when the Tab key is pressed for the first time and jump directly to the <main> content.

HTML-Example:

<!-- Place immediately after the opening <body> tag -->
<a href="#content" class="skip-link">Jump to main content</a>

For this to work, the page’s main content element (usually the <main> tag or an enclosing <div> container) must have the appropriate ID: <main id=”content”>.

The CSS class skip-link ensures that the link is visually hidden but appears as soon as a keyboard user presses the Tab key (i.e. places the focus on it). Sighted mouse users will therefore not notice the link at all, whilst it becomes immediately accessible to screen readers and keyboard users. Some modern themes already use the `skip-link` class. If not, you’ll need to add the CSS to your style.css file:

/* visually move the skip link off the screen by default */
.skip-link {
    position: absolute;
    top: -1000px;
    left: 0;
    background: #000000; /* Your brand-color */
    color: #ffffff;
    padding: 15px;
    z-index: 99999; /* must be above the header */
    transition: top 0.2s ease;
}

/* Show the link immediately as soon as it receives focus via the keyboard (Tab) */
.skip-link:focus {
    top: 0;
}

Preventing keyboard traps in mobile menus

A common mistake with responsive WordPress themes: the user opens the mobile hamburger menu using the keyboard, but the focus remains trapped on the actual page in the background. Or worse still: they tab into the menu but can no longer tab out of it using the keyboard.

If you want to implement a modal window or a floating overlay menu in an accessible way, you need to ensure that three technical levels are covered in the code.

1. The basic HTML structure with ARIA attributes

For the background lock trick to work, the menu overlay and the actual content of the website must not be nested within one another. They must exist as separate blocks side by side (as so-called sibling elements).

In a classic WordPress theme, the streamlined structure looks like this in practice:

<!-- 1. SITE WRAPPER (in WordPress usually <div id="page">) -->
<div id="page-site-wrapper">
    
    <header id="masthead" class="site-header">
        <!-- Hier lebt dein normales Logo und die Desktop-Navigation -->
        
        <!-- TRIGGER-BUTTON (within the Header) -->
        <button id="menu-trigger-btn" aria-haspopup="true" aria-expanded="false" aria-controls="mobile-nav-container">
            <span class="screen-reader-text">Open menu</span>
            <!-- Your hamburger-icon (e.g., as an SVG) -->
        </button>
    </header>

    <main id="primary" class="site-main">
        <!-- Your actual content / blogposts / WooCommerce-Shop -->
    </main>

    <footer id="colophon" class="site-footer">
        <!-- Your Footer -->
    </footer>

</div> <!-- End of #page-site-wrapper -->


<!-- MOBILE MENU-OVERLAY (Has to be outside of the wrapper) -->
<div id="mobile-nav-container" role="dialog" aria-modal="true" class="mobile-menu-overlay">
    <nav aria-label="Mobile Navigation">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/shop">Shop</a></li>
            <li><a href="/contact">Contact</a></li>
        </ul>
    </nav>
    <!-- 4. CLOSE BUTTON -->
    <button id="menu-close-btn">Close menu</button>
</div>

The main wrapper (#page-site-wrapper) encloses your entire website—from the header through the content to the footer. This element already exists in almost every theme. Most often, it’s the <div id=”page”> at the very top of header.php, which isn’t closed until footer.php. You don’t need to recreate it; you just need to reference its ID in JavaScript. When the menu opens, the script sets the inert attribute on this wrapper. This freezes the rest of the website for keyboard users and screen readers.

The trigger button (#menu-trigger-btn) is the classic hamburger icon that opens the menu. The ARIA attribute `aria-haspopup=”true”` tells the screen reader that this button opens an interactive window. aria-expanded=”false” is set to true via JavaScript as soon as the menu is open, so that blind users know whether the menu is currently active. aria-controls refers precisely to the ID of the following menu container.

The menu container (#mobile-nav-container) is the actual mobile menu, which appears as an overlay on top of the page. This element must not be placed inside the main wrapper. This is because if you apply the `inert` attribute (the lock) to the main wrapper, the menu would otherwise freeze and become unresponsive. So place this container right at the bottom of your header.php, outside the wrapper, or load it directly via footer.php just before the closing -tag.

The ARIA attributes role=”dialog” and aria-modal=”true” indicate to assistive technologies that, from this point onwards, all interactions must take place solely within this window.

The Close button (#menu-close-btn) provides the user with a clear, keyboard-accessible way to close the menu. As soon as the user clicks the hamburger button, JavaScript immediately moves the invisible keyboard focus to this Close button. If the user presses the Escape key whilst in the menu or clicks this button, the menu closes and the focus returns smoothly to the hamburger icon.

2. The JavaScript for focus management and background locking

HTML alone is not enough to prevent this keyboard trap. We need script-based focus management that does three things: controls the state changes of the ARIA attributes, blocks the background from responding to clicks and tab key presses using the HTML ‘inert’ attribute, and cycles focus within the menu.

Add this script to the theme files on your WordPress site:

document.addEventListener('DOMContentLoaded', () => {
    const triggerBtn = document.getElementById('menu-trigger-btn');
    const closeBtn = document.getElementById('menu-close-btn');
    const menuContainer = document.getElementById('mobile-nav-container');
    // Here we use the standard WordPress ID “page” directly
    const siteWrapper = document.getElementById('page');

    // Gather all elements within the menu that can potentially be selected
    const focusableElementsString = 'button, [href], input, select, textarea, [tabindex]:not([-1])';
    
    function openMenu() {
        triggerBtn.setAttribute('aria-expanded', 'true');
        menuContainer.classList.add('is-active'); // Enables your visual CSS overlay
        
        // Lock the entire WordPress background (#page) for keyboard and mouse
        if (siteWrapper) siteWrapper.setAttribute('inert', '');
        
        // Set the focus immediately to the first item in the menu (the Close button)
        if (closeBtn) closeBtn.focus();
        
        // Enable event listeners for keyboard navigation
        menuContainer.addEventListener('keydown', trapFocus);
    }

    function closeMenu() {
        triggerBtn.setAttribute('aria-expanded', 'false');
        menuContainer.classList.remove('is-active');
        
        // Unlock the website background again
        if (siteWrapper) siteWrapper.removeAttribute('inert');
        
        // Focus must be returned to the original hamburger button
        triggerBtn.focus();
        
        // Remove the event listener
        menuContainer.removeEventListener('keydown', trapFocus);
    }

    function trapFocus(e) {
        // Enable closing the menu using the Escape key
        if (e.key === 'Escape') {
            closeMenu();
            return;
        }

        // We only respond to the Tab key
        if (e.key !== 'Tab') return;

        const focusableElements = menuContainer.querySelectorAll(focusableElementsString);
        if (focusableElements.length === 0) return;
        
        const firstFocusableElement = focusableElements[0];
        const lastFocusableElement = focusableElements[focusableElements.length - 1];

        if (e.shiftKey) { 
            // When Shift + Tab is pressed and we're at the beginning -> jump to the end
            if (document.activeElement === firstFocusableElement) {
                lastFocusableElement.focus();
                e.preventDefault();
            }
        } else { 
            // When the Tab key is pressed and we're at the end -> jump to the beginning
            if (document.activeElement === lastFocusableElement) {
                firstFocusableElement.focus();
                e.preventDefault();
            }
        }
    }

    // Register click events for the buttons
    if (triggerBtn && closeBtn && menuContainer) {
        triggerBtn.addEventListener('click', openMenu);
        closeBtn.addEventListener('click', closeMenu);
    }
});

Where is this integrated into WordPress?

As classic WordPress themes are organised hierarchically across different files, you need to place the code strategically:

• The trigger button (#menu-trigger-btn): This goes directly into the header.php file of your child theme, exactly where the mobile logo and navigation are located within your <header> tag.
• The menu container (#mobile-nav-container): As this element must be located outside the main wrapper (<div id=”page”>), it is best to place the entire HTML block for the overlay right at the bottom of footer.php – specifically, immediately after the closing </div> tag and just before the <?php wp_footer(); ?> tag.
• The JavaScript: Save the script as a separate file (e.g. accessibility-menu.js) in the /js/ folder of your child theme. Then include it in functions.php using wp_enqueue_script so that it loads efficiently in the footer.

If you’re using a modern block theme (Full Site Editing), WordPress’s native navigation block already handles this complex control fully automatically for you in the background. However, if your agency builds its own highly customised overlay menus using a page builder or custom blocks, this script is the most reliable way to ensure full compliance with the legal requirements of the BFSG.

---

Forms & interactive elements

Forms (contact forms, checkout processes, newsletter sign-ups) are one of the biggest barriers on the web.

Unique <label>-tags instead of placeholders

Some WordPress form plugins hide the label above the field and use only the ‘placeholder’ attribute within the field to create a ‘clean’ design. This is not accessible for two reasons:

1. As soon as the user starts typing, the placeholder disappears. People with cognitive impairments then often forget what they were actually supposed to type.
2. Many screen readers do not read out placeholders reliably.

Each input field requires a valid, programmatically linked <label>:

<label for="user-email">Your E-Mail</label>
<input id="user-email" type="email" required name="email">

Accessible error messages

If a user omits a mandatory field or enters an incorrect telephone number, the error message must not be indicated solely by the colour red (keyword: red-green colour blindness).

The error message must be written as text, contain an icon and be linked to the input field programmatically via the `aria-describedby` attribute, so that the screen reader reads out the error immediately when the user tabs into the field:

<input id="user-email" type="email" aria-describedby="error-email-msg">
<span id="error-email-msg" class="error-text">Please enter a valid email address.</span>

---

Colours and contrasts

Accessible design does not mean that your WordPress website has to be boring or black and white from now on. It means that visual information is presented in such a way that it remains legible even for people with visual impairments, colour blindness or simply when viewing it on a smartphone in direct sunlight.

The mathematical contrast ratio (WCAG guidelines)

The Web Content Accessibility Guidelines (WCAG 2.2) set out precise mathematical requirements for the contrast ratio between text colour (foreground) and background colour.

• Standard body text (AA standard): Requires a contrast ratio of at least 4.5:1.
• Large text (24px or above, or 19px in bold): Requires a ratio of at least 3:1.
• Graphical user interface elements (e.g. button borders, icons): These must also have a contrast ratio of 3:1 with the background.

How can I measure contrast?

You don’t need to estimate these values. There are tools that do this for you:

• Colour Contrast Analyser (CCA) by Vispero: A free desktop app for Windows and Mac. Using a digital pipette (eyedropper), you simply click on the text colour and background colour to get the result straight away. The tool is also used in the official BIK BITV test.
• WebAIM Contrast Checker: A minimalist and fast online tool. As well as a simple pass/fail result for AA and AAA, it features a lightness slider. If your colour combination just fails the test, you can darken or lighten the colour slightly directly within the tool until the contrast is correct, and then copy the new hex code.
• whocanuse.com: A web tool that, based on two colours you enter, breaks down both visually and as a percentage how people with different visual impairments see that combination. It simulates in real time on the screen how your text looks, for example, to someone with red-green colour blindness, low vision or cataracts. Perfect for showing clients in a meeting why the contrast needs to be adjusted.
• Browser extensions: There are a number of extensions available for Chrome and Firefox that show you the colour contrasts on your website. Not all of them work perfectly. We have tested WCAG Contrast Checker (Link to Chrome-Addon, Link to Firefox-Addon) and Colour Contrast Checker (Link to Chrome-Addon)
• Developer tools: Chrome and Firefox also offer the option to measure colour contrast via their developer tools or inspector, respectively.

Make sure that the colour contrasts remain consistent even in the :hover and :focus states. It’s no use if a menu item is perfectly legible in its resting state but turns into a low-contrast light grey when you hover over it with the mouse.

---

Images & Media

Gutenberg vs. Classic Editor (TinyMCE)

The modern Gutenberg editor manages media metadata much more effectively than the old Classic Editor. When you insert an image in the block editor, WordPress automatically retrieves the ALT text stored in the media library and embeds it in a semantically correct manner.

When does an image need ALT text?

ALT text is not a place for keyword stuffing; rather, it should describe the function or content of the image, e.g. “Bar chart showing a 10 per cent increase in sales in 2026”. The aim is to ensure that people with visual impairments can still understand the content of the image.

It’s a bit trickier with purely decorative images, such as stock photos, which are used purely as filler. If an image has no direct connection to the text, the alt attribute can be left blank (alt=””). However, it must still be present; it must not simply be omitted. This signals to the screen reader: ‘ignore this – the image is purely decorative’. 

However, it could also be argued that every image serves some purpose – why else would it be on the page? To ensure that blind people have the same experience as sighted people, the alt attribute should therefore be filled in. What the right approach is here is a matter of judgement – there is no single, 100% correct answer. We recommend consistently filling in the alt text everywhere.

Video and audio

Embedded videos (e.g. via YouTube or Vimeo) must have subtitles (for deaf people) and, ideally, audio description (for blind people). For audio-only content (such as podcasts on the blog), you must provide a full text transcript either directly below the player or as a link.

---

Accessibility Plug-ins & Widgets

Accessibility plug-ins and external widgets can speed up the technical implementation of accessibility. They either modify the source code directly, support content editors in the backend, or alter the visual presentation in the browser. The advent of Large Language Models (LLMs) and AI interfaces is opening up new possibilities – but fully automated accessibility solutions are still not available.

What plugins can handle fully automatically

These tasks relate to standardised protocols and technical attributes that must be embedded in the source code:

• Injecting missing code attributes: If the theme being used omits the HTML language attribute, plugins can add this globally in the header (e.g. <html lang=”de”>).
• Providing technical scripts: You can insert the necessary HTML and CSS structures for functional skip links at the top of the DOM tree.
• Remove redundant attributes: Automated deletion of disruptive ‘title’ attributes – which are often redundant or out of date for screen readers – from navigation links or image tags.
• Enforcing standard CSS declarations: Overriding theme styles to make a global focus ring (:focus-visible) visible for keyboard navigation.

Plugins and AI interfaces can help with this

The scope of services has changed dramatically here as a result of AI integration. Tools can partially automate these processes, but they usually require a final check by a human:

• Simple and accessible language: Plugins integrate specialised language models (e.g. from OpenAI) via APIs. These can translate complex technical texts or nested sentences directly within the WordPress editor into ‘simple language’ or ‘easy-to-read language’ at the click of a button.
• ALT text for images: AI extensions use image recognition algorithms to automatically generate WCAG-compliant descriptions upon upload. The limitation is that the specific editorial context (why this particular image appears in the article) must be checked by the editor.
• Subtitles for media: Integrated transcription tools can automatically analyse audio and video files and generate synchronised subtitle files (VTT/SRT). However, these must also be checked manually.
• Visual customisation on the user side: Front-end widgets provide visitors with controls to temporarily adjust contrast, colours and font sizes. This helps to flexibly cater for individual needs (e.g. optimised typefaces for people with dyslexia), but does not exempt the operator from providing a high-contrast standard design.

What plugins cannot do

Structural logic, ergonomic design and complex code architectures cannot be fixed with a plugin:

• Chaotic information architecture and menus: If the navigation is illogically nested, no plugin can effectively restructure the user experience.
• Poorly designed forms: layout errors, unclear field labels or confusing logical flows within forms require the form logic to be redesigned manually.
• Structural organisation of text: A plugin cannot correct haphazardly arranged headings (e.g. an H3 immediately following an H1) in the front end without disrupting the theme’s visual layout. Ensuring a logical structure remains an editorial responsibility when maintaining content.
• Faulty responsive design: If a theme cuts off elements or renders buttons unusable on mobile devices, this can only be fixed in the CSS or theme code.
• Replacing the design foundation: Contrast and readability should be accessible right from the core design (theme/CI). Technical overlays must not be used as a mere pretext for permanently ignoring a flawed default design in the source code.

Recommendations for plug-ins and tools by purpose

Technical Code Fixers (Background Optimisation)

These tools directly modify the front-end’s HTML output in order to compensate for structural shortcomings in the installed theme.

• WP Accessibility
  • Features: Inserts functional skip links and allows you to control the minimum visibility of the focus ring. It adds missing language tags to the HTML document and removes standardised title attributes from images and links. It also offers an option to force text links to display underlines.
• Ally – Web Accessibility & Usability
  • Features: Focuses primarily on making quick CSS adjustments to the website’s stylesheet, such as enforcing standardised outline borders for keyboard users. It also includes an optional, minimalist front-end menu that allows users to make basic adjustments to contrast and font sizes.

Back-end auditors & AI assistants (quality control)

These tools are used for internal quality assurance within the WordPress dashboard whilst creating content.

• Accessibility Checker (Equalize Digital)
  • Features: The plugin integrates with the Block Editor. It scans the post or page against the WCAG standards before publication. A report is displayed below the editor, highlighting specific errors such as incorrect heading hierarchies, insufficient colour contrast in the text or empty link text (“Find out more”).
• Easy Language (laolaweb)
  • Features: Enables the provision of content in simple or easy-to-read language. The plugin links the WordPress editor to AI services (OpenAI, SUMM AI or capito) to automatically simplify existing texts. Editors can manually edit the result. The output is displayed via a flexible language switcher on the front end.

Front-end widgets & overlays (user interfaces)

These JavaScript-based interfaces are superimposed as a visual layer over the fully rendered website and allow the end user to customise the display.

• iubenda Accessibility Widget (which we offer at Raidboxes as an optional add-on)
  • Features: It provides website visitors with an interface for customising the visual appearance. This includes the ability to scale text continuously, switch to high-contrast or monochrome colour schemes, and change the font (e.g. for people with dyslexia). In addition, animations, CSS transitions and automatic sliders can be paused globally via the menu to reduce cognitive load.
• UserWay Accessibility Widget
  • Features: Operates as a cloud-based JavaScript overlay with a similar set of features. It integrates into the user interface via an icon and provides visitors with tools to adjust contrast, text alignment, cursor size and keyboard navigation aids directly within the browser window.

Are plug-ins useful for accessibility?

Overlays and plugins can be useful tools for improving usability for the end user, providing AI-powered editorial assistance, or automating standard administrative tasks within the code.

However, they do not relieve web designers and developers of the obligation to programme the core architecture of the WordPress website – in particular the themes, the forms and the keyboard accessibility of the main menu – cleanly from the ground up. A widget optimises interaction on a functional basis, but cannot replace a technically flawed foundation.

---

Measuring digital accessibility: How to check your website

Code that is error-free in the editor does not, in itself, guarantee that it will be accessible in practice. A valid testing protocol therefore consists of three interlinked phases: the automated scan, the manual ‘do-it-yourself’ checks, and the final stress test using assistive technologies.

Step 1: Automatic scans

Automated tools detect mathematically quantifiable errors (such as colour contrasts) and syntactic errors in HTML code within a matter of seconds. They are the most efficient way to start any audit.

• Google Lighthouse (Chrome DevTools): Integrated directly into the Chrome browser (F12 -> Lighthouse tab). The accessibility score provides an initial guide, but only covers the user interface.
• WAVE Extension (WebAIM): Displays error icons directly within the rendered front-end. Ideal for visually identifying missing alt text or incorrect heading hierarchies.
• axe DevTools (Deque Systems): The engine behind axe checks more thoroughly than Lighthouse and provides detailed guidance for developers on how to fix ARIA errors.
• Siteimprove Accessibility Checker: A browser extension that categorises errors directly according to the WCAG compliance levels (A, AA, AAA) and provides targeted recommendations for agencies.

Step 2: Manual do-it-yourself rapid tests

Once the obvious code errors have been rectified, there follow four practical functional tests which do not require in-depth technical knowledge but reveal typical barriers encountered in everyday life.

The 200% zoom test

People with visual impairments use the browser zoom function to make text legible.

• The test: Press Ctrl + (or Cmd +) until the zoom level in the browser reaches 200% (for the AA standard) or 400% (for the mobile reflow standard).
• Points to bear in mind: The text must not overlap with other elements or images. A horizontal scroll bar must not appear at the bottom of the screen – instead, the website must transition smoothly to a single-column (essentially mobile) layout without any content being cut off.

Keyboard controls

Mouse-free operation is a key requirement.

• The test: Use the Tab key to navigate through the entire page without using the mouse.
• Things to look out for: Do I lose track of the focus ring from time to time? Do I end up in the cookie banner or the mobile menu, and can I close it again using the Enter or Escape keys? If the focus jumps around in the background whilst the menu is open, this is a keyboard trap.

AI-assisted checking for clear language

The readability of texts is part of cognitive accessibility (WCAG Criterion 3.1). Instead of costly expert reports, established language models (LLMs) can be used to carry out an initial text analysis.

• The test: Copy key text passages (e.g. from the checkout or service pages) and run them through an LLM using the following prompt: “Analyse the following text for accessibility according to the criteria for plain language. Identify nested clauses, passive constructions and unclear technical jargon. Suggest an optimised, accessible version that corresponds to language level B1.”

Simulation of refractive errors

Information should never be conveyed solely through colour.

• The test: Open your browser’s developer tools (usually by pressing F12 or right-clicking and selecting ‘Inspect’).
  • In Chromium-based browsers (Google Chrome, Microsoft Edge, Brave): Click on the three vertical dots in the top-right corner of DevTools, select ‘More tools’ – ‘Rendering’, and scroll down to the ‘Emulate vision deficiencies’ section. Alternatively, pressing Ctrl + Shift + P (Windows) or Cmd + Shift + P (Mac) opens the command menu, from which you can access the ‘Rendering’ option directly.
  • In Mozilla Firefox: Go directly to the Accessibility tab in DevTools. In the top menu bar of this section, you’ll find the ‘Simulate’ drop-down menu, which allows you to enable the visual filters directly.
• What to look out for: Switch the page to ‘Protanopia’ (red-green colour blindness) or ‘Achromatopsia’ (total colour blindness). Are error messages in forms, active menu items or links within the body text still clearly recognisable as such (e.g. through additional icons or underlining)?

Step 3: The perspective of those affected

The final test simulates actual use by blind or severely visually impaired people. Every modern operating system comes with the necessary tools for this as standard.

The 2-minute screen reader test

1. Preparation: Close your eyes or switch off the monitor temporarily.
2. Enabling: Launch the system screen reader. On macOS, this is VoiceOver (Cmd + F5); on Windows, it is the built-in speech synthesiser (Win + Ctrl + Enter). Alternatively, you can use the free NVDA tool.
3. Procedure: Try to carry out a specific action using only the keyboard and the screen reader’s audio prompts – for example, adding a product to your basket or filling in the contact form.

If, at any point, the screen reader fails to read out file names (e.g. for images without ALT text), cryptic character strings or simply nothing at all, this function is blocked for the users affected. These findings are fed directly back into the final code optimisation.

---

Common mistakes

‘Well-intentioned’ doesn’t always mean ‘well done’. Avoid these four classic mistakes in your day-to-day work with WordPress:

Mistake 1: Blind faith in ‘all-in-one’ repair plugins

Plugins that promise: “One click and your website is legally compliant and accessible” are lying to you. No plugin in the world can fix a logically incorrect nested heading structure or guess what’s in an image to generate ALT text. Such tools merely tinker with the symptoms; they don’t fix the broken code.

Mistake 2: Autoplay media and uncontrollable sliders

Autoplay videos, background music or carousel sliders that cannot be paused are not only a conversion killer for the user experience, but also an insurmountable barrier for people with cognitive impairments or screen reader users. Every moving element must have a clearly visible stop button that can be accessed via the keyboard.

Mistake 3: Conveying information solely through colour

“All mandatory fields are marked in red.” – A blind user or someone with severe red-green colour blindness simply cannot see this difference. Always use a combination of colour, text labels (“Error:”) and icons for success, warning or error messages.

Mistake 4: ‘Click here’ and ‘Find out more’ links

Screen reader users often make use of a function that displays all the links on a page as a list. If this list then consists of twenty instances of the text ‘Click here’, ‘Find out more’ or ‘Link’, it is completely useless. The link text must always be understandable in its own right and meaningful when taken in isolation.

• Incorrect: “To read our SEO guide, click [here].”
• Correct: “You can find further information in our [SEO guide to accessibility].”

---

FAQ: Frequently asked questions about WordPress and accessibility