WCAG 3 and AI-generated interfaces: a practical accessibility check

## Quick answer

An AI-generated screen can look polished and still fail basic accessibility checks. Review the experience as a sequence of tasks: can a keyboard user reach the action, can a screen reader understand the structure, and can a person recover from an error?

Use automated checks for repeatable signals, then test the real flow with keyboard navigation and a screen reader. The result should be a short list of verified states, not a claim that the interface is accessible because the colour contrast passed.

The designer opens the Figma file, which was generated by the assistant. Landing, dashboard, float onboarding - everything is already arranged. The grids converge, the shadows are soft, there are button states. Looks fine. It's in development.

Two weeks later, an email comes from a user with a screen reader: half the form is not voiced, the icons have no signatures, the focus jumps from the “Send” button back to the header, and the error text is displayed in a color that VoiceOver simply does not see. And these are not layout bugs - it was all laid down on the layout. The one you didn't draw.

This is a new reality. Part of the interface is now created not by a person, but by a model - Figma AI, v0, Lovable, custom MCP agents, plugins on top of the design system. They quickly assemble the composition, but know almost nothing about accessibility. And WCAG 3.0 (even at the working draft stage) raises the bar – there is no longer a “contrast of 4.5:1 and all”, there is an assessment of tasks, contexts of use, several groups of users at once. You can't check it with your eyes anymore.

## Why the old approach to accessibility no longer works

Previously, the scheme was simple: the designer himself put the contrast, he signed the alt, he thought about the tab order. Accessibility is built into the process because the process has one author.

There are at least two authors, you and the model. And the model has no responsibility for the outcome. It optimizes the visual result: to look like a reference, to get into brand colors, to match the industrial. Semantics, focus, roles, states, movement - all this for her cosmetics, which can be completed, or you can not finish.

Here are three new types of errors that were almost absent in hand design:

• Plausible but fictitious semantics. The button is drawn as a button, but this is div from onClick. The title looks like H2 but is marked as plain text.
• Contrast "by eye." The model chooses shades so that it is beautiful, and regularly misses 0.3-0.7 on the APCA. The eye cannot see, the screen reader will survive, and the user with low vision will not.
• *Default and hover are generated. Focus-visible, disabled, loading, error, empty - missing or the same. WCAG 3.0 looks at this separately.

## Which changes in WCAG 3.0 versus 2. xx

Short and no tedious, because the checklist depends on it.

### From binary “passed/failed” to scale

In 2.x, the criterion is either met or not. In 3.0 - score on a scale (ratings like bronze/silver/gold in the early drafts). This means that you can no longer “close the line with a tick.” It is necessary to show how well the problem is solved, not just the fact of its solution.

For AI-generation, this is critical: the model produces a result that is often formally “does not violate”, but in quality – at the lower limit. We gotta catch this.

### Evaluation by results, not by technique

WCAG 3.0 sees if the user can complete the task of finding a product, paying for it, writing a message. Not “is there an alt in the picture”, but “is the meaning of the block without sight clear?”.

It doesn’t fit well with how AI tools work. They generate a screen, not a script. They don’t know what the user has to do. So the responsibility for the screenplay is entirely on you.

### Contrast by APCA, not WCAG 2 formula

In 3.0 move to APCA, an algorithm that takes into account the real perceived difference, size and weight of the font. Many color pairs that went through 2.x look faint on APCA, especially thin fonts on colored backgrounds. AI likes these combinations – they are “designer”.

## The first filter: what to check before the layout went into development

For now, it's fresh and cheap. This is not a complete audit, this is an input control — 15-20 minutes per screen.

### Checklist of input control of the AI layout

