Beyond the Prototype UI: What the Generated Interface Is Actually Missing

AI-generated interfaces look alike because the model returns the average of its training data, and that average is React with Tailwind CSS and shadcn/ui. The result is a defensible layout that nobody chose. Designer Austin Knight gives the best description of the output: "The challenge with these tools, and the gripe you'll hear most often from designers, is that they produce a lot of sameness." He lists the formula it produces: a navigation bar, a hero section, a centred headline, a few separated cards in a grid, a clean footer. His verdict on the result is the line worth keeping: "Everything is good, nothing is great." Anastasia Axelrod of AXE-WEB names the mechanism: "AI models are prediction engines trained on the open web... the AI views this aesthetic as the 'statistically most likely' answer to a design prompt. It defaults to the average of its training data." She also claims to spot a generated site in about half a second, mostly by its colour: "that specific shade of 'Tailwind Blue' or 'Purple Gradient'." Developers have a name for the result, the Sea of Sameness. One correction worth making, because getting it wrong makes you sound uninformed. Anna Arteeva of Design Systems Collective: "When someone says, 'AI-generated apps look like Tailwind', that's a misunderstanding. Tailwind has no inherent visual style. It just gives you the building blocks." The sameness comes from the defaults, indigo-500 and the standard radius and spacing scale, plus the fact that generation tools are heavily optimised for the Tailwind and shadcn combination. That points at the fix. Adjectives in a prompt will not change the output, because "modern and premium" is what produced the default in the first place. Design tokens will. Knight's own constraint prompt reads like configuration, not description: use our Tailwind config and component registry, reference our CSS variables rather than Tailwind defaults, follow our type scale, use our button radii, use our named motion easings. Note what this section is not. There is no peer-reviewed research on AI interface homogeneity. Everything above is practitioner commentary from named designers, and it is worth reading as exactly that.

A generated UI skips every state except the one where nothing has gone wrong. A generated screen typically ships the loaded, populated, valid, desktop, mouse-driven state and nothing else. Here is the checklist, with what has to exist for each. | State | When a real user hits it | What you have to build | |---|---|---| | Loading | Every fetch on a slow connection | Skeleton or spinner, disabled submit, no layout shift when data lands | | Empty (first run) | Brand new account, nothing created yet | Explanation of what goes here plus the action that creates the first item | | Empty (no results) | Search or filter returns nothing | Distinct message, the query echoed back, a way to clear filters | | Error (network) | Wifi drops mid-request | Human message, retry action, nothing lost from the form | | Error (server) | The API returns a 500 | Message that does not blame the user, a way out, an error logged somewhere you can see | | Partial failure | Three of five items saved | Explicit statement of what succeeded and what did not | | Validation | Wrong email, missing field, 400-character name | Inline messages tied to the field, plain-language recovery, no lost input | | Success and confirmation | Anything destructive or irreversible | Confirmation before, feedback after, undo where possible | | Component states | Hover, focus, active, disabled | Visible focus ring in particular, since it is what keyboard users navigate by | | Mobile and small screens | Roughly half your traffic | Real breakpoint testing, tap targets, no horizontal scroll, usable with a thumb | | Keyboard only | Power users, screen reader users, broken trackpads | Full tab order, no traps, escape closes dialogs, enter submits | | Real data | Launch day | Long strings, missing fields, pagination, authentication, latency | The last row causes the most damage, and Builder.io says why: "Without real data, everything looks better than it is. Tools that rely on placeholders hide the messy realities of latency, authentication, and error states, the details that decide whether a product feels fast or broken." A generated interface with lorem ipsum names and three sample rows tells you almost nothing about whether the product works. Plug in your ugliest real record, the customer with the 90-character business name and no phone number, and most of this list announces itself in a minute.

