Accessibility and AI: What Can Be Delegated, and What Can’t?

The European Accessibility Act has been in force for more than a year, but authorities still can’t enforce it. Meanwhile, development teams are having AI write an ever-larger share of their code, with measurements showing that accessibility is where AI performs worst. At Ergomania’s latest Product Design Talks event, we first followed an accessibility audit from start to finish, then three experts discussed where AI helps in this work and where it can even do harm.

 

The evening’s speaker was Olga Rozskova, senior product designer and accessibility auditor at Ergomania. The panel featured Árpád Nagy, lead UX designer and accessibility expert at OTP Bank; Zsolt Edelényi, web accessibility expert at Precognox; and András Fábián, principal product designer at Graphisoft. The discussion was moderated by Dr. András Rung, founder and CEO of Ergomania.

In Force for a Year, Yet the Market Is Holding Back

Rozskova opened with a short introduction. The 2019 European directive came into force last June, and the market is currently busy pushing compliance as far down the road as possible. Its scope, however, is no longer limited to the public sector. With a few exceptions – the smallest, low-revenue businesses – practically every B2C service falls under it, from e-commerce to transport. The reference standard is WCAG 2.2, which added nine new criteria to version 2.1, and version 3 is already in the works.

Unlike the previous talk, however, this one was not about the requirements themselves, but about how AI has not taken over the expert’s role – it has only sped up their workflow. Rozskova gave three arguments for this. First, more than 1,000 professionals have signed a statement rejecting plug-in widgets that promise one-click accessibility. Second, according to a 2025 study, none of the language models examined achieved full compliance. Third, the European Commission itself has confirmed that no automated tool covers all the requirements, and manual testing is unavoidable.

Where AI Comes into an Audit

Rozskova also walked through her own audit process, marking where the work is human and where a language model can lend a hand. The process starts with clarifying the brief, which is purely human work: is this really the entire user journey that needs to be examined and does it include third-party solutions, such as a chat or a booking module? Before finalizing the scope, she goes through the pages herself, because a process that looks like three steps often turns out to be much longer, and the timeline of the whole job depends on this.

The audit itself begins with a screen reader pass. Every suspicious or clearly faulty element is captured in a screenshot and added to a Figma file, organized by page, with plenty of annotations. Next comes a check of the rotor – the assistive view in which a screen reader user can run through the page’s links, headings, and sections as separate lists. This is where it becomes clear if the heading structure is a mess, or if there are seven links in a row labeled “Read more.”

Then come the two forms of zoom, each with a different focus: 200% is about the text – whether it fits and whether anything overlaps – while 400% is about the entire content, where having to scroll horizontally counts as a failure. The process ends with the handover: a presentation or workshop where designers, marketers, lawyers, product managers, and developers sit at the same table, and each of them has to be addressed in their own language.

AI plays a bigger role at two points. One is talking through borderline cases. Rozskova doesn’t know everything, and the model doesn’t know more than she does, but an uncertain question is easier to think through when there is someone to ask along the way. The other is structuring the final output. Her prompt sets out the role and the framework, i.e., that this is a manual audit with no automated testing, then the legal background and the methodology used, followed by the target groups: beyond people with visual impairments, users with limited mobility, for whom the size of the clickable area is the issue; deaf and hard-of-hearing users, for whom captions and transcripts matter; and finally people with cognitive impairments, for whom a countdown timer or a double negative in the text causes difficulties. The last part defines the output format: a table editable in Figma, with the screenshot, the issue, the reference, the proposed solution, and the severity.

Where AI Gets It Wrong, and What Stays Human

Rozskova showed two examples of the model missing the mark. One involved the rotor. From a photo of the screen reader’s list view, the model read out something different from what she saw with her own eyes. When questioned, it admitted the mistake. In the other, it only picked up a contrast issue, while the real problem was that the selected state was indicated by color alone.

What can’t be delegated? The first is gathering and annotating the evidence. The model can’t see the process – a static screenshot won’t show that clicking an element gets no response. Another is persuading decision-makers. If the auditor disappears after the handover, the results never become part of how the organization works. The third is testing with assistive technology. The fourth is professional responsibility: the auditor puts their own name to the results, and there is no pointing to the model after the fact.

In the second half of her talk, Rozskova summed up the lessons of a bank ATM project. In practice, voice guidance means an alternative interface with an entirely different logic, closer to a telephone menu system than to a screen – one that also has to stay in sync with the visible interface. It also turned out that security and accessibility can clash. Error notification is a basic accessibility principle, yet at an ATM, the system carries an incorrect PIN through the entire process and only flags it at the end, because in a threatening situation, this is what protects the user. Her conclusion: every fix made for users with disabilities made the machine better for everyone.

What Has Changed in a Year and a Half?