• For each interactive element, it is clear that it is interactive (not only in color)
• Default, hover, focus-visible, active, disabled, loading
• Focus-visible differs from hover and is visible on all backgrounds where the element occurs
• The contrast of text is checked for APCA, not just WCAG 2 (especially for sizes less than 16px and fine outlines)
• Color is not the only carrier of meaning (errors, statuses, links in the text)
• Unsigned icons have a meaningful text alternative in the specification
• The size of the touch target is at least 24×24, the target is 44×44, with gaps
• Text blocks are not stitched with a picture
• Reading order matches visual order (checked in Figma via outline/layers)
• Any animation longer than 0.2 s has a clear meaning and is not obsessive

### The anti-patterns AI generates are particularly eager

• A gray placeholder instead of a label is a field without a signature, when you enter the signature disappears.
• The "ghost" buttons are 1px contour in #D0D0D0 on white. It's almost invisible by APCA.
• Two-color graphs without signing values - meaning is read only by sight and only in color.
• Toast notifications that disappear after 2 seconds without the ability to return.
• Modals without an explicit header like dialog and without returning focus to the trigger.

If you see this in the generated layout – it is not “finish on the layout”. This is reworked in design because otherwise the developer will inherit the solution as a requirement.

## Workflow: where to catch problems in Pipeline

AI generation breaks the usual order “designer → review → development → QA accessibility”. Now the source of the layout is the model, not the person, and it doesn’t know what the user script is. This means that accessibility control needs to be built in earlier and at multiple points, otherwise it just won’t happen.

### Four checkpoints on the way from prompt to release

• Prompt. Before generation, set frame models: touch-target size, mandatory states, contrast pairs from the design system, density limitations. Do not "make beautiful and modern" but "a component must have a focus-visible 2px outside, hover, disabled with opacity 0.5 not to use.".
• **Output model.**Input control from the previous section. 15 minutes on the screen before the layout went to Figma as "accepted.".
• Assembly into layout. When an AI piece is placed on a real screen with real data — long names, empty states, network errors, RTL. Here comes up half the problems that were not visible in the isolated picture.
• Specification for development. Transmission is not pictures, but intentions: what semantics, what ARIA attributes, what order of focus, what texts for the screen reader. Otherwise, the front will get a “div that looks like a button,” and it will fold.

### Who's in charge

A common mistake is to assume that since the layout generated the model, then the availability “somehow by itself”. Nope. Responsibility remains with the person, and it is useful to say it out loud.

• Designer: semantics, states, contrast, order of reading, texts for assistive technologies.
• Developer: correct implementation of semantics, focus management, keyboard testing and screen reader.
• Product: Scenarios that test not only “works” but “works for a person with limitations.”.

If the team does not have a person who clearly owns this site, AI mockups will go on sale with the same sores month after month.

## Diagnosis: How to quickly understand how bad

Not every screen needs a complete audit. But quick measurement is useful - it shows whether it is possible to take this layout into work at all or you need to return for rework.

### Test in five minutes

1. Pass the screen only with the Tab keys. Can you see where the trick is? Is order logical?
2. Turn on the gray scale in the system. Are there different statuses, errors, active states?
3. Reduce the font to 200% through browser zoom or simulation in Figma. Is the layout broken, is the text cut?
4. Read the screen out loud as if you were dictating to a friend on the phone. Is the structure clear without the visual?
5. Ask yourself: What happens if the input field returns the error? Does the layout have this state?

If you stumble on any of the steps, the layout is not ready, no matter how beautiful it is.

### Where to watch APCA, not WCAG 2

WCAG 2 calculators are built into all Figma plugins and give the green tick too generously. For thin fonts, light text on colored backgrounds and any gradients, it is better to run through the APCA calculator separately. The target values for the main text are Lc 75+, for large headings – Lc 60+, for inactive and decorative elements – Lc 45+. These are rough landmarks, but they save from "formally passing, it is impossible to read.".

## Questions for design review AI layout

A list that is useful to keep in front of your eyes when looking at someone else’s or a generated screen. Not for a tick, but for a conversation with the author.

