Introduction

Open Components is the UXFront component standard: guidelines for building UI components with a perfect user experience, developer experience and agentic experience, whether humans or AI agents write them.

Learn the guidelines once, then hold every component to the same high standards, whether you or your agents write it.

The three layers

The standard has three layers, one for each audience a component serves. A component meets the standard when it meets all three.

User experience

Components behave the way people expect them to, with any input, on any device and for every ability.

• Accessible: keyboard, pointer, touch and screen readers, following WAI-ARIA.
• Predictable: the same interaction works the same way in every component.
• Every state: hover, focus, active, disabled, loading and error, all designed.
• Adaptive: respects motion, contrast, colour scheme and text size preferences.

Developer experience

One clear API, learned once and used everywhere. Knowing one component means knowing them all.

• Consistent: sizes, colours, states and events share their names everywhere.
• Type-safe: every prop, event and slot is typed and documented.
• Composable: small parts build larger ones, with no hidden coupling.
• Controllable: controlled or uncontrolled, with every state within reach.

Agentic experience

Components that AI agents can read, reason about and build with, so their output meets the same bar as yours.

• Semantic: roles, names and states agents can read straight from the markup.
• Described: anatomy, props and states, published as machine-readable specs.
• Deterministic: the same input always renders the same structure.
• Verifiable: rules agents can check their work against before shipping.

Foundations

Some rules hold for every component rather than for one. Design Tokens covers how to name the CSS variables behind them, a convention we call token paths, and the theme tokens they all share.

Components

Each component page holds one component to the three layers, and also covers how it looks, which we call its UI. Every page follows the same structure, so you and your agents always know where to look:

• At a glance: a single table with its element, role, keyboard support and options.
• UI: its anatomy, variants, colours, sizes, states and tokens.
• UX, DX and AX: the three layers, one trait at a time.
• Checklist: every rule, with a stable ID like button/keep-focus, a level, a scope that says whether the component or the code using it meets the rule, a basis that says where it comes from, like a WCAG success criterion or our own call, and a way to check it.
• Reference implementation: a component that does its part of every rule, along with its tests. The code is in Vue for now.

The Button is a great place to start, and the Roadmap lists the components we plan to ship next.

For agents

If your agent supports MCP, connect it to our MCP server at https://mcp.opencomponents.dev/mcp. It gives your agent the contracts, every rule and the docs as tools, so it reads a component's contract first, then only the sections it needs rather than the whole page.

Our agent plugin connects the server for you, along with skills that build and review components the way the standard asks, so your agent follows it without being told how. It works in VS Code, GitHub Copilot, Cursor, Codex, Claude Code and other clients that support Agent Plugins.

Every page of these docs is also published as markdown: prefix its path with /raw and add .md, as in /raw/docs/getting-started/introduction.md. /llms.txt lists every page, and /llms-full.txt holds them all in one file.

Pages that describe a contract, like the Button's, also publish it on its own, with every rule from their checklist: swap .md for .yaml, as in /raw/docs/components/button.yaml. It's a fraction of the page's length, for when an agent only needs the rules, and not the reasoning behind them.

Every contract follows the same JSON Schema, so you and your agents can validate one, including a contract you write for a component of your own. Each contract names the schema on its first line, so editors that use the YAML language server, like VS Code with its YAML extension, check it as you type.