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 \u2013 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. <\/p>\n\n
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\u2019ll 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\u2019ll show you why an accessible website is becoming the key to opening the door for AI agents. <\/p>\n\n
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 \u2013 for example, in our in-depth \u2018Access Ready\u2019<\/a> audit. In this process, real users of assistive technologies have the final say. I explain how to create accessible PDFs from the outset in \u2018Creating Accessible PDFs<\/a>\u2019. <\/p>\n\n 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 \u2018aha\u2019 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. <\/p>\n\n 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. <\/p>\n\n 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 \u2013 for example, \u2018Button, Add to basket, active\u2019. 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. <\/p>\n\n What is new is that AI tools also use this tree. Microsoft, for example, explicitly states in its documentation for Playwright MCP \u2013 a widely used tool that enables AI models to control browsers \u2013 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 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\u2019s a good reason why the first rule of ARIA is: wherever there\u2019s a suitable native HTML element, use that one. A genuine 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\u2019t 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<\/a>. <\/p>\n\n 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\u2019ll then see, for example, that a single product card template is causing the same missing link name to appear on all category pages. <\/p>\n\n AI is also helpful when it comes to prioritising and explaining issues. It translates an error message such as \u20184.1.2 Name, role, value not met\u2019 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<\/a>, which shows you where the measurable gaps lie in just a few minutes. <\/p>\n\n 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. <\/p>\n\n 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\u2019s 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. <\/p>\n\n 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). <\/p>\n\n 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. <\/p>\n\n 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 \u2018Our sales team at the Munich office\u2019, whereas a purely decorative background image, on the other hand, needs an empty 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\u2019s destination (2.4.4 Link Purpose), not the image\u2019s 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<\/a> shows what good alternative text looks like. <\/p>\n\n Practical tip<\/strong>: Don\u2019t 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 \u2018alt\u2019 attribute is the correct answer \u2013 and that is precisely what AI almost never provides on its own. <\/p>\n\n 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. <\/p>\n\n 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<\/a>. <\/p>\n\n Language models are excellent at simplifying complex texts. For plain language \u2013 that is, shorter sentences, fewer technical terms and a clear structure \u2013 a good AI draft with an editorial review is often sufficient. With \u2018easy language\u2019, however, it is different. It follows its own fixed rules and is aimed at people with learning difficulties. According to the rules of the \u2018Easy Language\u2019 network, every text must be checked by people from precisely this target group. <\/p>\n\n AI can significantly speed up this process, but it cannot replace it. Anyone who publishes an AI-generated text as \u2018plain language\u2019 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. <\/p>\n\n People underestimate just how much AI can help with the small, repetitive tasks in the editorial department. \u2018Click here\u2019 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 \u2018Invalid input\u2019 becomes an error message that explains what needs to be corrected (3.3.3 Error recommendation). <\/p>\n\n However, the key lies in how you phrase the question. \u201cMake the text accessible\u201d usually results in vague generalities. A specific task with context works better, such as: \u201cRewrite these three link texts so that they make sense without the surrounding sentence, and state the destination of each page.\u201d The result is then checked by a human \u2013 in a fraction of the time it would have taken to write it. <\/p>\n\n 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: <\/p>\n\n Although the first button now has a name, the screen reader reads out \u201cSubmit form\u201d, whilst the screen displays \u201cBuy now\u201d. This contravenes 2.5.3 (labelling in the name) and makes voice control impossible, as anyone who says \u201cClick Buy now\u201d will not select the button. Equally common are instances of 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 \u2018using AI\u2019. 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. <\/p>\n\n 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>. <\/p>\n\n The following overview categorises the common approaches according to what ultimately matters. Our own approach is clearly labelled as \u2018ifdb\u2019. <\/p>\n\nTwo approaches: AI for accessibility and accessibility for AI<\/h2>\n\n
How AI agents read your website: the Accessibility Tree<\/h2>\n\n
div<\/code> with no role and no name remains invisible to both \u2013 to the screen reader as well as to the agent. <\/p>\n\nWhy using more ARIA is still not the solution<\/h2>\n\n
button<\/code> element comes with role, keyboard navigation and focus by default, whereas a div<\/code> element that\u2019s been labelled retrospectively does not. <\/p>\n\nWhat AI is capable of in assessment today<\/h2>\n\n
The 30 to 40 per cent threshold \u2013 and why AI doesn\u2019t simply shift it<\/h2>\n\n
The blind spot in automated testing: states and processes<\/h2>\n\n
Alternative texts: Where AI helps and where it gets it wrong<\/h2>\n\n
alt=\"\"<\/code> 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. <\/p>\n\nPDFs and documents: AI-assisted tagging, human verification<\/h2>\n\n
Comprehensible texts and plain language using AI<\/h2>\n\n
Where AI really takes the strain off newsrooms in their day-to-day work<\/h2>\n\n
Code corrections using AI: faster, but with side effects<\/h2>\n\n
<!-- KI-Vorschlag: Scanner meldet keinen Fehler mehr -->\n<button aria-label=\"Formular absenden\">Jetzt kaufen<\/button>\n\n<!-- Besser: sichtbarer Text und zug\u00e4nglicher Name stimmen \u00fcberein -->\n<button>Jetzt kaufen<\/button><\/code><\/pre>\n\nrole=\"button\"<\/code> on elements that cannot be accessed via the keyboard at all (2.1.1 Keyboard), or aria-hidden=\"true\"<\/code> on elements that receive focus. No screen reader reliably flags all these cases \u2013 a person using a keyboard will notice them immediately. <\/p>\n\nAI-powered overlays: a promise that falls short<\/h2>\n\n
A comparison of AI approaches<\/h2>\n\n