Source: W3C ARIA Authoring Practices for tabs and dialogs
W3C ARIA Authoring Practices: tabs and dialogs
Evidence class: informative implementation guidance and illustrative examples from the W3C ARIA (Accessible Rich Internet Applications) Authoring Practices Guide, called APG below. Read: 2026-09-13; tabs pattern rechecked 2026-10-29. This is a different body of work from WCAG conformance requirements. Documentation and example markup were read; browser, keyboard, and assistive-technology behavior were not executed in this pass.
Tabs depend on latency as well as appearance
APG recommends automatic activation, where a tab shows its panel as soon as it receives focus, when panels appear without noticeable latency. When panels lag, automatic activation slows focus movement, so use manual activation, which separates moving focus from requesting a panel. Left and Right arrows move between tabs (Up and Down in a vertical tab list); Enter or Space activates a tab that was not activated on focus. Source: Tabs pattern, read 2026-10-29.
Manual activation example, read 2026-09-13, distinguishes focus from selection and provides implementation references. Its own warning says illustrative code is not intended as production-ready code; browser and assistive-technology combinations need testing. Copy the behavioral idea only after checking the chosen component implementation.
A modal has an entry and an exit contract
APG describes focus entering the dialog, remaining within it during Tab navigation, and returning to the invoker on close or to a logical successor when needed. It describes Escape dismissal and content-sensitive initial focus. Initial focus need not always be the first control or the primary action. Source: Modal dialog pattern, read 2026-09-13.
Modal example, read 2026-09-13, explains different initial-focus choices for short forms and longer content. It includes demonstration-only controls and its own production-use warning. Our transfer: specify focus and recovery alongside visible layout rather than treating an overlay screenshot as a finished component.
Limits
These notes do not choose a component library, require a modal for every edit, or endorse manually recreating native behavior. Use a component with appropriate semantics and test it in the actual application. Accessible component behavior does not by itself prove that the selected interaction is appropriate for the user's task.