Build to WCAG 2.2 Level AA. WCAG 2.2 has been the W3C Recommendation since October 2023, it is backward compatible with 2.1, it adds nine success criteria and it removes the old 4.1.1 Parsing criterion. Level AA is what regulators reference and what you should treat as the target. The nine criteria added in 2.2, which are the ones most likely to be new to you: | Criterion | Level | |---|---| | 2.4.11 Focus Not Obscured (Minimum) | AA (see note) | | 2.4.12 Focus Not Obscured (Enhanced) | AAA | | 2.4.13 Focus Appearance | AAA | | 2.5.7 Dragging Movements | AA | | 2.5.8 Target Size (Minimum) | AA | | 3.2.6 Consistent Help | A | | 3.3.7 Redundant Entry | A | | 3.3.8 Accessible Authentication (Minimum) | AA | | 3.3.9 Accessible Authentication (Enhanced) | AAA | Note on 2.4.11: sources disagree on whether it is Level A or AA. Check the W3C specification directly before quoting a level in anything that matters. The same caution applies to the commonly cited total of 87 success criteria with 55 at A and AA combined, which comes from accessibility vendor blogs that are not internally consistent. Verify both against the W3C specification itself. WCAG 3.0 is not a compliance standard and you should not be building to it. The most recent Working Draft was published on 3 March 2026 and reorganises guidance into roughly 174 requirements, replacing the A, AA and AAA pass or fail model with Bronze, Silver and Gold scoring, where Bronze is described as roughly equivalent to WCAG 2.2 AA. Estimates for a final Recommendation cluster around 2028 to 2030. Those figures and dates come from accessibility vendors rather than the W3C, so treat them as planning signals only. The short version: build to WCAG 2.2 Level AA now, watch WCAG 3.0, do not chase it.

95.9% of the top one million home pages had detected WCAG 2 failures in February 2026, up from 94.8% in 2025, reversing six consecutive years of small improvements (WebAIM, The WebAIM Million, 2026). The scale behind that number: 56,114,377 distinct errors across the million pages, an average of 56.1 errors per page, which is 10.1% worse than 2025's 51 per page. Average home page complexity reached 1,437 elements, up 22.5% in a single year. WebAIM's own caveat is important: "Because only automatically detectable WCAG failures were considered, this suggests that the rate of full WCAG 2 A/AA conformance was certainly lower than 4.1%." The useful part is how concentrated the failures are: | Failure type | Share of home pages, 2026 | |---|---| | Low contrast text | 83.9% | | Missing alternative text for images | 53.1% | | Missing form input labels | 51.0% | | Empty links | 46.3% | | Empty buttons | 30.6% | | Missing document language | 13.5% | WebAIM's framing: "96% of all errors detected fall into these six categories. These most common errors have been the same for the last 7 years. Addressing just these few types of issues would significantly improve accessibility across the web." Read that list against a generated interface and the overlap is almost exact. Contrast gets chosen for how it looks in a screenshot. Images arrive without alt text because the generator had nothing to describe. Inputs get styled with placeholder text instead of labels. Icon buttons ship with no accessible name. Four of the six most common failures on the web are the four things a prototype generator is most likely to hand you. One data-hygiene warning if you go looking for these numbers yourself. Several accessibility vendors are currently mis-attributing them, including one that labels the 95.9% figure as 2025 when it is 2026, and another that pairs a 2024 error count with a 2026 citation. Read the figures off WebAIM's own report rather than an aggregator.

The Disability Discrimination Act 1992 (Cth) applies to private-sector websites in Australia. It does so not by naming websites but by making it unlawful to discriminate in the provision of goods, services and facilities, and section 24 is the operative provision for access to services and information. The Act commenced on 5 November 1992 and is administered by the Australian Human Rights Commission on a complaints-based model. That distinction is worth stating precisely: there is no Australian regulator issuing proactive fines for an inaccessible website, and enforcement runs through individual complaints. Do not let anyone tell you Australian businesses face United States-style class action volume, because they do not. There is Australian case law. Bruce Maguire, who is blind, complained that the Sydney Organising Committee for the Olympic Games' official website was inaccessible, with missing alt text and inaccessible tables of athlete information. He relied on section 24 of the DDA, and the Human Rights and Equal Opportunity Commission, the Commission's predecessor, found in his favour in 2000. It was among the first decisions anywhere applying anti-discrimination law to web accessibility, and the W3C still uses the site as a case study. A note for anyone checking the primary sources: several articles online date this case to 2020. That is wrong, it was 2000. The regulator's published benchmark for private sites comes from the Commission's World Wide Web Access: Disability Discrimination Act Advisory Notes, version 4.1, 2014: "Non-government websites and web resources whose development commences after July 1 2010 should comply with WCAG 2.0 to a minimum of AA-Level conformance." The Notes also state the incentive plainly: "A complaint of disability discrimination is much less likely to succeed if reasonable steps have been taken to address accessibility during the design stage."

