Group long select lists with optgroup
The optgroup element splits a long select into named groups, which browsers render as headings inside the menu. W3C lists it as sufficient for 1.3.1 Info and Relationships, and its stated benefit is visual first, breaking up a long list so people can find things, with the announcement to screen-reader users following from the same markup. Three rules keep it honest. The optgroup goes directly inside the select and the options directly inside the optgroup, groups cannot be nested so there is exactly one level, and a group label is never selectable. The pattern W3C names as the thing to avoid is the fake heading, an option holding a row of dashes to draw a line. A select can hold loose options and groups at the same time, though that is usually a sign the list wants rethinking.
How we find it in an audit
No tool can decide that a list got long enough to need grouping, so this is a judgment call every time. We open the long selects, country pickers and category filters and account switchers, and look for two things. Grouping that should be there and is not, and the fake version built out of disabled options.
How affected users experience it
Arrowing into a grouped list, the group name arrives at the boundary. Vegetables, group. That is a position in a long menu, which is exactly what somebody reading by ear does not otherwise have. A flat list of 60 options gives them option after option and no map at all. The fake version is worse than nothing, because a disabled heading is noise you have to listen past and cannot choose.
Passes vs. fails
Passes
<select>
<optgroup label="Vegetables">
<option>Carrot</option>
<option>Leek</option>
</optgroup>
</select>Fails
<select>
<option disabled>--- Vegetables ---</option>
<option>Carrot</option>
</select>How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable, so the condition is part of the test rather than a footnote to it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique H85: Using optgroup to group option elements inside a select. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.