LibrarySource: W3C ARIA Authoring Practices for tabs and dialogsv2 · Updated Report

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.

Oddlynew UX and UI Principles for WebsitesSign in

Referenced by