Change Proposal: Allow menu and command to represent a tablist

It is proposed that the functionality of the menu and command elements be extended to represent a tablist (tabstrip) of tab controls.

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 (public-html@w3.org).

Rationale

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., tablist, tab, and tabpanel) and attributes (which include, at least, aria-selected and aria-labelledby) must be applied;
• scripting and CSS must be used to dynamically update certain attribute values (e.g., aria-selected and 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.

The HTML5 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 menu and 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.

Details

1. Add a tablist state to the menu element via the type attribute.
2. Add a tab state to the command element via the type attribute.
3. Add a tabpanel attribute to the command element.
4. Add a selected attribute to command elements with @type=“tab”.

When a menu element's type attribute is set to tablist, the menu represents a list of tabs. When a command element's type attribute is set to tab, the 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:

1. map the menu with state tablist and command elements with state tab to the accessibility tree;
2. identify to the accessibility API which tab control is currently selected based on the command elements' selected attribute;
3. set the first command element's selected attribute if none of the command elements have selected set;
4. ensure that only the tab panel for the currently selected tab control appears in the accessibility tree;
5. ensure that only the currently selected tab control is focusable;
6. provide conventional keyboard commands (as commonly implemented for tabbed interfaces in most operating systems) for moving among the other tabs in the tablist;
7. implement a default visual rendering for the tabbed interface.

Impact

Positive Effects

• 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.

Negative Effects

• User agents will have to implement these features, manage focus for command elements with a state of tab within menu elements with state tablist, implement basic keyboard interaction, and provide a default rendering for tabbed interfaces.

Risks

• 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.

References

• HTML WG Issue 134: "Provide tablist and tab states for menu and command elements respectively"
• HTML WG Bug 10831: "Provide tablist and tab states for menu and command elements respectively"