ARIA widget patterns

The problem: a widget that lies

A team builds a country picker. It is a div that shows the selected country, and a click opens a ul of 195 countries. It looks like every select box on the web. A sighted mouse user picks "Portugal" in two seconds.

A screen reader user tabs to it and hears "Portugal, group". Or nothing at all, because the div is not focusable. If a developer added tabindex="0", pressing Down Arrow scrolls the page instead of moving through countries. The screen reader has no idea a list opened, how many items it has, or which one is chosen.

Then someone adds role="menu" to the list because it "pops up like a menu". Now the screen reader switches into a mode for application menus, announces "menu, 195 items", and expects keys like a desktop File menu. The user is told the widget is something it is not. That is worse than no ARIA at all.

What ARIA is, and what it is not

ARIA, Accessible Rich Internet Applications, is a W3C spec of attributes that tell assistive technology what an element is and what state it is in. It has three kinds of attributes: a role says what the thing is (role="tab"), a state says something that changes often (aria-selected="true"), and a property says something more stable (aria-controls="panel-1").

ARIA changes only the accessibility tree, the parallel tree of names, roles, and states that the browser builds from the DOM and hands to screen readers through the operating system's accessibility API. It does not add behavior. role="button" does not make a div focusable, does not fire on Enter, and does not fire on Space. Every key in a custom widget is your code.

That is why the semantic HTML lesson starts with the first rule of ARIA: if a native element does the job, use it. A button, a select, a details element, and a dialog element bring their role, focus, keys, and states for free. ARIA is for the widgets HTML does not have: a combobox with filtering, a tab list, a tree, a data grid.

Why patterns, and not just attributes

A role is a promise. When a screen reader hears role="tablist", it tells the user "tab list, tab 2 of 4" and the user, who has used tabs in a hundred apps, reaches for the arrow keys. If your tabs only respond to Tab and Enter, the promise is broken and the user is stuck.

So the unit of work is not one attribute. It is a pattern: a role structure, the states that must stay in sync, and a keyboard contract, all three together. The ARIA Authoring Practices Guide (APG), published by the W3C's Web Accessibility Initiative, writes down these patterns for about 30 common widgets, each with working examples you can try with a keyboard and a screen reader.

WebAIM's yearly scan of the top one million home pages keeps finding that pages with ARIA have more detected accessibility errors on average than pages without it. ARIA is not the cause on its own, but ARIA used without a pattern is a common source of errors. Picking a pattern and following it fully is how you avoid that.

What this lesson covers

This lesson walks through the APG patterns you meet in real products: combobox, listbox, menu and menubar, tabs, dialog and alertdialog, disclosure and accordion, tree, and grid. For each one you get the roles, the states, the keys, how focus moves inside it, and the mistakes that show up in audits. Then you learn how to pick the right pattern for a design, and how to test it with real screen readers.

It builds on three published lessons: semantic HTML (native elements and the first rule of ARIA), keyboard navigation (roving tabindex and aria-activedescendant in general), and focus management (dialogs, inert, and where focus goes when content changes). Here we join them into full widgets.

The mental model: a pattern is a contract with four clauses

Think of road signs. A red octagon means stop in every town, so drivers react without reading the small print. If one town painted its stop signs blue, drivers would sail through. ARIA patterns are the road signs of widgets: a tab list is announced the same way and answers to the same keys on every site, so users already know how to drive it.

Every APG pattern is a contract with four clauses. Learn to read any pattern through these four and you can build one you have never seen before.

1. Structure: which roles, and how they nest. Some roles have required owned elements: a listbox must contain options, a tablist must contain tabs, a menu must contain menuitems. Some have a required context: an option only means something inside a listbox.
2. Name: every widget needs an accessible name, from aria-labelledby pointing at visible text, from aria-label, or from its content. A listbox called "listbox" tells the user nothing.
3. States: the attributes that change as the user acts (aria-expanded, aria-selected, aria-checked, aria-activedescendant). They must change in the same render as the visual change, every time.
4. Keyboard and focus: which keys do what, and how focus moves between the items. This is the clause most often skipped, and the one users notice first.

Why structure matters so much

The screen reader works out position from the structure. When focus lands on the third tab inside a tablist of four, it says "Pricing, tab, selected, 3 of 4". The count comes from the role tree, not from any attribute you wrote. Put a wrapper div with role="presentation" in between and that still works; put a focusable button or a div with its own role in between and the tree is invalid, and screen readers may lose the count or the role.