Four things could not be confirmed while researching this guide, and they are stated as open rather than implied as duties. Overstating an obligation that may not exist is worse than admitting the gap. The 2014 Advisory Notes have been replaced by the Commission's Guidelines on equal access to digital goods and services, issued under section 67(1)(k) of the Disability Discrimination Act 1992 (Cth) and section 11(1)(n) of the Australian Human Rights Commission Act 1986 (Cth). The Guidelines state that they "are not legally binding" and that an organisation "may not be protected from a finding of unlawful discrimination if they claim that they conformed with, or relied on, the Guidelines", while describing the standards they discuss as "the minimum organisations should aim for". Their publication date could not be established, because the Commission's site refused automated retrieval. Whether the Commonwealth Digital Service Standard currently requires WCAG 2.1 Level AA or 2.2 Level AA of government agencies is disputed between sources. Check with the Digital Transformation Agency before relying on either. A proposed set of Disability Standards for Digital Access is not in force, so treat it as proposed rather than law. Two requirements are settled and worth knowing. AS EN 301 549, adapted from the European standard and ratified in 2016, sets accessibility requirements for ICT procured by Australian public-sector organisations. And state anti-discrimination law applies alongside the Commonwealth Act, including the Victorian Equal Opportunity Act 2010 for anyone trading in Melbourne.

Run three passes over a generated interface before real users see it: a state coverage check, a responsive review, and an accessibility audit. Ministry of Programming uses the same three as its gate before engineering handoff, and they catch most of what a prototype hides. 1. State coverage. Walk the table above screen by screen. For each screen, deliberately produce the empty, loading, error and success state, and fix whatever is missing or ugly. Turn your network off mid-request at least once. 2. Responsive review. Open the real thing on a real phone, not a browser at a narrow width. Check tap targets, horizontal scroll, fixed elements covering content and forms with the keyboard open. 3. Accessibility audit. Run an automated checker first, because it catches most of the six failure types that account for 96% of detected errors on the web. Then do the manual part the checker cannot: tab through every screen with the mouse untouched, confirm the focus ring is always visible, confirm nothing traps focus, and read every image and icon button asking what a screen reader would say. One judgement call worth having in advance. Axelrod's advice on when to stop prompting a generated design applies here: "If the AI gives you a bad structure or generic copy, don't spend 3 hours trying to fix it with more prompts. Just stop... You are wasting time trying to teach a calculator how to paint." Missing states are fixable by prompting because they are mechanical. A structurally wrong interface is not, and that is a signal to design it yourself and generate the implementation.

buildAcademy is a small live Melbourne cohort for people who can build with AI tools but have not shipped to real users, and taking a generated interface through state coverage, mobile and accessibility is done on your own project. The list in this guide is long and none of it is difficult. It is just invisible until someone points at the empty screen you have never seen, or tabs through your form and cannot get to the submit button. Doing that pass once with someone experienced is how it becomes a habit rather than a document. See the curriculum and upcoming cohort dates at 13labs.au/buildacademy.

What is missing from an AI-generated UI? Every state except the happy one. Loading, empty, error, partial failure, validation, confirmation, hover and focus, mobile behaviour, keyboard navigation and behaviour with real data. As Ministry of Programming puts it, the invisible states often decide whether users trust a product, and generation tools skip them. Why do AI-generated sites all look alike? Because the model returns the statistically likely answer, and that is React with Tailwind and shadcn/ui defaults. It is not Tailwind's fault, since Tailwind has no inherent visual style. The fix is giving the tool your design tokens and component registry rather than describing a mood. Which accessibility standard applies in Australia? Build to WCAG 2.2 Level AA. The Australian Human Rights Commission's published benchmark for non-government sites developed after 1 July 2010 is at least WCAG AA conformance, and the Disability Discrimination Act 1992 (Cth) applies to private websites through section 24. Can an Australian business be sued over an inaccessible website? A complaint can be made to the Australian Human Rights Commission, and Maguire v SOCOG succeeded on that basis in 2000. Enforcement is complaints-based, with no regulator issuing proactive fines, which is materially different from the United States position. What is the fastest accessibility fix with the biggest effect? Contrast, alt text, form labels and accessible names on links and buttons. Six failure types account for 96% of all errors detected across the top million home pages, and they have been the same six for seven years (WebAIM Million, 2026).