• What scenario does this screen solve and where is the user with the screen reader?
• What is primary action and why is it visually different from secondary?
• Where is focus-visible and does it match hover?
• What states are not drawn and why are they not in the product or forgotten?
• If you remove the color, does it make sense?
• What will the developer see in the specification: a semantics component or a picture?
• What will happen to this 320px screen at 200% zoom?
• Which texts will go to the aria-label and who writes them - the designer or the front on a whim?

A good review is not “found a joint”, but a conversation after which the author sees what is missing.

## Segment summary

AI speeds up generation, but doesn’t take responsibility for accessibility—it stays with the designer and the team. Embedded control in four points: prompt, model output, layout assembly, specification. Check by APCA, script and state, not just picture. And remember: what got into the layout as “accepted”, the developer will inherit as a requirement – to redo it cheaper now than after the release.

## Advanced Scenarios: When AI Becomes Part of Pipeline

A single layout is half the story. The real pain begins when AI is built into the daily process: generating variants through Figma AI, importing components from v0, transferring the layout to Cursor via MCP. Here, accessibility breaks down not at the level of an individual screen, but at the level of habit.

### Scenario 1: Make Me 5 Choices of This Card

The model honestly gives five. All are beautiful, none is marked by contrast, and three have inactive states made via opacity: 0.4 over an already faded color. The designer chooses the “cleanest” and a component that won’t even pass WCAG 2 goes to the library.

Which helps:

• Run all options through the APCA plugin before the selection, not after.
• In the prompt, immediately fix: “disabled through the token --state-disabled, not through opacity”.
• Keep the reference values of Lc in the design system and compare with them, not by eye.

### Scenario 2: MCP transmission to code

Figma MCP gives the model not a picture, but a structure: frames, autolayout, layer names. If you have a layer called Group 47, the code will come <div>. If it's called Button / Primary / Disabled, there's a chance for semantics, but only a chance.

Anti-pattern: Assume that MCP “will figure it out.” It won't. It will carry exactly what you put in the names and structure.

What to put in the layout so that the output in the code was meaningful:

• Component names are Input / Text / Error, not Frame 12.
• In the description of the component - the role and aria-label by default.
• States as variants of a component, not as separate frames side by side.
• Text placeholders that don’t look like real signatures (otherwise the model will think it’s a label).

### Scenario 3: AI revision of the AI layout

The temptation is to run the generated screen through the same model with the “find accessibility issues” prompt. Sometimes it works, more often it doesn't. The model will confidently list common items (“check contrast”, “add alt-texts”), but will not see that in this particular layout, the focus-trap does not close from the keyboard. An AI review is useful as a first filter, but not as a final test.

## How to explain the decision to the team

Most of the gaps in accessibility are not technical, but communication. The designer sees the problem, but can’t build it into the team’s priorities.

### Translate into the language of the interlocutor

• “This screen loses N percent of scripts on screen readers, and it’s an audience that won’t leave on its own — it just won’t convert.”.
• “If we sew div onClick right now, we’ll have to rewrite it to button through the sprint because the focus doesn’t work.”.
• Lawyer or compliance (if any): “EAA from 2025 in the EU requires availability for commercial products – it’s not nice to have.”.

"Blind users" as an argument works poorly. “Cost of rework” and “risk” are better.

### Make the problem visible

Recording a screen with a screen reader passing through your layout as is convinces faster than any presentation. Ten seconds where VoiceOver reads “button, button, button, button” instead of action names – and the discussion ends.

## The checklist of the quality of the AI layout before the Merzh

• All interactive elements are state components, not static frames.
• Contrast is tested for APCA, not just WCAG 2.
• Focus-visible is drawn and different from hover.
• Errors and empty states are in the layout, not “finish later”.
• Texts for assistive technologies are written in the specification, not left to the developer.
• The order of reading coincides with the visual order – verified by Tab navigation in the prototype.
• Layer and component names are meaningful in case of transmission via MCP or export to code.

## Segment summary

