Whenever I’m asked to review a WordPress site, I almost always hear the same phrase up front: “We’re using an accessible theme and have installed an accessibility plugin, so we’re in the clear.” And yet, almost without fail, the site still fails the test. That’s because making WordPress accessible isn’t simply a matter of ticking a single box, but rather the interplay of four levels: theme, content, extensions and day-to-day operation. In this guide, I’ll show you at which of these levels digital accessibility fails in practice, which plugins really help, how you can test your site yourself, and why – particularly with WordPress – ‘done once’ never means ‘finished’. With code, a practical checklist and examples from real audits.
Making WordPress accessible in 7 steps<br/>
- Choose a well-maintained theme labelled ‘accessibility-ready’, or check your existing theme for focus, contrast and skip links.
- Mark up content neatly in the Block Editor: one h1, a complete hierarchy of subheadings, alt text, proper lists and tables.
- Check page builder elements such as menus, accordions, tabs and sliders for keyboard accessibility and ARIA compliance.
- Ensure forms and the checkout process have labelled fields and error messages in text form.
- Use an accessibility checking plugin for the editorial team, but do not regard an overlay as a solution.
- Test the site using a keyboard, a screen reader and a scanner.
- Publish the accessibility statement and monitor digital accessibility after every update.
Is WordPress accessible – or do you need to give it a helping hand?
WordPress is not automatically accessible – but it does provide you with a solid foundation. The project has its own accessibility team, and the WordPress core and admin area aim to comply with WCAG 2.2 at Level AA. Any new code added to the core must comply with these standards. However, this only means that the tool itself is accessible – not necessarily the site you build with it. Whether your website is ultimately digitally accessible depends on four factors, all of which you need to keep under control.
Anyone who works on just one of these four layers – usually the theme – and ignores the other three ends up building the typical WordPress site that fails an audit.
There’s no question in my mind that it’s worth the effort. If you make your WordPress site accessible, you’ll expand your potential audience, improve readability for search engines and, at the same time, meet the legal requirements that have applied to private companies since the BFSG came into force. The catch lies in the word ‘provided’: you’ll only reap these benefits if you tackle all four levels – a good theme on its own will negate them.
| Section | What is decided here | Most common pitfalls |
|---|---|---|
| 1. Theme | Basic framework: landmarks, keyboard focus, contrast, skip links | ‘Accessibility-ready’ is mistakenly regarded as a complete solution |
| 2. Content (Editor) | Semantics of headings, images, lists, links | The Block Editor is used purely as a design tool |
| 3. Builders & Plugins | ARIA for widgets, forms and additional functions | Page builder widgets without ARIA; overlays as a stopgap solution |
| 4. Day-to-day operations | Maintaining digital accessibility over time | “Once done” – updates break it without you noticing |
Layer 1: The right theme as a foundation
When setting up your WordPress site to be accessible, it all starts with the theme – it provides the basic framework, and this is where you should pay attention to the tag. Themes with this label are reviewed by the Theme Review Team and comply with the WordPress Accessibility Coding Standards – meaning they come with a clean heading structure (Criterion 1.3.1), sufficient contrast (1.4.3), visible focus indicators (2.4.7) and skip links (2.4.1) as standard. You can find these themes using the feature filter in the official directory. Modern block themes such as Twenty Twenty-Five include landmarks and accessible colour palettes as standard.
There are two things you need to know here. Firstly, the WordPress team has tightened the requirements for the 2026 badge. Theme authors were required to have their themes reviewed in accordance with the new rules by 30 September 2026; the original deadline was 30 June. Themes for which no new review has been requested have been disappearing from the filter since October. Therefore, do not blindly rely on an older ‘accessibility-ready’ theme; instead, check whether it is still being maintained and currently carries the label. Secondly, even the best theme has its limitations – in the Block Editor, you cannot assign semantic HTML5 elements such as or to individual elements, and with complex layouts you will need to take extra care anyway. The theme is the foundation, not the finished house.
A practical tip that will save you a lot of trouble later on: always make your own adjustments to the theme – such as tweaking contrast or focus styles – in a child theme and document them. Otherwise, the next theme update will wipe out all your painstakingly crafted digital accessibility work, and you’ll have to start all over again.
A real-life example: A medium-sized service provider had deliberately chosen a high-quality, accessibility-ready theme and was convinced that this meant they had done everything necessary. During the audit, the theme was indeed flawless – but the homepage consisted almost entirely of a page-builder layout that completely overrode the clean theme structure. The solid foundation was buried beneath a layer of non-semantic markup. A theme does not protect you from what you build on top of it.
Layer 2: Managing content correctly in the Block Editor
This is where most barriers arise in practice, particularly for people without a technical background. The Block Editor (Gutenberg) was built to make content more semantic – yet many use it as a design tool: they stack paragraph blocks on top of one another instead of using headings, insert lists as plain text, and create visual headings by simply formatting text in bold and large font. Visually, this looks neat. For a screen reader, however, it is a wall devoid of structure. This happens particularly frequently in blog posts and in WooCommerce product descriptions.
This difference determines whether blind users can skim through your page or not. A screen reader navigates via the heading structure – if this is missing, there is no sense of direction:
<!-- Falsch: sieht aus wie eine Überschrift, ist aber nur ein fetter Absatz -->
<p><strong>Unsere Leistungen</strong></p>
<!-- Richtig: echte Überschrift, die als Struktur erkannt wird -->
<h2>Unsere Leistungen</h2>The good news is that Gutenberg provides you with the tools to do this. Use exactly one for the page title and structure the rest seamlessly using and (Criteria 1.3.1 and 2.4.6). With modern block themes, the template often already specifies the page title as – in this case, do not add a second within the content, otherwise the page will have two. The Outline panel in the editor shows you the heading structure at a glance and immediately highlights any gaps. Also, ensure you provide meaningful alt text for every illustrative image (1.1.1), use descriptive link text instead of ‘click here’ (2.4.4) and format lists as proper list blocks. The same applies to data tables: use the table block with proper headers instead of recreating tables from individual column blocks – otherwise, a screen reader cannot establish the connection between a cell and its heading. This doesn’t cost any developer hours – just a bit of discipline on the part of the editorial team.
Even experienced editors can overlook a WordPress-specific pitfall when it comes to images: the alt text you enter in the Media Library is only a default – each image block has its own alt field, which overrides this default. If you insert the same image in two places, it may have meaningful alt text in one instance and none at all in the other. And for purely decorative images, the alt field should be left deliberately blank (Criterion 1.1.1) – rather than using the file name – so that a screen reader skips them instead of reading out ‘IMG_2024.jpg’.
Layer 3: Assessing Page Builder objectively
The third layer is the trickiest, because this is where two common misconceptions collide. The first concerns page builders. Tools such as Bricks generate clean HTML and allow you to assign the correct tag to each element – but their complex widgets are the weak point. Accordions, tabs and sliders often lack ARIA roles; buttons are rendered as <span> rather than as genuine button elements (a breach of 4.1.2 Name, Role, Value and 2.1.1 Keyboard Navigation); and forms lack grouping with <fieldset> and <legend> (1.3.1). A particularly common issue concerns custom-built menus: whilst the native WordPress menu provides keyboard navigation and aria-expanded for sub-menus, many page builder mega-menus create pure hover-based constructs that cannot be expanded via the keyboard at all. Such builders are powerful, but require a developer who is aware of the ARIA gaps and can address them.
<!-- Page-Builder-Falle: ein span als Schaltfläche, für Tastatur unerreichbar -->
<span class="btn" onclick="...">Jetzt anfragen</span>
<!-- Richtig: echtes button-Element, fokussierbar und vorlesbar -->
<button type="button">Jetzt anfragen</button>Plugins for digital accessibility in WordPress: what they can and cannot do
The most common question about WordPress and digital accessibility is: Which plugin will make my site compliant? The honest answer: none. Plugins are still useful, however, if you know what type you’re dealing with. I distinguish between three groups.
| Type | What they do | Examples | What they cannot do |
|---|---|---|---|
| Checking plugins | Show errors directly in the editor, often whilst you are writing | Accessibility Checker, Editoria11y, Sa11y | Fix errors themselves; fully detect keyboard and screen reader issues |
| Repair plugins | Fill individual technical gaps, such as skip links, focus frames and alt text fields | WP Accessibility | Fix structural errors in themes, page builders or forms |
| Overlays and toolbars | Display a menu across the page for contrast, font sizes or ‘AI repair’ | Various providers | Fix the code; on their own, these measures do not comply with the WCAG |
I recommend validation plugins for every editorial team. They catch precisely the errors that crop up in day-to-day work: missing alt text, missed heading levels, and links with no description. Repair plugins such as WP Accessibility are a useful tool – though the plugin itself makes it clear that it does not make your site compliant with any specific guidelines.
Overlay plugins – those toolbars that advertise ‘one-click accessibility’ or ‘AI-powered’ fixes and display a menu for contrast and font sizes – must be strictly distinguished from this. They do not fix the underlying code; they merely place a layer over it. They are rightly controversial amongst experts, and as a stand-alone measure they do not comply with WCAG. Nevertheless, I do not consider them fundamentally worthless – I judge them by what they claim to be. Such a toolbar can have its place if it is honestly labelled as a stopgap solution that does not fix the code; anyone who markets the same toolbar as fulfilling a requirement is simply shifting the problem onto the users. That is precisely the difference between an honest aid and a promise of a cure.
A real-life example: An online shop had installed an overlay plugin and, assuming this would ensure it was legally compliant, had taken no further action. During testing, a blind user was unable to proceed past the checkout stage: the form fields, built using a page builder, had no associated labels, and the overlay could do nothing to remedy this. The toolbar was visible, but the barrier remained. The shop fell under the scope of the BFSG and was vulnerable – despite the supposed protection.
Making WooCommerce and forms accessible
Anyone selling via WordPress is generally subject to the BFSG – which is why it’s worth taking a very close look here. Two areas deserve particular attention if you want to make your WordPress site accessible, as this is where business and accessibility intersect directly: WooCommerce shops and forms.
In WooCommerce, product descriptions are a notorious weak point because they are often maintained by different editors without a heading structure. Even more critical are product filters and the checkout process. Filters that can only be operated with a mouse, and payment forms without associated labels, exclude precisely those users who rely on a keyboard or screen reader – and this happens at the very point where they want to make a purchase. Every user excluded in this way represents a direct loss of revenue. The standard fields in the WooCommerce checkout are clearly labelled (3.3.2) and keyboard-accessible (2.1.1) – the problems almost always arise where a page builder or checkout plugin replaces these fields with its own, unlabelled versions. You should therefore specifically test the path a customer actually takes, not just a sample page. Product filters are the second pitfall: if they can only be dragged using the mouse, or if there is no feedback after filtering that a screen reader can read aloud (4.1.3 status messages), the filter remains unusable for some customers.
Forms are the second ongoing area for improvement. Whether it’s a contact, registration or order form: every field needs a visibly linked label (3.3.2), related fields should be grouped using and (1.3.1), and error messages must be displayed as text (3.3.1), not just as a red border. Many form plugins do not provide this by default. There are accessibility extensions available, such as for Contact Form 7 – but whether a form makes your WordPress site accessible is determined by the actual markup, not by the plugin’s claims. You should therefore always check the result yourself.
The WordPress Checklist for Digital Accessibility
This checklist summarises what you should check across all four layers. It is not a substitute for a full audit, but it does provide you with a reliable self-assessment tool for the most common sources of error.
| Area | What to check |
|---|---|
| Theme | Up-to-date accessibility-ready theme, visible keyboard focus, working skip link, sufficient contrast |
| Headings | Exactly one h1, a complete h2/h3 hierarchy with no gaps (use the Outline panel) |
| Images | Meaningful alt text for informative images; an empty alt attribute for purely decorative |
| forms | Visibly linked labels; use of `fieldset` and `legend` for groups; error messages in text form |
| Navigation | Fully keyboard-navigable, with `aria-expanded` on expandable menus, and focus always visible |
| Interactive blocks | Accordions, tabs and sliders with correct ARIA roles and keyboard navigation |
| Content | Descriptive link text instead of ‘click here’, proper list blocks, clear language |
| Media | Subtitles and transcripts for videos, no audio that plays automatically |
| Legal Information | Accessibility statement published and linked in the footer; feedback channel provided |
You can find the full checklist for each website in our checklist for accessible websites
Once you’ve worked through these points properly, you’ll be ahead of the vast majority of WordPress sites. But – and this is the crucial catch – you won’t be done with it for good.
How to test your WordPress site yourself
You can get an initial assessment in half an hour, without needing any specialist knowledge.
- Keyboard test: Put your mouse aside and use the Tab key to navigate through the home page, the menu, a form and the checkout. Can you always see where you are? Does the menu open? Can you find your way out of every section?
- Screen reader test: On Windows, use the free NVDA; on a Mac, use the built-in VoiceOver. Listen to a page and use the H key to navigate through the headings. Ourguide to screen readers explains how these programmes work.
- Automatic scan: Access Score checks your page for compliance with WCAG 2.2 free of charge and explains the findings in an easy-to-understand way. Browser extensions such as WAVE or axe DevTools can help with individual pages.
- Contrast: With Access Contrast, you can check your brand colours against the WCAG guidelines and receive a suggested correction for each colour pair.
An automated scan only detects some of the WCAG criteria. Only by testing with real users of assistive technologies can you determine whether a person using a screen reader can actually complete your checkout process – this is how we test at Access Ready.
WordPress and the BFSG: What else you need
It is not the system but your website’s content that determines whether your WordPress site falls under the Accessibility Enhancement Act. Anyone offering online contracts to consumers – for example, via WooCommerce, a booking form or a customer portal – will generally be affected from 28 June 2025. Our guide to the obligations for websites explains exactly who is subject to these requirements.
In addition to the technical implementation, the law requires an accessibility statement: this describes the extent to which your website meets the requirements, what barriers still exist, and how users can report them. A template text is not sufficient for this, as the statement must be based on an actual assessment. Access Declare generates it based on a full scan of your website. You can find out which details are mandatory in our guide to mandatory content.
Retrofitting or waiting for a relaunch? The right time
A question I’m often asked: is it worth retrofitting an existing website, or is it better to wait for the next relaunch? The honest answer depends on the state of your website – but one principle always applies: the sooner accessibility is taken into account, the cheaper it is.
If a relaunch is on the cards anyway, this is by far the best time to make WordPress accessible. A theme designed to be accessible from the outset, a clean block structure and accessible forms involve only a minimal amount of extra work when building a new site, compared to a standard relaunch. Implementing these features retrospectively into an established site, however, becomes significantly more expensive, as you’ll have to dismantle existing content, layouts and plugin configurations.
Just because a relaunch isn’t on the cards doesn’t mean you should wait – the BFSG has been in force since June 2025, and inaction is not an option. The pragmatic approach, then, is to tackle the most significant barriers first, maintain your content properly from now on, and develop your WordPress site to be accessible in stages. Start with the pages that drive your actual business – the homepage, contact page and checkout – rather than the blog archive from 2018. The key is to get started and not leave progress to chance.
Why ‘doing it once’ isn’t enough with WordPress
WordPress is a living system, and that is precisely what makes accessibility an ongoing task. Every theme update, every plugin update, every new blog post and every new product page can introduce a barrier that wasn’t there yesterday. A plugin update might alter a form’s markup; a new member of staff might edit a page without using a heading structure; or a theme change might inadvertently remove the skip link. Experts therefore strongly recommend retesting critical processes such as registration, checkout and booking after every update.
In reality, nobody does this manually – an active WordPress site changes too frequently for that. A one-off audit describes a state that may already be out of date by the time of the next deployment. This is where our Access Guard monitoring comes in: it automatically checks your site after every update and deployment, reports new barriers in real time directly to your tools such as Slack or Jira, and provides ready-to-use code snippets to fix the issue. A one-off scan won’t detect the breach – you’ll only find out about it when a user complains or a warning notice arrives. Access Guard detects it on the day of deployment and keeps you in the loop, rather than leaving you to deal with it on your own.
For a platform that changes with every plugin and every post, this is the only realistic way to keep WordPress accessible: not a state that you achieve once and for all, but a process that is continuously safeguarded through monitoring. Access Guard thus transforms accessibility from a project with an end date into a reliable operational state – and that is precisely what distinguishes a site that passes an audit from one that will still do so a year from now.
A real-life example: An agency had built an exemplary, accessible WordPress site for its client and the site had been signed off correctly. Four months later, a user reported that the main navigation was no longer working via the keyboard. The cause was an automatic update to the menu plugin, which had altered the keyboard navigation logic. Nobody had noticed because nobody had tested the site after the update. With proper monitoring, the error would have been spotted on the same day – as it was, the site remained in the red zone for months.
Are you planning a relaunch or looking to improve your existing website? In 30 minutes, we’ll discuss where the biggest barriers lie and how you can overcome them.
Frequently asked questions about WordPress and the BFSG
Does my WordPress website have to be accessible under the BFSG?
This is not determined by the system, but by the nature of your business. From 28 June 2025, the Accessibility Enhancement Act will apply to businesses that offer certain products and services to consumers, such as in e-commerce, banking or telecommunications. Anyone who concludes contracts with consumers via their WordPress website – for example, via WooCommerce or a booking form – is generally affected. Micro-enterprises with fewer than ten employees and an annual turnover or balance sheet total of no more than two million euros are exempt, provided they provide services.
Is there a WordPress plugin that makes my site BFSG-compliant?
No. Reputable plugins resolve individual issues, such as missing skip links or invisible focus frames. However, the theme, content, page builder widgets and forms must still be accessible in their own right. Overlay widgets that promise compliance at the click of a button do not alter the source code: the barriers for screen readers and keyboard navigation remain.
Is Elementor accessible?
Elementor can be used in an accessible way, but the result depends on how the page is built. Typical weak points include mega menus, sliders and accordions without correct ARIA attributes, as well as headings whose level has been chosen based on appearance rather than structure. Every Elementor page should therefore be tested using a keyboard and a screen reader, not just a scanner.
How much does it cost to make a WordPress website accessible?
That depends on the initial state of the site. A clean theme with few forms can be adapted quickly, whilst an online shop that has grown over the years with many extensions will require more effort. You can get an initial overview free of charge with Access Score; you’ll find realistic budget estimates in our article on the costs of an accessible website.
How often should I check my WordPress site?
After every major update to the theme, page builder or plugins, and whenever new forms or shop features are added. As hardly anyone can manage this manually on a day-to-day basis, Access Guard continuously monitors your site and reports any new barriers as soon as they arise.
Which WordPress theme is accessible?
In the official directory, look out for the ‘accessibility-ready’ label and ensure that the theme is actively maintained. WordPress’s default themes, such as Twenty Twenty-Five, provide a solid foundation. However, a theme alone does not make your site accessible – content, plugins and forms also play a key role.
Is WooCommerce accessible?
The standard fields in the WooCommerce checkout are clearly labelled and can be navigated using a keyboard. Problems usually arise where page builders, checkout plugins or product filters replace or extend these fields. You should therefore check the actual path your customers take, from the product to the order confirmation.
Do I need an accessibility statement for my WordPress site?
Yes, if your site falls under the BFSG. The statement must be based on a genuine audit and updated regularly. Access Declare generates it from a full scan of your site.
Our article on accessible web design shows how these requirements can be taken into account right from the design stage.
From a one-off conversion to ongoing compliance
Making your WordPress site accessible therefore involves two tasks in one: the one-off implementation across all four layers and the ongoing maintenance during normal operation. You can complete the first step using this guide and a professional audit. The second step cannot be carried out reliably by hand.
If you want to know where your website stands today, a free WCAG quick test with Access Score is the right place to start – it shows you the automatically detectable issues in plain language. For robust evidence, you’ll then need a human-led in-depth audit such as Access Ready, as an automated scan only detects some of the WCAG criteria. And to ensure your site remains accessible even after the next update, Access Guard – a continuous accessibility monitoring service for WordPress – is the honest solution for a system that is constantly changing. I’m not promising you a perfect site at the touch of a button – but rather a process that begins with diagnosis and leads to long-term protection.
