Reputation: 13557
I have a list of options from which one can be selected. For all intents and purposes HTML's <select>
element covers this. Since we need a different visual presentation, I'm looking at using WAI ARIA role="listbox". I'm unclear on how to use aria-activedescendant
, aria-selected
and aria-checked
.
Questions regarding focus/active state:
aria-activedescendant
on the listbox to point to the [role="option"]
that is currently active (has "virtual focus"), I would use [aria-selected]
. How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually? (:focus
is on the listbox, after all)[role="option"]
can have [aria-checked]
and [aria-selected]
. I guess I need [aria-selected]
but don't see what I'd use [aria-checked]
for.aria-activedescendant
?Questions regarding keyboard interaction:
Questions regarding validation:
If the listbox has [aria-required="true"]
some sort of validation has to be performed. specifically if an option has been selected (or checked).
blur
sufficient?[aria-invalid="true"]
on the listbox?Upvotes: 6
Views: 6077
Reputation: 66
aria-checked
is indeed more something for a list of very closely related options with actual visible checkboxes that can be toggled on or off. This is most common in the Windows world. Explorer can be set to such a pseudo multi-select mode, or some apps use that to activate or deactivate a set of accounts. On the Mac, you can think of the list of accounts in Adium, which can be either checked (active) or not. A selection will always be there, and one or more of their checkboxes can be checked or not.
aria-selected
is always the right one to indicate the selected state of an option. E. g. when traversing the list with the arrow keys, aria-selected="true"
moves from item to item, while the others must then get aria-selected="false"
. As Patrick said, you can use this to also generate some nice looking CSS.
As for keyboard interaction: arrows up and down will select an item, and if the items are checkable, too, space will toggle the checked or unchecked state of the currently selected item.
In a true multi-select, like html:select @size>1, and multiselectable being true, the interaction would be:
This is, again, standard Windows paradigm, can be observed in Explorer in Details view, for example.
As for validation: onBlur
is sufficient, or you could dynamically do it via changes in selection/focused item, make sure at least one item is selected, or whatever validation you need.
aria-invalid="true"
is sufficient for screen readers to know, but an error message and possibly a visual indication would be nice for everyone to know what's wrong.
Upvotes: 5
Reputation: 152
How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually?
Generally, you'd add aria-selected="true" and then craft some CSS that takes care of it using attribute selectors, e.g. div[role=option][aria-selected=true] { ... }, or add a css class dynamically?
[aria-checked] and [aria-selected]
This is more of a philosophical question I guess. aria-selected more closely matches what you'd have with a select...but then again (particularly for multi-select widgets) you can imagine the listbox actually being a series of checkboxes, and in that case you'd use aria-checked. there's no definitive right or wrong about either one (something you'll find a lot once you dive into more complex ARIA widgets).
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant
Hmm...perhaps you could dynamically generate IDs for all options on page load via script? Or - but not tested - you could have something like a "roving" ID that moves around the options depending on which one is active (adding/removing the ID to the relevant option).
Upvotes: 2