The panel’s first question was what has changed since a similar discussion on the same topic a year and a half ago. According to Zsolt Edelényi, once the European Accessibility Act came into effect, the waters began to stir – just not in Hungary. In France, the Carrefour supermarket chain was sued over its lack of accessibility. In court, the company argued that its 71% compliance was sufficient, but the court rejected this and ordered it to make its online store fully accessible within six months. In Sweden, more than 100 complaints reached the authorities within a very short time, and Germany set up a 70-person body to handle accessibility complaints. The other change is AI itself, about which, in Edelényi’s view, we now know a great deal more. So far, the balance is that it has caused more problems than it has solved.

Speaking for OTP, Árpád Nagy mentioned two things: the bank’s publicly available accessibility statement, and the fact that customer reports have multiplied over the past year. The latter is partly good news, because they arrive directly, not through an authority. OTP is in the middle of a technology shift, with much more component-based development. Some of these components are built with AI. The experience is mixed. What’s good is good, but what isn’t is hard to fix, because the model works as a black box. Overall, it speeds things up, but it also means considerably more iterations.

Things are different at Graphisoft. As András Fábián explained, with a few exceptions, the company is not subject to legal compliance requirements (the directive covers consumer, B2C products and services; professional design software falls outside its scope), so for them, accessibility is much more a question of usability and business. Over the past year and a half, they have introduced two AI features, which made the program’s accessibility neither better nor worse. What changed is that they now use AI in both design and development, and they see real potential in this.

Why the Hungarian Market Hasn’t Moved Yet

What lies behind the silence in Hungary: the national mindset, the authorities’ sluggishness, or both? According to Edelényi, it’s just a delay. Financial supervisory authorities coordinate at the European level every year, and the alignment of supervisory checks has already begun. If a fault is found at an international bank, it will be investigated wherever the authority moves fastest.

Nagy believes that the authorities are not yet prepared to carry out inspections. They lack both the expertise and the staff. From a company’s point of view, this may seem reassuring, since companies today know more about the subject than the authority does. Reviewing a mobile banking app would also take serious preparation: it requires the app itself, bank accounts, and user profiles. Regardless, the bank expects inspections to arrive sooner or later, and is preparing for them. For now, though, even those affected don’t know where to turn. It took Nagy months to find out which Hungarian authority was responsible, and when he called them, he was told they didn’t yet know about the task.

Fábián pointed to a paradox in his own sector. There is little movement among most of their competitors either, because apart from public procurement, they face no pressure to comply. While the physical world is becoming increasingly accessible, the tools used to create the built environment are not fully accessible – from an inclusive design perspective, that is a striking paradox.

Edelényi added that the lack of preparedness is also a technological issue. An official inspection has to be objective, predictable, and reproducible, and this cannot be achieved through manual testing alone. Fixing an accessibility error in a live system costs 30 times as much as at the design stage, and in his view, early fixing can only be achieved with the engineering-grade automated technology of the US company Deque – which saves a medium-sized organization tens of millions of forints a year. Implementing it, however, takes time, money, and expertise.

Beyond the Law: What Gets a Company Moving?

What can motivate a company beyond legislation? For Graphisoft, it is first and foremost about a better product. As an example, Fábián described how, when a graphical interface in Archicad was replaced with a list-based one, there was uproar, because keyboard users lost the focus order they were used to. At the time, accessibility wasn’t even part of the conversation, only efficiency. Many people see disability as an issue affecting a narrow group, when in fact it is a spectrum. Their users include older people too, and the tired eyes or hands of a designer drawing through the night are also a limitation.

According to Edelényi, the reason for the inertia is simply that the topic hasn’t yet reached decision-makers. When he lays out the arguments for return on investment, brand building, and market growth and shows them a case study, their eyes open, and they grasp the compliance risk too – it’s just that most of the executives he talks to had never heard of any of it before.

Nagy sees the same within OTP. He goes from manager to manager trying to explain the topic, and whether it gets through depends on two things. Either the person is open to it from the start, or they understand it through the legal risk – a language everyone speaks. A recurring question from managers is how many people this affects. In those cases, Nagy shares the bank’s own estimate of what proportion of its customer base is involved. What would really move things forward, though, is one or two Hungarian precedents – companies that have been fined – and there haven’t been any so far. Fábián believes that the misconception in senior management of accessibility being a niche issue can be dispelled by opening up toward inclusive design. Referring to the ATM research in Rozskova’s talk, he joked that when he stands in front of an ATM, he himself feels motor, cognitive, and visual impairments kicking in all at once.

AI as a Source of Errors – and as a Tool

