Ask Cursor to build a settings screen for a project management app, the one with Profile, Notifications, and Billing stacked down the left side, and a few form fields on the right. You'll have it in a few seconds, with hover states, even spacing, and a chevron that rotates when a section opens.

Now put the mouse away and press Tab.

Pressing Tab is how a person can move through a page without a mouse. Press it once, and the browser moves focus to the next link, button, or text field, and draws a focus ring around it so you can see where you are. Press Enter or Space, and you activate it. Hold Shift and press Tab to walk back the other way. For blind people using a screen reader and for people with tremors or limited hand movement, the keyboard is the only way to use anything on the page.

Each press of Tab moves the focus one element further along a fixed sequence called the tab order. The browser builds that sequence from the page's code, and it puts only links, buttons, and form fields in it. Profile, Notifications, and Billing on the screen Cursor just produced are none of those. They are div elements, the plain container HTML uses for grouping things, with a click handler attached, so a mouse click still works.

Nothing marks a container as a control, so the browser leaves all three out of the tab order sequence. Press Tab and focus goes from whatever sits above the list straight into the form fields on the right. The focus ring never reaches Profile, Notifications, or Billing.

Had the tool used real button elements for those three items, there would be nothing to fix. The browser puts a button in the tab order automatically, lets it take focus, and fires it on the press of Enter and Space, with no extra code needed. A div gets none of that, because as far as the browser knows, it is just a box.

A developer can rebuild each piece manually, adding an attribute that forces the div into the tab order and writing the code that makes Enter and Space work. But AI design generators rarely produce that code, and the people using them rarely know this code is missing.

Broken Keyboard Access

The settings screen is one example of a bigger pattern. Generators often put divs with click handlers instead of buttons and links in most interactive components:

• They often build broken pop-up dialogs. When a "Delete this project?" confirmation opens, the keyboard focus is supposed to move into it, stay inside it until it closes, and close it on pressing Escape. In the AI-generated pages, the pop-up covers the screen while the keyboard focus stays trapped in the page behind it, so pressing Tab moves through controls the person cannot even see, pressing Escape does nothing, and there is no way to press Cancel.
• They ship icon-only buttons with no names attached to them in the code. A screen reader works by reading each element out loud as a blind user moves through the page, and button names are what it often reads. When the name is missing, the person hears the word "button" and nothing else, with no way to tell what this button is supposed to do, and whether pressing it will save the form or delete the account.
• They ship broken dropdown menus. A real dropdown works from the keyboard: press Enter to open the list, move within it with the arrow keys, press Enter again to pick. Generators build dropdown menus as stacks of styled divs, and none of them work from the keyboard. The list opens on a mouse click only; the arrow keys don't select the dropdown elements, and the person using only the keyboard has no way of navigating to and opening that menu.

The broken dialogs and menus only become apparent when using a keyboard, while the next issue is obvious on any generated screen.

Fitts's Law and undersized buttons.

In 1954, psychologist Paul Fitts measured how long it takes to move a hand to a target. His work on airplane cockpits during and after World War II showed that many failures blamed on human error were caused by poorly designed controls and displays.

Fitts's Law states that the time required to reach a target depends on its size and distance. Make a target smaller or move it farther away, and it becomes harder to hit. The user must either move more slowly or accept more misses. Designers apply this principle to pointer targets, which is why frequently used actions receive larger buttons and why a tiny close icon in the corner of a banner is so difficult to click.

Generated interfaces often ignore Fitts's Law in the most direct way. Their buttons often come out too small. A study presented at the Web for All conference in April 2025 had ChatGPT and Claude generate the homepage of a banking app (ten interfaces for each combination of model and prompt) and measured the results.

When the prompt did not explicitly mention accessibility, interactive elements averaged 32 pixels, and quick-action buttons measured between 24 and 32 pixels. Accessibility guidelines recommend 44 by 44 pixels for touch targets, and the study's authors call the undersized buttons "potentially challenging for users with upper-body motor impairments." The generated buttons met the 44-pixel minimum only when the prompt spelled it out as an explicit requirement.

The Von Restorff Effect and Sameness

The next big failure is sameness. Open a few AI-generated landing pages, and the pattern becomes hard to miss: an indigo accent color, a purple-to-indigo gradient in the hero, Inter type, softly rounded cards, and the same sequence of sections, from hero to features to social proof to pricing to FAQ to footer.

In an August 2025 post on X, Adam Wathan, the co-founder of Tailwind CSS, jokingly apologized for using "bg-indigo-500" as a default color for Tailwind UI buttons, saying it had led to "every AI-generated UI on earth" becoming indigo.

The explanation people give for it is a feedback loop: Tailwind UI used indigo as a default, tutorials and starter templates copied it, models trained on that corpus, their outputs were republished, and the next training round contained even more indigo.

The UX law this breaks is the Von Restorff Effect, described by psychologist Hedwig von Restorff in 1933: when several similar objects are present, people remember the item that stands out from the group. But AI systems tend to reproduce familiar patterns from their training data unless the prompt gives them clear direction. Their default outputs may look polished, but they also look like every other page the tool produced that day.

Cognitive Load

The next failure is cognitive load. Every interface asks the user to hold information in mind, compare options, and decide what to do next. Our working memory is limited, and a good design directs that attention toward the task by giving people the information they need at the point they need it. A cluttered screen spends some of that limited capacity on itself, like an inefficient transmitter. That extra effort slows people down and makes mistakes more likely.

In 1956, George Miller argued that people can hold only a small number of items in immediate memory, often summarized as seven, plus or minus two. That idea became Miller's Law. While the exact number of items is not a hard rule and is debatable (even Miller himself thought it was probably a coincidence), the useful lesson is that working memory is limited, and every extra element on a screen competes for it.

A 2026 study tested this with 62 people across four screen designs: a health dashboard, a learning dashboard, an e-commerce cart, and a student portal. Each person used three versions of each screen: one designed by a person, one generated by AI from a basic prompt, and one generated by AI after the prompt had been refined.

People completed every task correctly on the human-designed screens, but on the raw AI-generated screens they succeeded only 63% of the time. More than one in three attempts failed. The AI-generated screens also had the highest perceived cognitive load and visual complexity, took longer to evaluate, and were rated as harder to use.

Once the prompts were refined, the AI-generated screens reached the same 100% task accuracy as the human-designed ones. As with the undersized buttons, the problem improved when someone knew what to ask for.

Some tools avoid these problems better than others. Vercel’s v0 generates interfaces using the shadcn/ui component library by default. shadcn/ui gives developers source code for reusable interface components, which they can copy into their projects. Many of its interactive components are built on Radix Primitives, a library designed to handle difficult accessibility behavior such as keyboard navigation, focus management, and the information screen readers need to interpret an element correctly.

A Radix dialog manages focus while it is open, returns focus when it closes, and supports Escape to dismiss it. Those behaviors come from code written and tested by people. v0 can reuse that work when it selects the right component, so a screen built from established buttons, dialogs, and menus inherits much of their accessible behavior. But when v0 needs something the library does not provide, it has to generate the behavior itself. And then the library's safeguards do not extend to those new parts.

The library also cannot make visual or structural decisions for the model. It does not choose the page's colors, ensure sufficient contrast, or decide whether a layout is understandable and logically grouped. Reusable components can solve many interaction problems, but they cannot guarantee that the screen built from them is fully accessible or designed efficiently for the task at hand.