The same structure feeds tools. axe-core, the rule engine behind Lighthouse's accessibility audit and many test setups, has rules like aria-required-children and aria-required-parent that catch a broken role tree. They cannot check the keyboard clause, though. That part needs a human or an end-to-end test.

The two ways to move inside a widget

Composite widgets, the ones made of many items, are a single tab stop. Inside, arrow keys move an active item. There are two ways to tell the browser and the screen reader which item is active. The keyboard navigation lesson covers both in general; here is how they map onto patterns.

Roving tabindex moves real DOM focus. The active item has tabindex="0", every other item has tabindex="-1", and on each arrow key you swap the values and call .focus() on the new item. The browser scrolls it into view, :focus-visible styles it, and every screen reader follows real focus.

aria-activedescendant keeps DOM focus on one element, the container or an input, and points at the active item by id: aria-activedescendant="opt-7". The screen reader announces opt-7 as if it had focus. You must style it yourself (it does not match :focus), scroll it into view yourself, and keep the id in the same document, since the reference does not cross a shadow root.

<ul role="listbox" aria-labelledby="city-label">
  <li role="option" tabindex="0" aria-selected="true">Lisbon</li>
  <li role="option" tabindex="-1" aria-selected="false">Lima</li>
  <li role="option" tabindex="-1" aria-selected="false">Lyon</li>
  <li role="option" tabindex="-1" aria-selected="false">Leeds</li>
  <li role="option" tabindex="-1" aria-selected="false">Lagos</li>
</ul>

Choosing a value: listbox and combobox

The most common custom widget is some kind of picker: a country, a user to assign, a font. Two APG patterns cover it. A listbox is a list of options that is always visible, where the user picks one or more. A combobox is an input, usually a text field, with a popup of suggestions that appears as you type or press Down Arrow.

Before either, ask if a native select works. It brings a role, a name from its label, type-ahead, and a picker that suits the platform, including the large touch picker on phones. A datalist attached to an input gives simple suggestions for free. Build a custom one only when you need rich options (avatars, two lines of text), filtering on the server, or styling the native control cannot reach.

Listbox

• Structure: role="listbox" containing role="option" elements. Group options with role="group" and a label. Options are plain text: no links or buttons inside.
• Name: aria-labelledby pointing at the visible label.
• States: aria-selected="true" on the chosen option. For many choices, add aria-multiselectable="true" to the listbox and set aria-selected on each option, true or false.
• Keys: Up and Down move, Home and End jump to the ends, typing a letter jumps to the next option starting with it (type-ahead). In a multi-select list, Space toggles the active option and Shift+Down extends the selection.

A common mistake is a listbox of items that each contain a delete button. Options cannot hold interactive children: the screen reader flattens each option to its text, so the button is lost. If each row needs actions, the pattern is a grid, or a plain list of buttons.

Combobox, the ARIA 1.2 way

The combobox pattern changed twice. In ARIA 1.0 the role went on the text input; ARIA 1.1 moved it to a wrapper around the input; ARIA 1.2 (2023) moved it back onto the input. Many old tutorials and libraries still show the 1.1 wrapper. Follow 1.2: role="combobox" goes on the focusable input itself.

<label id="city-label" for="city">City</label>
<input id="city" type="text"
  role="combobox"
  aria-autocomplete="list"
  aria-expanded="true"
  aria-controls="city-list"
  aria-activedescendant="city-opt-2" />
<ul id="city-list" role="listbox" aria-labelledby="city-label">
  <li id="city-opt-1" role="option">Lisbon</li>
  <li id="city-opt-2" role="option" aria-selected="true">Lima</li>
  <li id="city-opt-3" role="option">Lyon</li>
</ul>
<div role="status" class="sr-only">3 suggestions</div>

• aria-expanded tells the user the popup is open. Set it to false, not remove it, when closed.
• aria-controls points at the popup's id. Older versions used aria-owns for this; 1.2 uses aria-controls.
• aria-autocomplete says what typing does: list shows suggestions, inline completes the text in the field, both does both, none means the list does not change as you type.
• aria-activedescendant names the highlighted option. Empty it when nothing is highlighted, and when the popup closes.
• The popup is usually a listbox, but 1.2 also allows a grid (rows with several cells), a tree, or a dialog. Set aria-haspopup on the input when the popup is not a listbox; listbox is the default.

