Proposed optional assertions for container semantic reading by current item reading commands, e.g., JAWS/NVDA insert+tab

[mcking65]

Pottentially Applies to menuitem, treeitem, option, radio, cell, gridcell, checkbox in group, elements in toolbar, tab

Potentially applies to JAWS insert+tab, NVDA insert+tab, VO ctrl-opt-f4, VO ctrl-opt-f3.

Suggestion: Optional assertions that these commands also provide role and name of parent container.

See discussion starting with this comment in PR 378.

[jscholes]

Notes from the April 15 CG meeting

Background

• Screen readers don't always do the best job of letting users query where they are within a complex web page or component.
• There are many keystrokes available, including something like object navigation in NVDA to get information about the parent/grandparent/etc. But users can only remember/comprehend a certain number of keystrokes at once.
• Commonly used keystrokes, like Insert+Tab in JAWS/NVDA, have a defined purpose, e.g. to report the object which has current focus with some related information about it. But that doesn't include much, or any, wayfinding info.
• It's not the ARIA-AT project's role to be opinionated about and define screen reader behaviour or consistency. But nor do we want assertions to be limited by complexity or current SR behaviour.

Takeaways

The group reached consensus that:

• When pressing Insert+Tab in a composite widget (or similar keystrokes to consult the current focus), we should assert that the role and name of the composite are conveyed.
• The assertions should be optional.
• The same optional assertions shouldn't be included for:
  • Insert+Up for current line (or similar keystrokes which are scoped to reading text); or
  • components that are not part of a composite widget, e.g. a checkbox in a group or link in a labelled navigation region.
• When a composite contains a layered hierarchy which itself isn't formed of composites, the assertions should still refer to the base composite. E.g.:
  • In a treeview, the role and name of the treeview should still be asserted even when a user is many levels deep, rather than the role and name of the parent node.
  • In a grid or treegrid, the assertions should always relate to the grid or treegrid rather than a labelled rowgroup.
• "Composite" mostly follows the WAI-ARIA definition of the term, but also includes toolbars.

There are several outstanding questions:

1. Assertions are scoped to tests rather than individual commands, and we don't want to change that. This will require separating reading-related tests into two, one for Insert+Tab and another for Insert+Up. How should we word those tests?
2. How should we handle nested composites, like a radiogroup within a toolbar? Arguably the context from both is helpful.
3. Are we missing any other edge cases, whether related to nested composites or something else?