Roadmap

Open Components grows one component at a time. We'd love to cover every component you reach for, but a page only helps you if you can trust it, so we write each one in full before we move on to the next. This page shows you where we are, and what's coming next.

Every component gets a page with the same structure as the Button's, so you always know where to look:

• User Interface (UI) - how it looks, from its anatomy to its tokens
• User Experience (UX) - how it behaves for every person and every input
• Developer Experience (DX) - how developers work with it
• Agentic Experience (AX) - how agents can read and verify it

On top of that, each page comes with a checklist of every rule, a contract your agents can check their work against, and a reference implementation that does its part of every rule, along with the tests that prove it. That's a lot to get right, so a page only ships once all of it is ready. We'd much rather give you one page you can rely on than several you can't.

Components

Here's every component we plan to cover. A tick means its page has shipped, so you can read it today.

We've grouped them by what they build on, so each group can reuse what the ones before it have already settled, like the Button's sizes and colours, or how the Dialog handles focus. The order may still change as we go, and you can help shape it.

Actions and forms

Let's start with the components people use to act and to fill in forms. The Button sets the sizes, colours and states that every other component shares, and the form controls build on them with the labels, hints, validation and controlled values that every form needs.

Overlays

Next come the components that sit on top of the page. They all need to take focus and give it back, close with Escape or a click outside, and stack in the right order, so we'll settle those rules once and share them.

Navigation and disclosure

These help people find their way around a site, or show and hide what's on a page. Most of them build on the Link and the Button, and add the keyboard support people expect, like moving between tabs with the arrow keys.

Feedback and display

These tell people what's going on, and most of them aren't interactive at all. That's why their rules are mostly about meaning and contrast, and about making sure screen readers hear about what changes.

Later

Finally, the composite widgets. They have the most keyboard behaviour of all, and they build on almost everything above, which is why they come last. A combobox, for example, is an input, a popover and a list working together.

Before a page ships

You don't have to wait for a page to hold a component to the standard. The three layers in the Introduction apply to every component, Design Tokens covers how to name its variables, and the Button shows how the layers turn into rules you can check.

Your agents can do the same. Point them at /llms-full.txt, which holds the whole standard in one file, and ask them to follow the Button's structure. For a component that doesn't have its page yet, you could use:

Build a Tabs component for our design system that meets the Open Components standard:
https://opencomponents.dev/llms-full.txt

There's no Tabs page yet, so follow the Button page's structure. Work through the UI,
UX, DX and AX of tabs, following the WAI-ARIA Tabs pattern, then write a checklist with
a stable ID for every rule, like tabs/arrow-keys, and a test for each one.

Suggest a component

Is a component you need missing, or further down the list than you'd like? Open an issue and tell us what you're building with it. Knowing what you need helps us decide what comes next.