In October 2025, OpenAI launched its own browser, ChatGPT Atlas. The announcement included a sentence that really ought to feature in every digital accessibility guide: website operators can add ARIA attributes to help the ChatGPT agent better understand their site. ARIA – that is precisely the technology we have been using for years to ensure that screen readers can read out a website in a way that is understandable. To me, this single sentence shows that the debate on AI and digital accessibility is currently taking a new turn.
Up until now, the question has simply been: Can AI make our website accessible? Now, a second question has emerged, and, to be honest, for many companies this is the more important one: Can AI even use our website? In this guide, I’ll show you both sides: what AI is actually capable of today when it comes to identifying and removing barriers, and where it reliably falls short. And I’ll show you why an accessible website is becoming the key to opening the door for AI agents.
How AI is really changing digital accessibility
In short: AI speeds up work on digital accessibility, but does not make it redundant. It identifies errors on a large scale, suggests alternative text, structures PDFs and simplifies texts. What it cannot do is assess whether a person using a screen reader, keyboard or screen magnifier will actually be able to complete your ordering process. Yet it is precisely this question that determines whether your website meets the requirements of the BFSG and BITV 2.0. That is why, at ifdb, we use AI-supported methods combined with human verification – for example, in our in-depth ‘Access Ready’ audit. In this process, real users of assistive technologies have the final say. I explain how to create accessible PDFs from the outset in ‘Creating Accessible PDFs’.
Two approaches: AI for accessibility and accessibility for AI
When people talk about AI and digital accessibility, they usually mean only the first aspect: AI as a tool that identifies and removes barriers. The second aspect has only recently come to light, and it is the real ‘aha’ moment. AI agents that carry out research for your customers, fill in forms or place orders actually need exactly the same information that a screen reader requires. That means unambiguous labels, genuine buttons and a clear structure.
Conversely, this means that a website which a blind person cannot use is very likely to be difficult for an AI agent to use as well. Digital accessibility is therefore no longer merely an obligation and a social responsibility, but quite simply a technical prerequisite for your offering to be available on the next channel at all.
How AI agents read your website: the Accessibility Tree
Every browser creates a second, invisible version of the page from your HTML: the accessibility tree. This tree specifies, for each element, what it is, what it is called and what its state is – for example, ‘Button, Add to basket, active’. Screen readers read out this very tree. I have explained in detail how it is created and why CSS does not affect it in my post on the accessibility tree.
What is new is that AI tools also use this tree. Microsoft, for example, explicitly states in its documentation for Playwright MCP – a widely used tool that enables AI models to control browsers – that it works with snapshots of the Accessibility Tree rather than screenshots. And OpenAI notes in its documentation for Atlas that the agent uses ARIA to understand the structure and controls of a page. A button that is, in reality, a div with no role and no name remains invisible to both – to the screen reader as well as to the agent.
Why using more ARIA is still not the solution
Now, one might be tempted to lavish the website with ARIA attributes so that AI can understand it better. I can only warn against doing this. There’s a good reason why the first rule of ARIA is: wherever there’s a suitable native HTML element, use that one. A genuine button element comes with role, keyboard navigation and focus by default, whereas a div element that’s been labelled retrospectively does not.
Following the Atlas announcement, accessibility expert Adrian Roselli was right to warn that ARIA attributes would soon be crammed full of keywords. This would be disastrous for people using screen readers, as they would hear each of these words read out. The good news is that whatever helps a screen reader also helps the agent. If you write clean, semantic HTML, you don’t need to build anything extra for AI. You can find out when ARIA is useful and when it does more harm than good in the guide to aria-label and WAI-ARIA.
What AI is capable of in assessment today
When it comes to quality assurance, AI really comes into its own where volume is concerned. AI-powered scanners can process thousands of pages in a short space of time, group similar errors together and identify which template in the CMS is causing them. Instead of 4,000 individual error reports, you’ll then see, for example, that a single product card template is causing the same missing link name to appear on all category pages.
AI is also helpful when it comes to prioritising and explaining issues. It translates an error message such as ‘4.1.2 Name, role, value not met’ into a clear task for the editorial or development team. You can get an initial overview of your website free of charge with Access Score, which shows you where the measurable gaps lie in just a few minutes.
The 30 to 40 per cent threshold – and why AI doesn’t simply shift it
In practice, automated tests only detect around 30 to 40 per cent of requirements. Many hope that AI will soon push this limit higher. To a certain extent, it will do so, as image recognition and language models are now capable of evaluating things that traditional rules fail to cover. However, the bulk of the gap is not a technical problem, but an information problem.
Whether an image is decorative or conveys a message does not lie in the image itself, but in the intention of the person who included it. Whether an error message is understandable is determined in the user’s mind. And whether a checkout process works seamlessly with a keyboard and screen reader only becomes apparent when someone actually uses it in that way. This information is not contained in the code. That is why even the best AI cannot extract it from the code.
The blind spot in automated testing: states and processes
A second reason for this limitation is often overlooked: scanners usually check the state of the page as it loads. However, barriers often only arise afterwards: when a menu drops down or a dialogue box opens, when an error message appears after submission, or when the shopping basket updates without reloading. Whether the focus remains in an open dialogue box and returns to the correct position after it is closed (2.4.3 Focus Order) can only be seen by running through the process. The same applies to the question of whether a new message is announced (4.1.3 Status Messages).
Modern online shops and customer portals built as single-page applications consist almost entirely of such states. AI agents that navigate through processes on their own are certainly improving in this regard. However, whether a voice prompt reaches a blind person at the right moment and is understandable remains a question that needs to be clarified with real users.
Alternative texts: Where AI helps and where it gets it wrong
When it comes to alternative text in accordance with WCAG 1.1.1 (non-text content), AI has now become remarkably good at describing what can be seen in a photograph. However, that is often not what is required at all. A team photo on the careers page might need the description ‘Our sales team at the Munich office’, whereas a purely decorative background image, on the other hand, needs an empty alt="" so that the screen reader skips it. An AI that describes every image in detail therefore tends to make the page longer rather than better for screen reader users.
The situation becomes even more tricky when it comes to images that serve as links. In such cases, the alternative text must describe the link’s destination (2.4.4 Link Purpose), not the image’s content. Furthermore, in accordance with 1.4.5 (Images of Text), images containing embedded text should, where possible, not be presented as images at all. Our guide to alternative text shows what good alternative text looks like.
Practical tip: Don’t let AI describe first; let it decide first. Provide the tool with the surrounding text and the purpose of the image, and ask: Is this image decorative, informative or a link? Only then should it generate the text. In many cases, an empty ‘alt’ attribute is the correct answer – and that is precisely what AI almost never provides on its own.
PDFs and documents: AI-assisted tagging, human verification
AI has a particularly significant impact when it comes to documents. An accessible PDF in accordance with PDF/UA (ISO 14289) requires tags for headings, lists, tables and images, a logical reading order and alternative text. Doing this manually for hundreds of annual reports, forms or contracts would take weeks. Today, AI can recognise the structure of a page in seconds, thereby laying a very solid foundation.
However, a large proportion of the test criteria set out in the Matterhorn Protocol, which is used to test PDF/UA compliance, can only be assessed by a human. Is the reading order logical? Does a table header really describe the correct columns? Does the alternative text fit the context? This is precisely why a human must always be involved in the testing of accessible PDFs. You can find out more about the requirements in the guide to accessible PDFs.
Comprehensible texts and plain language using AI
Language models are excellent at simplifying complex texts. For plain language – that is, shorter sentences, fewer technical terms and a clear structure – a good AI draft with an editorial review is often sufficient. With ‘easy language’, however, it is different. It follows its own fixed rules and is aimed at people with learning difficulties. According to the rules of the ‘Easy Language’ network, every text must be checked by people from precisely this target group.
AI can significantly speed up this process, but it cannot replace it. Anyone who publishes an AI-generated text as ‘plain language’ without checking it risks producing texts that appear simple in form but are factually inaccurate or simply incomprehensible. For public authorities required to provide information in plain language under BITV 2.0, this is no minor issue.
Where AI really takes the strain off newsrooms in their day-to-day work
People underestimate just how much AI can help with the small, repetitive tasks in the editorial department. ‘Click here’ becomes link text that specifies the destination (2.4.4 Link purpose). A meaningless subheading is transformed into one that describes the section (2.4.6 Headings and captions). And ‘Invalid input’ becomes an error message that explains what needs to be corrected (3.3.3 Error recommendation).
However, the key lies in how you phrase the question. “Make the text accessible” usually results in vague generalities. A specific task with context works better, such as: “Rewrite these three link texts so that they make sense without the surrounding sentence, and state the destination of each page.” The result is then checked by a human – in a fraction of the time it would have taken to write it.
Code corrections using AI: faster, but with side effects
Many development teams now rely on Copilot or ChatGPT to fix accessibility errors. Whilst this saves time, it creates a whole new category of errors: corrections that satisfy the scanner but create new barriers for people. A typical example:
<!-- KI-Vorschlag: Scanner meldet keinen Fehler mehr -->
<button aria-label="Formular absenden">Jetzt kaufen</button>
<!-- Besser: sichtbarer Text und zugänglicher Name stimmen überein -->
<button>Jetzt kaufen</button>Although the first button now has a name, the screen reader reads out “Submit form”, whilst the screen displays “Buy now”. This contravenes 2.5.3 (labelling in the name) and makes voice control impossible, as anyone who says “Click Buy now” will not select the button. Equally common are instances of role="button" on elements that cannot be accessed via the keyboard at all (2.1.1 Keyboard), or aria-hidden="true" on elements that receive focus. No screen reader reliably flags all these cases – a person using a keyboard will notice them immediately.
AI-powered overlays: a promise that falls short
This limitation is most evident in the case of overlay widgets, which are superimposed on a website via script and are designed to automatically remove barriers ‘using AI’. They do not alter the source code, but instead attempt to correct the display in the browser retrospectively. This is generally insufficient for screen readers, keyboard navigation and forms, and certainly not for AI agents that read the actual code.
The US Federal Trade Commission (FTC) made it clear in April 2025 that this claim has no legal basis. It ordered an overlay provider to pay one million US dollars for advertising that its tool made websites WCAG-compliant. I have explained why overlays do not offer protection under the BFSG either in my article on the limitations of overlays.
A comparison of AI approaches
The following overview categorises the common approaches according to what ultimately matters. Our own approach is clearly labelled as ‘ifdb’.
| Approach | Finds a large number of errors | Fixes in the source code | Checks usability with assistive technologies | Provides robust evidence |
|---|---|---|---|---|
| AI scanner only | yes | no | no | no |
| KI-Overlay | in some cases | no | no | no |
| Language model as an assistant | in some cases | Yes, it involves a risk | no | no |
| AI-powered, human-reviewed (ifdb) | yes | yes | Yes, with real users | yes |
What the BFSG says about AI
The BFSG does not contain any specific rules on AI. It requires that your digital service is accessible, regardless of how you achieve this. An AI-supported assessment is therefore not, in itself, sufficient proof. What matters is whether your service actually meets the requirements and whether you can provide evidence of this.
Conversely, AI functions must themselves be accessible if they form part of a service offered to consumers. A chatbot in customer service, an AI assistant in an online shop or an advisory tool in online banking forms part of the service – and is therefore subject to the same requirements as the rest of the website. A chat window that cannot be opened using the keyboard, or whose responses are not read out by a screen reader (4.1.3 Status Messages), is quite simply a barrier.
AI Regulation: two accessibility requirements that hardly anyone is aware of
Ironically, the EU’s AI Regulation contains two accessibility requirements that are surprisingly rarely discussed. The first is already in force: from 2 August 2026, Article 50 requires chatbots to disclose that people are speaking to an AI. And Article 50(5) expressly stipulates that this notice must comply with the applicable accessibility requirements. An AI notice that a screen reader cannot read aloud therefore does not fulfil this obligation.
The second concerns high-risk AI, such as systems that sort job applications or assess candidates. Under Article 16(l), their providers must ensure that the systems comply with the EU’s accessibility requirements. Following the latest postponement, this will apply from 2 December 2027. You can read about what this means for recruitment processes in the article on accessible job applications.
How to spot genuine AI promises
Almost every provider now uses AI in their marketing. Whether there’s any substance to these claims can be established fairly quickly by asking five questions:
- Does the provider promise compliance at the touch of a button? If so, caution is advised, as a large proportion of the criteria cannot be checked automatically.
- Does the solution alter your source code, or does it just change how it appears in the browser?
- Do people check the result – using a keyboard, a screen reader and a screen magnifier?
- Do you receive documented evidence specifying the scope of the test, the method used and the date?
- Does the provider take responsibility for the results, or do they simply leave you to get on with the report?
How to make good use of AI
A clear division of labour works best: AI handles the volume and the drafts, whilst humans make the decisions. In practice, this approach has proved its worth:
- Let AI-powered scanners regularly check your entire website and group errors according to templates.
- Use AI suggestions for alternative text, document tags and plain language as a draft, never as a final version.
- Have any changes to the code checked by someone who is familiar with the WCAG criteria.
- Test the key workflows using a keyboard, a screen reader and real users of assistive technologies.
- Keep a record of the inspection and the rectification work so that you can demonstrate that you have exercised due care to the authorities and in court.
- Monitor your website regularly thereafter, as every update can create new barriers.
How we use AI at ifdb
We use AI where it saves time, and people where judgement is required. Access Score shows you how your website is performing in just a few minutes. Access Ready tests your application with real users of assistive technologies and with the screen readers JAWS, NVDA and VoiceOver, right through to a robust certificate. And Access Guard continuously monitors your website and reports new barriers as soon as they arise.
Many tools simply provide you with an automated report and leave you to get on with the results. We support you every step of the way, from the initial scan right through to verification. And, as an added bonus, your website will be built in such a way that even your customers’ AI agents can navigate it with ease.
Do you need solid evidence of your digital accessibility? In 30 minutes, we’ll discuss how the assessment and certification process works for your organisation.
Frequently asked questions about AI and digital accessibility
Can AI automatically make a website accessible?
No. AI can identify errors and suggest solutions, but it cannot reliably assess whether content is understandable or processes are user-friendly. Without human review, a large proportion of the requirements remain unaddressed, and AI-generated corrections to the code may even create new barriers.
Can I use ChatGPT to check my website for accessibility?
As a tool, yes: ChatGPT and other language models explain criteria, evaluate individual code snippets and rephrase text. They are no substitute for a proper test, however, as they do not interact with your website using a keyboard or screen reader, and can sound convincing even when they are wrong.
Why is digital accessibility important for AI agents?
This is because AI agents interpret websites using the same layer as screen readers: the accessibility tree, with its roles, names and states. If there are no clear labels or genuine control elements, an agent will be unable to search for or order items on your behalf. An accessible website is therefore easier for AI to use as well.
