One thing I run into time and time again is a list of things that are interactive. WAI-ARIA does have a role=“list”, however, ,it is defined as a “list of static elements”. Most notably, this means screen readers do not enter forms/interactive mode when encountered. The examples I"m thinking of don’t fall into any other category- they are not toolbars or menus, etc…and I would like to avoid role=“application” (since that’s not what it is either really).
- A inbox list (a list of e-mail messages)
- A list of attachments in an email (or any list of links you would like to navigate via arrow keys rather than tab, but don’t fall into the category of a toolbar or menubar or foldertree)
- A list of messages in a thread (a la gmail)
I know there are more, but that is all I can think of offhand. It’s the #1 issue I have when working with wai-aria and email clients…
The listitems are the static children of the list. The listitems themselves can contain interactive objects, just like an HTML listitem can.
That said, for some of the use cases you describe (like the list of attachments) where you might want to select multiple items, the listbox role might be a better option.
Then are you saying screenreaders should enter “forms” mode when encountering listitems?
“Then are you saying screenreaders should enter “forms” mode when encountering listitems?”
No. A listitem is static, but it may contain an interactive object.
Worth noting that just because an element is interactive, it does not mean that a screen reader should switch into forms or application mode. There is no expectation that a screen reader would do this when encountering the
<details element for example.
I guess that’s why I’m saying there seems to be a ‘list of interactive objects’ role missing-- for a list of ‘things’ you would like to use the arrow key to navigate among-- vs using tab or making the user manually enter ‘forms’ mode
Can you provide the code for a simple use case?
Am I correct in saying that this seems to fit role=“feed”?