An agent generates a settings screen. The secondary text sits at 2.9:1 against the background, below the WCAG minimum. The buttons have no visible focus state, so a keyboard user can't tell where they are. The form fields use placeholder text as their only label, so a screen reader announces nothing once the user starts typing. It ships, because it looked finished and nobody checked. A month later, a user who relies on a screen reader can't complete signup, and the question lands on someone's desk: who's responsible for this?
The answer is uncomfortable and simple, and it's the reason AI generated UI accessibility is about to be a real problem for a lot of teams. The AI is not responsible. The company that shipped the interface is, exactly as it always was, and "the agent made it" is not a defense that exists in any accessibility law or any court. As agents generate more UI, they generate more accessibility failures, and the liability for those failures sits entirely with the humans who let them ship. This piece covers what AI reliably gets wrong, why, who actually owns it, and the accessibility gate that keeps it from reaching users.
What AI-generated UI gets wrong
An agent generates a settings screen.
Accessibility failures from agents are consistent, which is good news, because consistent failures are catchable. The recurring ones:
Contrast. Generated color choices frequently fail the 4.5:1 ratio for normal text and 3:1 for large text, especially on secondary text, placeholder text, disabled states, and buttons where the tool prioritized a pleasant look over legibility.
Focus states. Agents routinely omit visible focus indicators, so keyboard and switch users have no way to see where they are on the page. The interface looks clean and becomes unusable without a mouse.
Labels. Generated forms lean on placeholder text as the only label, which disappears when the user starts typing and is often not exposed to assistive technology at all. The field becomes a mystery to a screen reader.
Semantic structure. Agents produce markup that looks right and isn't structured right, headings that aren't real headings, buttons that are actually styled divs, landmarks that don't exist, so assistive technology can't navigate it even when it renders correctly to a sighted user.
Keyboard operability. Custom interactions the agent generates, dropdowns, modals, tabs, frequently can't be operated by keyboard alone, trapping or excluding anyone who doesn't use a pointer.
Motion. Generated animations often ignore reduced-motion preferences, which can cause real physical discomfort for users with vestibular conditions.
Why AI gets accessibility wrong
Two reasons, and both are structural rather than fixable by a better prompt alone.
The training data is the average web, and the average web is inaccessible. Models learn from what exists, and most of what exists fails WCAG, so the statistical center the model reproduces is itself non-compliant. Asking an agent for "a clean form" gets you the average form, and the average form has accessibility problems baked in. The model isn't ignoring accessibility; it's faithfully reproducing a web that ignores it.
Accessibility is largely invisible in a static mock. Contrast is visible if you measure it, but focus order, keyboard operability, screen-reader semantics, and reduced-motion behavior don't show up when you look at a still image of a screen. The agent optimizes for how the screen looks, and most of accessibility is about how the screen behaves, which the agent isn't evaluating and a quick human glance doesn't catch either. This is the same reason accessibility gets missed in hand-built design, amplified: the agent produces more, faster, with the same blind spot, a dynamic related to why dark mode is harder than it looks, where the visible layer hides the hard part.
Who's actually responsible
The legal and ethical answer is the same, and it doesn't bend for AI: the entity that publishes the interface owns its accessibility. Accessibility law, the ADA in the US, the European Accessibility Act that applies across the EU, and WCAG as the standard courts and regulators point to, attaches to the product and the company shipping it, not to the tools used to build it. No framework anywhere accepts "our AI tool generated the inaccessible code" as a defense, any more than "our contractor wrote it" excuses a company from a defective product. If it ships under your name, its accessibility is yours.
This matters more now, not less, because agents increase the volume of UI shipped and the temptation to ship it fast without review. A team that used to hand-build ten screens and check a few now generates fifty and checks none, and every unchecked screen is a potential compliance failure the company is fully liable for. The accessibility risk didn't move to the AI. It scaled up and stayed exactly where it was, with you. The legal exposure this creates is real and rising, which the piece on accessibility as a lawsuit risk covers in depth. None of this is legal advice; it's the direction every accessibility regime already points.
The practical upshot: since you own the failures regardless, the only rational response is to catch them before they ship. Which means a gate.
The accessibility gate for AI output
Treat accessibility as a required checkpoint on any AI-generated UI before it reaches a user, structured so most of it runs automatically and the rest is a fast human pass.
Automate what a machine checks better than a human. Contrast ratios, tap-target sizes, missing form labels, and missing alt text can all be caught by automated tools, in the design file or in the build pipeline. Wire these up so no generated screen advances without passing them. This handles the highest-volume failures, contrast and labels, with zero ongoing human effort.
Keep a short manual pass for what automation can't catch. Tab through the screen with the keyboard alone: can you reach and operate everything, and can you see where you are? Run it through a screen reader briefly: does the structure make sense, are the controls announced? Check that animations respect reduced-motion. These take a few minutes per screen and catch the behavioral failures automated tools miss, focus, keyboard operability, semantics.
Make it a gate, not a suggestion. Accessibility that gets checked when someone remembers is accessibility that ships broken under deadline. Put it in the workflow as a required checkpoint with a named owner, the same way you'd gate any quality-critical review, a structure covered in human-in-the-loop review for AI design. The gate is what converts "we care about accessibility" into "inaccessible screens don't ship."
Feed failures back into prompts. If your agent consistently produces low-contrast secondary text, add "all text meets WCAG 4.5:1 contrast, all interactive elements have visible focus states, form fields have real labels" to your standing instructions. It won't fix everything, the structural failures remain, but it reduces the volume the gate has to catch, which makes the whole process cheaper.
The compliance window is closing as AI opens the floodgates
The timing here is bad in a way worth naming. Accessibility enforcement is tightening at the exact moment AI is increasing the volume of UI that ships. The European Accessibility Act began applying across the EU in June 2025, extending accessibility obligations to a wide range of digital products and services sold there, so a company reaching European users now faces requirements it may not have faced before. In the US, web accessibility litigation under the ADA has climbed year after year, with thousands of suits and demand letters targeting inaccessible sites and apps. The direction across regimes is the same: more scope, more enforcement, less tolerance for "we didn't get to it."
Now put that next to the AI shift. Teams that used to hand-build a handful of screens and check them are generating many more, faster, with the accessibility blind spot described above, and shipping them with less review, not more. The volume of potentially non-compliant UI is rising just as the consequences for shipping it are rising. A team that treats accessibility as optional is increasing its exposure on both axes at once. The window in which you could quietly ship inaccessible interfaces and hope nobody noticed is closing, and AI is the thing prying it open wider.
Accessibility is a quality and reach issue, not only a legal one
Framing accessibility purely as legal risk undersells it, and the undersell is why it keeps losing to deadlines. Accessible design is better design. Sufficient contrast helps everyone reading on a bright screen outdoors, not only users with low vision. Clear focus states and keyboard operability help power users, not only people who can't use a mouse. Real labels and clean semantic structure improve how the page is understood by search engines and assistive technology alike. Reduced-motion support spares users who feel unwell from your animations, and annoys no one who doesn't need it.
There's a reach argument too. A meaningful share of any audience has a disability, permanent, temporary, or situational, and interfaces they can't use are customers you can't serve. An inaccessible signup flow isn't only a legal liability; it's a segment of your market walking away silently, which never shows up in a survey and quietly caps your growth. The teams that treat accessibility as a quality standard rather than a compliance chore end up with interfaces that are clearer, faster to navigate, and usable by more people, which is what good design was supposed to mean before "clean" got confused with "legible."
Start Monday
Take the next AI-generated screen your team produces and run it through one automated contrast-and-label check plus a two-minute keyboard test, before it ships. Write down what failed. Do it on five screens and you'll have both a hit rate, evidence of how often AI output fails accessibility, and the beginning of an a11y gate. That's a week of work that protects real users and removes real legal exposure, and it starts the habit that keeps both problems from scaling with your AI usage.
Agents will keep generating more UI, faster, with the same accessibility blind spot they inherited from the web they learned on. The failures are consistent, which means catchable, and the responsibility for them is yours whether you catch them or not. Build the gate, automate the bulk of it, and stop shipping the failures you'll be held accountable for anyway.