The combobox keyboard contract

Focus never leaves the input. That is why the combobox is the one pattern that needs aria-activedescendant: if you moved DOM focus to an option, the next letter the user types would land on the option, not in the field.

Two details separate a good combobox from a passable one. First, announce the number of results in a polite live region (role="status") after the list updates, debounced so it does not speak on every key press. Second, keep option ids stable across result updates, for example from the record's id, so a highlight on "Lima" still points at Lima when new results arrive. The autocomplete guide builds the full component, including racing requests.

Running commands: menu, menubar, and why your nav is not a menu

In ARIA, menu has a narrow meaning: a list of commands or choices, like the File menu of a desktop app. Edit, Duplicate, Archive, Delete. It is not "anything that pops up" and it is not "the navigation at the top of the site". Getting this one wrong is the most common pattern mistake on the web.

The menu button pattern

• Structure: a button with aria-haspopup="menu" (or true, which means the same) that opens a role="menu". Items are role="menuitem", or menuitemcheckbox and menuitemradio for toggles, each with aria-checked. Use role="separator" between groups.
• Name: the menu gets aria-labelledby pointing at its button.
• States: the button has aria-expanded="true" while the menu is open, false while closed. Disabled items get aria-disabled="true" and stay focusable, so users can find them.
• Focus: opening the menu moves focus to the first item (Enter, Space, or Down) or the last item (Up). Items usually use roving tabindex (the APG has examples of both focus models). Escape closes the menu and puts focus back on the button. Tab closes the menu and moves on in the page.
• Keys inside: Up and Down move (wrapping from the last item to the first is optional), Home and End jump, a letter jumps to the next item that starts with it, Enter activates and closes. Space toggles a checkbox item.

Menubar

A menubar is the horizontal bar of an app, like File, Edit, View in Google Docs. It is one tab stop: Left and Right move between top items, Down opens a submenu, and inside a submenu Right opens a nested submenu and Left closes it. Few websites need one. If your product is a document editor or an IDE in the browser, it may.

Why site navigation should not be role=menu

A site header with a "Products" dropdown full of links looks like a menu, so developers add role="menu" and role="menuitem". Three things go wrong.

1. Links stop being links. A menuitem role replaces the link role, so the screen reader no longer says "link" and users lose their link habits: the links list in the screen reader, open in a new tab, and knowing the item goes somewhere.
2. The keyboard contract changes. Screen readers switch to a mode where keys go to the page, and users press arrows, not Tab. Your nav probably only handles Tab, so they are stuck. If it does handle arrows, Tab now leaves the whole menu, which surprises sighted keyboard users who expected Tab to walk through the links.
3. Content is lost. A menu may only contain menu items, groups, and separators. A mega menu with headings, short descriptions, and a promo card cannot be a valid menu.

The right pattern for site navigation is the disclosure: a nav landmark, a button with aria-expanded that shows or hides a plain list of links, and Tab to move through them. Escape closing the open panel and returning focus to its button is a good extra. The APG has an example for exactly this, the disclosure navigation menu.

Real products split along this line. Overflow "..." buttons that run commands on an item, like the action menus in GitHub's Primer design system, are menus. The GOV.UK header, like most marketing site headers, shows links, so it uses buttons with aria-expanded that reveal lists of links: disclosure navigation. Ask what the items do, not what the popup looks like.

Showing and hiding: tabs, disclosure, and accordion

Three patterns hide some content and show it on demand. They look alike in a mockup, and the difference is in how many sections can be open and how the user moves between them.

Tabs

Tabs show exactly one of several panels in the same place: Overview, Specs, Reviews on a product page, or Code, Issues, Pull requests on a repository. The parts:

• Structure: role="tablist" containing role="tab" elements (use buttons), and one role="tabpanel" per tab.
• Name: the tablist gets aria-label or aria-labelledby; each panel gets aria-labelledby pointing at its tab, so entering the panel announces "Specs, tab panel".
• States: aria-selected="true" on the current tab, false on the others. Each tab's aria-controls points at its panel. Hidden panels get the hidden attribute.
• Focus: roving tabindex. Only the selected tab has tabindex="0". Tab from the tab list goes into the panel. If the panel starts with text, not a focusable control, give the panel tabindex="0" so Tab lands on it.
• Keys: Left and Right move between tabs and wrap at the ends; Home and End jump. For a vertical tab list, set aria-orientation="vertical" and use Up and Down.

