Changelog

Our MCP server gives your agents the standard as tools, but they still need to know when to reach for it, and its prompts only run when you start them. Our agent plugin brings the two together: skills that your agent picks up on its own whenever it builds or reviews a component, and the MCP server they read the standard from.

New

• Install it in VS Code, GitHub Copilot, Cursor, Codex, Claude Code and any other client that supports Agent Plugins, the open format for packaging skills and MCP servers.
• Its skills build a component in your framework, review one or how a screen uses it, reporting every rule by its ID, and move your CSS variables to token paths.
• Where your client doesn't connect MCP servers, the skills read the same contracts and pages from this site.

Inputs are where people tell you things, and they look so simple that they're often built in a hurry. The Input page walks you through building one the right way, from a label that doesn't disappear as people type to an error message that says how to fix what's wrong.

New

• The Input has the Button's sizes, so the two line up in a row, and slots for icons, prefixes and suffixes, and for buttons like Show password.
• Its border has 3:1 against the page, so people can always see where to type, and its invalid look comes from aria-invalid, so it always matches what screen readers announce.
• Its checklist covers how forms use it too, like giving every input a label and an autocomplete value, checking values when people leave an input rather than while they type, and never blocking paste.
• It comes with its own contract, live examples and a tested reference implementation.

A spinner is one of the simplest components there is, and still easy to get wrong. The Spinner page walks you through showing that something is busy, and making sure everyone hears what's loading and how it went, since the spinner itself stays silent.

New

• The Spinner takes its size and colour from the text around it, stays hidden from screen readers and stops turning when someone prefers reduced motion.
• Its checklist covers how screens use it too, like showing one spinner per wait, saying what's loading in a status message and leaving focus where it was.
• It walks you through every state of the wait it shows, from busy to done or failed, and what to say when it's taking longer than expected.
• It comes with its own contract, live examples, a tested reference implementation and a browser test that checks what screen readers and agents find while the page waits.

Improved

• The Button shows the Spinner while it's loading, so changing your spinner once changes it everywhere.

Agents do their best work with just what a task needs, but a component page holds far more than that: the Button's alone is about 35,000 tokens. Our MCP server, at https://mcp.opencomponents.dev/mcp, gives your agents the standard as tools instead, so they read a component's contract first, then only the sections and rules their task needs.

New

• Connect it to Claude, Codex, Cursor, VS Code, GitHub Copilot, Gemini CLI, Grok, Hermes Agent or any other client that supports remote MCP servers. It's free, with no sign-in.
• Its tools read a contract, list the rules that apply to your task, read a page a section at a time in your framework, search the whole standard and return the reference implementation.
• Its prompts build a component, review one or how a screen uses it, reporting every rule by its ID, and move your CSS variables to token paths.

Contracts give agents every requirement for a component in one YAML file, so a field that's missing or misspelled leads them astray without a word. They now all follow one published JSON Schema, which catches those mistakes before anyone relies on the contract.

New

• Every contract names the schema on its first line, so editors that use the YAML language server check it as you type.
• The schema covers components and conventions alike, so you can validate the contracts you write for your own components too.
• We validate every contract on this site against it on every change, so the ones we publish always pass.

Most of our rules rest on WCAG, but some go further, and some are our own. Every checklist now has a Basis column that tells them apart, so you know when a rule is something WCAG asks for at level AA, and when it's a call we've made.

New

• Every rule in the Button and Design Tokens checklists names its basis: the WCAG 2.2 success criteria behind it and their level, HTML, WAI-ARIA or the APG, or Open Components for our own rules.
• Contracts include each rule's basis too, so your agents can tell the rules apart as well.

Improved

• button/focus-visible asks for an outline at least 2px thick, rather than exactly 2px, and the Button page says what we recommend for the details you can change and still meet the standard, like the ring's offset or the opacity of the state layers.

Fixed

• button/keep-focus now covers a button that can be disabled while it has focus, like Next on the last page, which stays focusable. Before, it said a focused button is never natively disabled, which no Button could promise on its own.
• button/focus-not-obscured now cites WCAG 2.4.12 as well as 2.4.11, since it asks that a focused button isn't covered at all.

Buttons are the most common interactive component in any interface, and also the one we most often get wrong. Our first component page walks you through building one the right way, and every component page after it will follow the same structure.

New

• It covers how a button looks, how it behaves for every person and every input, how developers work with it and how agents can read and verify it.
• Every example is live, and its code comes in React, Vue, Svelte, Angular, Solid, Astro and Vanilla.
• A checklist, a contract for agents and a tested reference implementation help you hold your own buttons to the standard.

Every component reads its colours, sizes and spacing from CSS variables, and their names are all that people, tools and agents have to go on. Our first Foundations page shows you how to name them, so that everyone reads them the same way.

New

• Token paths, like --color--primary, give every token a name that can only be read one way.
• Every component reads the same theme tokens, so a new brand or a dark mode never means editing every component.
• A Stylelint rule and a checklist let you and your agents check your tokens automatically.