Building Accessibility with Generative AI: Five Things Teams need to Consider

16 September 2026 - Keith Allan

""

Generative AI has moved quickly from experimentation into everyday design and development.

Developers are using it to generate code and troubleshoot problems. Designers can produce interfaces and prototypes in minutes. Content teams can create, restructure and adapt information at a scale that would previously have taken considerably longer.

For accessibility, that speed is both a help and a risk. AI can help teams understand requirements, suggest accessible patterns and catch problems earlier. But it can just as easily produce a component that works perfectly with a mouse and shuts out keyboard users, a colour palette that fails contrast requirements, or an image description that simply says "image".

The important question is no longer whether teams will use AI to build digital products. It is how they use it without losing accessibility along the way. Here are five things worth considering, whichever part of the process you work in.

1. If accessibility isn't in the prompt, don't expect it in the output

Generative AI works with the requirements and context it is given.

Ask it to "build a contact form" and you may get something that looks and behaves like a contact form. That doesn't necessarily mean you'll get correctly associated labels, accessible validation, appropriate error messages, logical keyboard interaction or properly communicated status updates.

Accessibility needs to be part of the brief. For developers, that might mean asking for semantic HTML, keyboard accessibility and WCAG 2.2 AA conformance, for example "build a contact form with programmatically associated labels, keyboard operability and error messages announced to screen readers". Designers can ask for minimum contrast ratios, visible focus states and adequate target sizes. Content teams can ask for plain language, descriptive link text and meaningful alt text. It also means including accessibility requirements when asking AI to develop acceptance criteria, user stories or design suggestions.

Used well, AI can bring accessibility conversations much closer to the point at which decisions are made. Instead of waiting for an audit at the end of development, teams can ask accessibility questions while they design and build.

2. Convincing output isn't necessarily accessible output

One of generative AI's strengths is its ability to produce plausible-looking results extremely quickly. That is also where the risk sits.

A custom control can look completely correct while being impossible to operate with a keyboard. An icon button can work visually while having no accessible name. A form can display an obvious error message without telling a screen reader that anything has changed. A polished mockup can contain low contrast text. A well-written page can still have links that say "click here" or images described as "graphic".

The wider web shows how easily this happens. WebAIM's 2026 analysis(this will open in a new window) of the top one million home pages found that 95.9% had detectable WCAG 2 failures, up from 94.8% the year before and reversing six years of small improvements. It also found that pages using ARIA had significantly more detected errors than pages without it, an average of 59.1 compared with 42, and that the more ARIA a page contained, the more errors it tended to have. WebAIM is careful to note that this doesn't necessarily mean ARIA introduced those errors, because those pages were also more complex. But it is a useful reminder that adding more code doesn't make something more accessible. WebAIM also suggests these trends likely reflect broader changes in how sites are built, including greater reliance on third-party frameworks and AI-assisted coding.

None of this is unique to AI. We see the same problems regularly on sites that were built entirely by hand, which is why clients come to us for detailed manual accessibility inspections. Automated tools only catch a portion of these issues, so our inspections draw on our extensive experience of watching people with disabilities use websites, and on usability testing with disabled participants, which shows us exactly where and why someone gets stuck. AI can produce the same problems, only faster.

Treat AI-generated output as a starting point, not evidence of accessibility.

3. AI can support accessibility expertise. It can't replace it.

There are many useful applications for AI in accessibility work. A developer unfamiliar with an accessibility requirement can ask for an explanation. A designer can sense-check colour and layout decisions. A content editor can ask for help making a page easier to read and navigate. Existing code can be reviewed for potential problems, and accessibility acceptance criteria can be drafted earlier in a project.

That can make accessibility knowledge much more readily available during everyday work. But accessibility decisions are often contextual.

The technically correct answer may not be the most usable one. A component that works in isolation may create problems within a wider journey. Meeting a WCAG Success Criterion doesn't automatically mean someone using a screen reader, magnification, voice control or keyboard will have a good experience.

AI can provide information and suggestions. Understanding how those decisions affect real people still requires expertise, judgement and testing.

4. Test the experience, not just the output

A code review or automated accessibility scan can tell you useful things. Neither can tell you what it is like to use the product.

  • Can someone complete the whole journey using only a keyboard?
  • When an interaction changes the page, does focus go somewhere sensible?
  • At 400% zoom, can someone still understand and operate the interface?
  • Does a screen reader communicate the name, role and state of controls correctly?
  • Are errors and status messages communicated when they appear, or only visually displayed?
  • Do headings, links and image descriptions still make sense when read out of context?

These are questions that require interaction with the product, and the most useful answers come from people who use assistive technology every day.

Automated testing remains a useful part of an accessibility programme, particularly when it is built into development and monitoring processes. But manual testing and assistive technology testing remain essential.

The faster we become at creating digital experiences, the more important it becomes that assurance keeps pace.

5. AI doesn't change who is responsible for accessibility

The organisation providing the product or service remains responsible for the experience people have when using it.

Whether a barrier was introduced by a developer, a designer, a content editor, a third-party component or AI-generated code makes little difference to the person who encounters it. For organisations selling covered products and services to EU consumers, responsibility is legal as well as ethical. The European Accessibility Act has applied since 28 June 2025, and enforcement is now under way in several countries, as we explored in The Deadlines Moved. The Standard Didn't.

AI therefore shouldn't remove accessibility checks from the process. If anything, the speed and volume at which it can produce digital content makes those checks more important.

Teams still need clear accessibility requirements, knowledgeable people reviewing the work, appropriate testing and, where possible, involvement from disabled users.

Making AI work for accessibility

Generative AI has real potential to improve how accessibility is considered during design and development.

It can make knowledge easier to access, help teams explore solutions and bring accessibility questions into conversations much earlier than a traditional end-of-project audit. But it doesn't provide assurance on its own.

At User Vision, we work with organisations at different stages of this process – from detailed manual audits, assistive technology testing and usability testing with disabled participants, through to training and consultancy that helps design, development and testing teams build accessibility into their everyday practice. For organisations managing accessibility across multiple digital products, our Access360 managed accessibility service combines expert testing with ongoing monitoring and reporting to help teams understand where barriers exist and track improvements over time.

AI can help teams build faster, and it can help them build better, but only if accessibility is part of the process from the start.

The shopping cart battleground: what Amazon's shopping agent standoff means for UX

21 September 2026

Amazon has now blocked AI shopping agents from Perplexity, Google, OpenAI and Meta. Behind the legal arguments sits a UX problem: customers who ask an agent to buy for them and hit a wall. Here is what the standoff means for your customer journeys, and three questions to ask now.

Read the article: The shopping cart battleground: what Amazon's shopping agent standoff means for UX

The Unintended Consequences of Making Things Easier

7 September 2026

AI scribes save GPs time, but University of Edinburgh research suggests other things change too. Three lessons on behaviour, trust and effort for anyone introducing AI into a service people rely on.

Read the article: The Unintended Consequences of Making Things Easier

The Deadlines Moved. The Standard Didn't.

24 August 2026

Two accessibility deadlines moved in opposite directions this year. The EAA turned one in June and enforcement is now visibly ramping up across EU member states, while the US extended its ADA Title II deadline for state and local governments to April 2027 or 2028, depending on size. Neither is a reason to relax: both frameworks converge on WCAG 2.1 AA as the baseline, and this piece sets out what the extra runway is actually for.

Read the article: The Deadlines Moved. The Standard Didn't.

Explore all thoughts

Do you have a project in mind? Let’s chat about what we can do for you. Get in touch