AI changes not the fact of checks, but their point of application: you need to control not only the final layout, but also the prompt, library, layer names, specification. Argue the team through cost and risk rather than morals – it works faster. And remember, the best way to show the accessibility issue is not to describe it, but to let a colleague hear how your screen sounds on a screen reader.

## The final checklist: what to check with your hands

The previous checklist was "macro" - about what should be in the layout. This one is about micro-checks that take minutes but catch most of the AI generation failures.

### Color and contrast

• The text on the color buttons is checked by APCA, not only by 4.5:1.
• Disabled is readable but not as active (Lc differs by at least 15 from active).
• Errors are not transmitted by color alone; there is an icon or text.
• The focus indicator has a contrast of ≥3:1 with any background on which it can appear.
• Input placeholders are not used as a single label.

### Structure and semantics

• Each button in the layout is a Button component, not the text in the frame.
• Button icons have hidden text or aria-label in the specification.
• Titles in the layout go by hierarchy (H1 → H2 → H3), not by font size.
• Forms have visible labels, not just placeholders.
• Links differ from ordinary text not only in color.

### Conduct

• The Tab order in the prototype coincides with the visual order.
• Modals have a focus trap and return focus to the trigger when closed.
• Toasts and notifications stay on screen long enough or have a way to re-read.
• Animations can be turned off (prefers-reduced-motion is included in the specification).
• Session time and timeouts don’t “eat” the user without warning.

## The anti-patterns AI generates most often

### "Ghost disabled"

The model reduces the opacity at the active button to 0.4 and calls it disabled. Contrast leaves below acceptable, the state is almost the same as a hover on a dark topic. It is treated only with a token of state, run by hands.

### Gradient text

The favorite method of generative layouts is white text on a blue-violet gradient. At the center of the button, the contrast is good, at the edges - a failure. APCA plugins show one number for a pixel, and the real readability sags.

### Icon instead of button

AI draws a “modern minimalist interface” – three dots, a gear, an arrow. What these icons do is clear only to the designer. The screen reader will read Button and shut up.

### Pseudo-input

The input field is drawn as Rectangle with text inside. Visually, input. The code after the MCP transfer is div. No keyboard focus, no autocomplete, no assistive support.

### "States After"

The layout has one screen: “how it should be when everything is fine.” No download, no error, no blank list, no offline. AI paints success perfectly and almost never files.

### Contrast "in a screenshot"

The designer throws the image of the layout in the chat and asks “how is the contrast?”. The model looks at the compressed JPEG and responds "normally." The real meanings of colors can be quite different.

## Questions for review layout

These questions should be asked aloud – yourself or a colleague – before sending a layout to the development.

• What happens if you only open the screen from the keyboard?
• What will the screen reader hear in the first five seconds on this screen?
• What three states of this screen have I not drawn?
• If the color disappeared, could we use this interface?
• Which of the elements did AI paint with a picture rather than a component?
• What text in the layout should actually be a label and not a placeholder?
• Where in this layout is the focus “lost”?
• What in layer names will come into the code through MCP and break the semantics?

If there is no clear answer to any of these questions, the layout is not ready yet, even if it looks beautiful.

## Practical outcome

Availability in the age of AI generation is not a separate test at the end. It's a set of habits: write prompts with constraints, hold state tokens, check APCA contrast, name layers meaningfully, draw states, run Tab by prototype. Each individually takes minutes. Collectively, they save weeks of reworking and save an audience that no one on the team will see in conventional analytics because it just doesn’t reach the screen. AI draws fast. The responsibility for how real people use it is still on the designer.

## FAQ

Is an automated audit enough? No. It catches repeatable markup and contrast problems, but not every focus order, naming or task-flow failure.

What is the fastest manual check? Navigate the complete primary flow with only a keyboard and inspect focus, labels, errors and recovery.

When should accessibility be checked? During the first prototype and again after implementation, because components and content can change the result.

### What to read next

• Figma AI Agent: what to check before trusting the canvas
• Components in Figma that survive updates
• CSS animations without a library