Accessible by Construction: @angular/aria In short: Building a dropdown that works properly for keyboard and screen-reader users is a week of work most projects never budget. , new in v21 and final in v22, gives you that work for free while you keep full control of how it looks. Ask a good frontend developer to build a searchable dropdown and you will get something that looks right and works with a mouse. Ask what happens when a screen-reader user presses Home, or types three letters quickly, or presses Escape while the list is filtered — and you will usually get a pause. That is not a criticism. These patterns are genuinely intricate. What "headless" means here The directives draw nothing and style nothing . You write all the HTML and all the CSS. They contribute exactly three things: 1. Keyboard behaviour — arrow keys, Home and End, type-ahead, Escape, tab order, wrapping 2. Accessibility information — the roles and states that screen readers announce, and the relationships between elements 3. Focus handling — one tab stop for the whole group, focus returning correctly when things close This is the opposite trade to Angular Material , which gives you behaviour and a fixed visual design. If your product has its own look, Material means fighting its styles. means writing your styles from scratch but never thinking about screen-reader details again. The eight patterns Thirteen unstyled pieces across eight standard patterns: Pattern What it covers --- --- Listbox Choosing one or several items from a list Combobox A box plus a popup — search, select, multi-select Menu Action menus with sub-menus, checkboxes, and radio items Tabs Tab strips and panels Accordion Expandable sections Tree Nested, expandable navigation Grid Two-dimensional keyboard movement Toolbar Grouped action buttons What using one looks like Your HTML, your classes, your styles. What you get without writing it: arrow-key movement with wrapping, Home and End, type-ahead, the correct roles, selection state kept up to date, one tab stop for the whole list, and the right element announced as focused. Styling from the accessibility state — rather than a class you maintain — is the recommended way, and it means the visual state and the announced state cannot drift apart . Tabs, for comparison Arrow keys move between tabs, Home and End jump to the ends, panels are correctly linked to their tabs, and the strip is a single tab stop with the panel next in order. All of that is the standard tabs pattern, and all of it is easy to get subtly wrong by hand. Where this sits next to other options Angular Material — behaviour plus Material Design. Right when you want that look or can accept it. Harder to restyle. — behaviour only. Right when you have your own design and want to own the HTML. This is the new option and the reason the package exists. Outside headless libraries — similar idea, but a dependency that has to keep up with Angular versions. Building it yourself — now hard to justify for any of the eight patterns. The main reason people did was that no headless option existed in Angular. What it does not do Worth being clear, because "we use " is not the same as "we are accessible." It handles keyboard, announcements, and focus for these specific patterns. It does not handle colour contrast, visible focus styling, image descriptions, heading structure, form labels, motion preferences, or anything about your own components. Those remain yours. What it removes is the hardest kind of accessibility bug to catch : a control that looks and mouse-clicks correctly while being unusable with a keyboard or a screen reader. Automated checking tools largely do not catch those, because the HTML can pass every check while the behaviour is wrong. Adopting it There is no migration. It is purely additive: 1. New complex controls — start here 2. Existing controls with known accessibility problems — replace the behaviour, keep your HTML and styles 3. Existing controls that work — leave them Because it is headless, replacing a hand-built dropdown usually means keeping the entire template and adding directives, then deleting the keyboard handling you were maintaining. That is often a net deletion. The architect's view The build-versus-adopt decision here is unusually one-sided , and it is worth understanding why, because the reasoning generalises. Normally "build it ourselves" trades effort for control. With accessible components that trade does not hold, for two reasons. The requirements are externally defined. Standard patterns specify exactly which keys must do what, which states must be announced, and where focus must go. This is not a place for product-specific judgement — there is a correct answer, and it is published. You cannot easily tell whether you got it right. Automated tools check the markup, not the interaction model. A widget can pass every automated check while being unusable with a keyboard. Verifying by hand means testing with a screen reader, which most…