ChangeProposals/tablist and tab states for menu and command elements
This change proposal is intended to address HTML WG Issue 134: "Provide tablist and tab states for menu and command elements respectively" as articulated in HTML WG Bug 10831: "Provide tablist and tab states for menu and command elements respectively".
- Editor: Gregory J. Rosmaita (oedipus at hicom dot net)
- Original proposal: Everett Zufelt / Invaluable Contributions: Jason Kiss
- Please address feedback to the HTML Working Group mailing list (firstname.lastname@example.org).
Most operating systems implement native support for tabbed interfaces and pass the relevant state information to users via accessibility APIs. In the default design pattern for tabbed interfaces as commonly implemented in most operating systems, only the currently selected tab control is focusable, while the remaining tab controls are not. Additionally, only the tab panel associated with the current tab control is visible and available through the accessibility tree. On the other hand, most web-based tabbed interfaces are typically implemented only visually using CSS. Important information such as which elements are serving as tab controls, which of those controls is currently selected, and what page content is associated with the currently selected control, is not programmatically determinable and remains unavailable to assistive technologies.
In order to make the identification and state of a web-based tabbed interface programatically determinable today goes beyond simple visual presentation using CSS and requires significant work on the part of the document creator:
- several WAI-ARIA roles (i.e.,
tabpanel) and attributes (which include, at least,
aria-labelledby) must be applied;
- scripting and CSS must be used to dynamically update certain attribute values (e.g.,
aria-hidden) to ensure that keyboard interaction with the tab controls is intuitive and that only the currently selected tab panel is visible and present in the accessibility tree.
The work required today to build an accessible tabbed interface is needlessly complicated and constitutes an inferior means of providing such information and functionality when a native solution is readily available.
menu element, along with the
command element, can currently represent a generic list of controls, a context menu, or toolbar. Since a group of tab controls effectively acts as a menu of commands for showing and hiding associated content tab panels, it is therefore proposed that the
command elements are well-suited to serve the purposes of a tabbed interface, and that their functionality be extended to represent a tablist of tab controls and to identify which of those tabs is selected.
- Add a
tabliststate to the
menuelement via the
- Add a
tabstate to the
commandelement via the
- Add a
tabpanelattribute to the
- Add a
type attribute is set to
menu represents a list of tabs. When a
type attribute is set to
command represents a tab control. A
command element with state
tab must also have a
tabpanel attribute set, the value of which shall reference the
id of the element in the document that represents the content (tab panel) associated with that tab control. At any time, one, and only one,
command element with
@type="tab" will have
@selected="selected", indicating the currently selected tab, and its associated tab panel content visible and available to the accessibility tree. All other tab panels must be hidden and unavailable.
User agents will:
- map the
commandelements with state
tabto the accessibility tree;
- identify to the accessibility API which tab control is currently selected based on the
- set the first
selectedattribute if none of the
- ensure that only the tab panel for the currently selected tab control appears in the accessibility tree;
- ensure that only the currently selected tab control is focusable;
- provide conventional keyboard commands (as commonly implemented for tabbed interfaces in most operating systems) for moving among the other tabs in the tablist;
- implement a default visual rendering for the tabbed interface.
- Assistive technologies and accessibility APIs will be able to easily identify a tablist, the number of tabs it contains, and which tab is selected.
- Only the tabpanel associated with the currently selected tab will be available via the accessibility tree, thus reducing any potential confusion for assistive technologies regarding the state of the tabbed interface.
- Developers will be able to use native HTML elements in a much simpler way instead of being required to perform the extra work of adding numerous WAI-ARIA attributes and managing some of them dynamically via scripting.
- Developers will not be required to manage focus or keyboard interaction for tab controls.
- User agents will have to implement these features, manage focus for
commandelements with a state of
menuelements with state
tablist, implement basic keyboard interaction, and provide a default rendering for tabbed interfaces.
- Without developers doing significant work to make a tabbed interface accessible using WAI-ARIA and additional scripting, the presence, state, and functionality expected of a tabbed interface will remain unavailable to assistive technologies.