Tabs have one real design choice: automatic or manual activation. With automatic activation, moving to a tab with an arrow key also shows its panel. With manual activation, arrows only move focus and the user presses Enter or Space to show the panel.

Disclosure

A disclosure is one button that shows or hides one piece of content: "Show more", "Advanced options", a FAQ answer. It is the simplest pattern in the APG: a button with aria-expanded, and optionally aria-controls pointing at the content. Enter and Space toggle it. There is no role for the content and no arrow keys.

The native details and summary elements are a disclosure with no script. Browsers expose the open state. The name attribute, supported in all major browsers since 2024 (Chrome 120, Safari 17.2, Firefox 130), groups several details elements so only one stays open: an exclusive accordion with no JavaScript at all.

Accordion

An accordion is a stack of disclosures with headings. Each header is a real heading (h3, at the right level for the page) that contains a button with aria-expanded and aria-controls. The heading lets screen reader users jump between sections with the H key; the button does the toggling.

Panels may get role="region" with aria-labelledby pointing at their button, which makes each open panel a landmark. The APG advises against that when many panels can be open at once, because a page full of regions makes the landmark list useless. Up and Down between headers, Home and End, are optional extras; Tab already works.

Interrupting: dialog and alertdialog

A modal dialog is a window over the page that the user must deal with before going back: a sign-in form, a confirm step, an image editor. The focus management lesson covers the focus side in depth (where focus goes on open, inert, returning focus on close) and the modal dialog guide builds one. Here is the pattern itself.

The dialog contract

• Structure: role="dialog" on the container, with aria-modal="true" when the page behind is blocked. Everything outside the dialog must be unreachable, which inert on the rest of the page or the native modal dialog gives you.
• Name: aria-labelledby pointing at the dialog's heading. Add aria-describedby only for a short message that should be read on open, not for a long form.
• Focus on open: to the first focusable control in most cases; to the heading or the start of the content (with tabindex="-1") when the dialog opens with text the user should read first.
• Keys: Tab and Shift+Tab cycle inside the dialog. Escape closes it. On close, focus returns to the control that opened it.

The native dialog element opened with showModal() does most of this for you. It gets the dialog role, makes the rest of the page inert, puts it in the top layer above every z-index, closes on Escape through the cancel event, and returns focus to the opener on close in current browsers. Prefer it to a hand-built div with role="dialog".

<button type="button" id="rename-btn">Rename</button>

<dialog id="rename" aria-labelledby="rename-title">
  <form method="dialog">
    <h2 id="rename-title">Rename file</h2>
    <label for="name">New name</label>
    <input id="name" name="name" autofocus />
    <button value="cancel" formnovalidate>Cancel</button>
    <button value="save">Save</button>
  </form>
</dialog>

<script>
  const dialog = document.getElementById("rename");
  document.getElementById("rename-btn")
    .addEventListener("click", () => dialog.showModal());
</script>

Alertdialog

An alertdialog is a modal dialog whose purpose is an urgent message that needs a response: "Delete 12 files? This cannot be undone." The role tells assistive technology it is an alert, so screen readers can treat it like a system alert and read the message right away. Give it aria-describedby pointing at the message, so the user hears both the title and the question.

Where focus goes matters more here. For a destructive confirm, focus the least destructive button, Cancel, so an Enter pressed by habit does not delete anything. With a native dialog, add role="alertdialog" to the element and put autofocus on Cancel.

Things that are not dialogs

• A toast ("Message sent", "Undo") does not take focus. It is a live region: role="status" for polite news, role="alert" for errors. If it has an Undo button, give users time to reach it and make it reachable from the keyboard.
• A popover with a few links, like a user card on hover, is not modal. Use the popover attribute or a disclosure. It should close on Escape, but the page behind stays usable.
• A cookie banner usually should not be modal either. A bottom bar that users can tab to and dismiss is less hostile, and it must not entirely hide the focused element (WCAG 2.2, success criterion 2.4.11, Focus Not Obscured).

Hierarchies and two dimensions: tree, grid, and table

The last two big patterns are the heaviest. A tree shows nested items you expand and collapse, like a file explorer. A grid is a set of cells you move between in two directions, like a spreadsheet or a calendar. Both are a single tab stop with a large keyboard contract, so build them only when the simpler options fail.

