Vibecoding has sped up development, including interface creation, but it has also brought back an old problem that the community has been trying to solve for over a decade — ever since HTML5 appeared.

Among a million pages, 50,960,288 different accessibility errors were found — an average of 51 errors per page. Source

Generated interfaces often suffer from “divitis”: links acting as buttons again, and images without alternative text.

To fix these problems, you can “teach” your IDE to generate accessible interfaces with just a few steps:

  1. Use UI component libraries that are accessible “out of the box”;
  2. Add rules for the agent to follow accessibility requirements in markup;
  3. Test the generated interfaces.

Choosing a UI Library

Fortunately, accessibility has become a trend, so many component libraries have already taken care of it — but it’s important to know your friends by sight. Here are some of them:

React/Next

  1. Radix and ShadCN — My personal top picks. Beautiful components, easy to assemble and use;
  2. Spectrum — Adobe is held to very high UI quality standards, so these guys know how to make them accessible;
  3. MUI — Production-ready components from Google.

Vue/Nuxt

  1. Radix and ShadCN for Vue — fewer components and theming options, but great for vibecoding;
  2. NuxtUI — A styled component set for Nuxt apps; I recommend using MCP to search components (sometimes hallucinates);
  3. Reka UI — Same idea as Radix, but without styling.

Svelte/SvelteKit

  1. Radix and ShadCN — Same as above, my favorite option;
  2. Melt UI — Unlike others, this one doesn’t provide ready-made components but a set of functions to build them from native HTML elements;
  3. Bits UI — A whole constructor of accessible components, similar to Radix.

The easier it is to use the components, the easier it will be for the agent, and the fewer tokens you’ll spend creating clean interfaces.

I recommend using ShadCN and TailwindCSS — the best combination for LLMs: fewer hallucinations, no need for special rules for this set.

For other combinations, I also recommend creating rules with detailed usage examples and an accessible set of components. Ideally, use MCP or local documentation for the component set you’ve chosen, and fix in the rules that before making template changes, the model should study the component set and its usage. This reduces hallucination risk, at the cost of some tokens.

About the Rules

Popular AI IDEs have rules you can configure globally or locally for your project:

  1. Cursor: ./cursor/rules/{rule_name}.mdc, can also be set in “Rules & Memory” in Cursor Settings;
  2. Windsurf: ./.windsurfrules;
  3. Claude Code: CLAUDE.md.

At minimum, you can add just a couple of lines to existing rules so the IDE knows not to assemble the UI carelessly:

Accessibility
- Ensure interfaces are keyboard navigable.
- Implement proper ARIA labels and roles for components.
- Ensure color contrast ratios meet WCAG standards for readability.

That should be enough to avoid “divitis”, but sometimes you need to assemble a complex component, combining library components with native tags to create something advanced.

I’ve created rules for Cursor that should work for any framework and component library — they include examples and more precise requirements: Rules for Cursor (.mdc). But for your app, I recommend creating your own rules considering your stack, framework, components, architecture patterns, and more. You can use a prompt for Claude to generate Cursor rules — you just need to fill in your stack details: Prompt for generating rules.

For other IDEs, follow the same approach.

Testing

You can’t make an interface for people without testing it yourself. After applying all rules and using a suitable library, simply try using your interface — for example, with a keyboard, then with a screen reader. Visually check that the markup isn’t overloaded with ARIA attributes, that ready-made components from the library were used, and that custom components follow accessibility guidelines.

Additional Resources and Tools

What’s Next?

Try integrating new rules into your pipeline and start testing your interfaces.

You can email me — I’ll be happy to help you set up your IDE, show you how to test, and explain how to convey the importance of accessibility to stakeholders — danila@katokdoes.art.