Asked where AI is useful and where it does harm, Edelényi started with the bad news. The annual survey by WebAIM (a US accessibility nonprofit) runs automated accessibility tests on the home pages of 1 million websites. Last year, for the first time, it showed an increase in the number of errors. In his view, this is because developers are having AI write a growing share of their code. Research by AIMAC, developed by the GAAD Foundation and ServiceNow, found that 94.59% of AI models produce errors when generating HTML code, while in Microsoft’s open-source project A11y LLM Eval, 6 of the 10 models tested failed every automated accessibility test. By contrast, 88% of development leaders are convinced that AI-generated code is accessible – and this gap is at the root of the current problem. The reason is simple: LLMs were not trained on accessible code, and the Microsoft project’s goal is to push the major model developers to change that.

As a positive example, Edelényi cited the Deque Axe Toolkit mentioned earlier: its algorithmic component finds well over half of all accessibility errors, and a human- and AI-assisted layer finds nearly 20% more – so roughly 80% of errors can be covered. The key, however, is that this system is not stochastic (that is, not based on probability, as LLMs are); it draws its data from a reliable source and doesn’t hallucinate when answering questions about the standards.

Nagy gave an example from everyday work. If someone simply asks the model for a website without specifying what kind of compliance they expect, they won’t get an accessible solution by default. This is one reason they use AI to create accessibility annotations, to reach the design handover faster – although in his view, the real solution would be to define the components properly and build everything from them from then on.

From the vendor side, Fábián saw three opportunities. First, with issues like focus order, they know what the problem is, but the fix takes an enormous amount of programming work. In a feature-driven world, this is the first thing to be cut, because it’s hard to translate into dollars – with AI, however, this work can be done more efficiently. Second, the requirements can be built into the guidelines, the prompts, and the design system, so that design starts from a better baseline. Third, automated testing falls flat on closed software, because there is no readable data structure, only an empty canvas. Yet the data is there, since the BIM model – the digital twin of the building, in which every element is stored together with its associated data – is well-structured, semantic data.

The problem isn’t the data, it’s the interaction layer. This is exactly where MCP helps – the model context protocol through which the functions and data of a closed program become readable and interpretable for an external agent. In Fábián’s view, this is what a screen reader needs as well: with the same development work they put into a flagship feature, they can also make the product more inclusive.

Edelényi added that we need to learn how to use AI; most problems come from using it for things it isn’t meant for, and in ways it isn’t meant to be used. As an example of how AI, when used well, can be reliable, he cited the Axe Assistant built into Deque’s online training platform, Deque University. It was trained on 100% reliable accessibility examples and set up to give a reliable answer to every question.

What Will Remain Human?

What will still not belong to AI five years from now? According to Fábián, it’s the decision: defining what the quality criterion is, and which of several solutions is the right one. We can ask the model for data and reports, but not for the choice.

Nagy was more sceptical on this point, because in his view we tend to minimize effort. A good brief produces a good solution – but only if we can judge both the brief and the result. The risk here is that we understand less and less of the details. In research and reporting, however, he sees major opportunities. He also added that in his view, product teams will shrink considerably – designers will write the prompts for smaller changes themselves, while developers focus on more complex tasks.

Edelényi argued from the software development side. Today, the final decision lies with the developer, but as soon as there are systems that code reliably, humans will be taken out of the factory where code is made. Fábián added a concern he has heard from developers: the better a model codes, the less transparent the code becomes, and the more trust is demanded. At first glance, the code looks to be of high quality, so for the sake of efficiency, more and more decisions are handed over to the model, and developers no longer know the code as deeply as they used to. From his own experience, when he fed in too much information at once, he got plans he could no longer get his head around – they looked good, but he chose to start over, step by step. AI is not a personality that decides it will do the designing and we will carry it out.

Not a Project, but a Culture

In the closing round, Edelényi started from his own company’s perspective. Precognox works on AI integration as well as accessibility, so for him, the two areas are not separate. This also shaped his message: accessibility has to be built into the AI-driven development process. This is what he says internally, too, and in his view, the sooner companies take this step, the better placed they will be.

Nagy believes AI will play its biggest role in accessibility testing and reporting. New versions of the mobile and online banking platforms come out frequently. A full review is 4 weeks of work for 12 people – manual effort simply can’t keep up at that pace. The limits need to be tested: see what can be handed over, then check the results. Routine steps can safely be left to AI. For example, it reliably flags a missing alt text on an image, but it can’t decide what the alt text should say, or whether one is needed at all. He added that accessibility is not a one-off project. If it’s done once and then not maintained, it starts to deteriorate, so it has to become part of the company culture.

Fábián’s message to his own decision-makers was that MCP and AI offer an unprecedented opportunity to pay off a serious debt cost-effectively. But that alone won’t make the product accessible; it only makes getting there much more efficient. As for why it’s worth doing, his argument is that they don’t want to make an accessible product, they want to make a good product – and a good product is accessible. Just as a good building, a good hospital, and good public transport are. Seen this way, it is not charity but business and inclusion: the more people who can use the product, the better for the company.