Tree view

• Structure: role="tree" containing role="treeitem" elements. A parent item's children sit in a role="group" inside it. Leaves have no aria-expanded at all.
• States: aria-expanded="true" or false on parent items; aria-selected for the selected item (or aria-multiselectable on the tree for many). If only part of the tree is in the DOM, add aria-level, aria-setsize, and aria-posinset so position is still announced: "src, level 2, 3 of 7, expanded".
• Keys: Up and Down move through the visible items; Right on a closed parent opens it, on an open parent moves to its first child; Left on an open parent closes it, on a child moves to its parent; Home and End jump; type-ahead jumps by first letter; * optionally expands all siblings.
• Focus: roving tabindex on treeitems is the common choice; aria-activedescendant on the tree also works.

Watch for one trap. A docs sidebar with nested sections is a tree in shape, but users only need to reach links. A nav with nested lists and disclosure buttons for the sections is easier to build and to use: Tab through the links, Enter on a button to expand. Use a real tree when users act on items in place, like selecting, renaming, or dragging files, as in VS Code's explorer.

Grid

A grid in ARIA is an interactive widget, not a look. It is for content where the user moves focus between cells: a spreadsheet, a date picker's month view, an inbox where each row has a checkbox, star, and actions. The structure is role="grid", role="row", and role="gridcell", with columnheader and rowheader for headers. A native table with these roles added works well because the structure is already there.

• Keys: all four arrows move by one cell; Home and End go to the start and end of the row; Ctrl+Home and Ctrl+End go to the first and last cell; Page Up and Page Down move by a screenful of rows.
• Cells with controls: if a cell holds one button, focus goes on the button itself. If a cell holds an editor, Enter or F2 enters it and Escape returns to cell navigation. While editing, the arrows move the text caret, not between cells.
• Large data: with virtualized rows, set aria-rowcount on the grid and aria-rowindex on each row, so "row 5,341 of 10,000" is announced even though only 40 rows are in the DOM. The virtualization lesson covers the rest.
• Selection and sorting: aria-selected on rows or cells; aria-sort="ascending" on the header of the sorted column.

Grid or table?

If users only read the data, use a plain table with th headers and scope. Screen readers have rich table commands for it (in NVDA and JAWS, Ctrl+Alt plus an arrow moves by cell and reads the header), and every cell's text is reachable in reading mode. Turning a read-only table into a grid takes those away and adds a keyboard contract the user did not ask for.

Use a grid when cells are the thing you act on: a calendar where arrow keys move between days, a spreadsheet, a data grid with inline editing. The APG also has treegrid for rows that expand into child rows, like an email thread view or a file list with folders. It is the hardest pattern in the guide; reach for it last.

Picking the right pattern

Most ARIA bugs are not typos. They are the wrong pattern, chosen because of a word in the design file. "Dropdown", "menu", "tabs", and "popup" describe how something looks. The pattern depends on what the user is doing with it.

Four questions, in order

1. Does a native element do it? button, a, select, input with datalist, details, dialog, table, radio buttons in a fieldset. If yes, stop. You get the behavior, the platform's look on mobile, and years of browser and screen reader testing.
2. What does the user do with it? Go somewhere (links), run a command (button or menu), choose a value (select, listbox, combobox, radio group), reveal content (disclosure, accordion, tabs), answer a question that blocks the page (dialog), or work with structured data (table, grid, tree).
3. How many things at once, and in how many directions? One panel open or many (tabs or accordion); one value or many (aria-multiselectable); one direction (listbox, tree) or two (grid).
4. Where must focus stay? If the user must keep typing while choosing, it is a combobox and the focus model is aria-activedescendant. Otherwise use roving tabindex.

Lab: from a UI description to a pattern

Pick a piece of UI from a real product below. The lab shows the pattern that fits, the roles and states you need, the keys you must handle, and the mistake teams most often make with it. Try to name the pattern before you look.

Same look, different pattern

The same visual can need different patterns. A button with a chevron that opens a list can be four things, and a careful candidate names the difference out loud.

Failure modes and testing with screen readers

A pattern can pass every automated check and still be unusable. The role tree may be valid while the keys do nothing, or a state may update a frame late. This chapter lists what breaks in production and how to catch each kind of bug.

What breaks in production

Two cross-cutting issues deserve their own note. First, shadow DOM: ARIA id references like aria-labelledby and aria-activedescendant do not cross a shadow root today, so a web component library that puts the input in one shadow root and the listbox in another breaks the combobox. Proposals such as reference target are working their way through standards; until they ship everywhere, keep related parts in the same tree.

Second, mobile. Touch screen readers (VoiceOver on iOS, TalkBack on Android) navigate by swiping, not arrow keys. A pattern still has to work there: every item must be reachable by swipe, and double tap must activate it. Support for aria-activedescendant on mobile has been weaker than on desktop, which is one more reason to prefer roving tabindex outside of comboboxes.

Three layers of testing

1. Automated rules (axe-core in unit tests, Lighthouse, the axe browser extension): catch broken structure, missing names, invalid attribute values, and duplicate ids. Cheap; run on every pull request. They find only part of real issues, and none of the keyboard ones.
2. Role-based tests (Testing Library's getByRole, Playwright's getByRole): query the widget the way assistive technology sees it, press keys with user-event or page.keyboard, and assert on aria-selected, aria-expanded, and which element has focus. This is how you lock in the keyboard contract.
3. Manual screen reader passes: before release and after big changes, use the widget with a real screen reader. Only this tells you what users actually hear.

test("arrow keys move between tabs", async () => {
  const user = userEvent.setup();
  render(<ProductTabs />);
  const overview = screen.getByRole("tab", { name: "Overview" });
  await user.tab();
  expect(overview).toHaveFocus();

  await user.keyboard("{ArrowRight}");
  const specs = screen.getByRole("tab", { name: "Specs" });
  expect(specs).toHaveFocus();
  expect(specs).toHaveAttribute("aria-selected", "true");
  expect(screen.getByRole("tabpanel")).toHaveAccessibleName("Specs");

  await user.keyboard("{End}");
  expect(screen.getByRole("tab", { name: "Reviews" })).toHaveFocus();
});

Which screen readers to test with

Screen readers and browsers come in pairs, and the pair matters because the browser builds the accessibility tree. Test the pairs your users use. The common ones:

• NVDA with Chrome or Firefox on Windows. Free, widely used, and a good first test.
• JAWS with Chrome on Windows. Common in workplaces and government.
• VoiceOver with Safari on macOS and iOS. Built in; the only realistic choice on Apple devices.
• TalkBack with Chrome on Android.

Windows screen readers have two modes. In browse mode (also called virtual cursor) the arrow keys read the page line by line and never reach your code. In focus mode keys go to the page.

When focus lands on a combobox, listbox, grid, tree, or menu, the reader usually switches to focus mode on its own, so your arrow handlers run. That switch is driven by the role, which is one more reason the role must be right.

A short script for each widget: reach it with Tab and listen to the name, role, and state. Operate it with the keys from its APG page. Check that every change is announced ("expanded", "selected", "3 of 8"). Leave with Tab and Escape and check where focus lands.

Compare with the APG's own example in the same pair: if the example speaks and yours doesn't, the bug is yours.

Using it in a system design interview

Frontend system design rounds often ask for a component: an autocomplete, a dropdown, a date picker, a modal, a data table, a tabs component, a file explorer. Each one maps to an APG pattern. Naming that pattern early, and getting it right, is one of the clearest signals that you have built real accessible UI.

When to bring it up

• During requirements. "It must be fully usable with a keyboard and a screen reader; I'll follow the APG combobox pattern." One sentence, said early, sets the bar.
• In the component API. Show that accessibility shapes the props: a required label prop, an id prefix or useId for the ARIA references, onKeyDown handled inside the component, and a render prop for option content, while the component keeps the option role on the element it renders.
• In the state model. The pattern's states are part of your state: isOpen drives aria-expanded, activeIndex drives aria-activedescendant or the roving tabindex, selectedId drives aria-selected. One source of truth means they cannot drift.
• In testing and rollout. Role-based tests for the keyboard contract, axe in CI, and a manual pass with NVDA and VoiceOver before launch.

What to draw

A small annotated markup sketch beats a paragraph. For an autocomplete, draw the input with its ARIA attributes, the listbox with option ids, and an arrow showing aria-activedescendant pointing from one to the other. Add a live region box for the result count. Interviewers remember a candidate who drew this.

How deep to go by level