Secondary actions on items in composite widget roles

[smhigley]

I've been repeatedly running into a difficulty between a relatively common app UI pattern and the required owned elements part of the ARIA spec. The problem is specifically with secondary actions with composite interactive widget roles. I'm using "secondary action" to refer to cases where the child of the composite widget role (e.g. tab, treeitem, option, etc.) performs a primary action that makes sense for its role, but then also has secondary actions like edit/delete/etc., exposed through an associated button.

Here are some examples of UI that have this pattern:

1. Close buttons in tabs (probably the most familiar example):
   
2. A menu of recently opened files, where each file has share, favorite, and more actions buttons:
   
3. A tree of participants in a meeting, where each participant has mute and more actions buttons:
   
4. A tree of emails, where each email has flag, complete, and more actions buttons:
   

Context menu approach

A solution we've used in the past was to make the visual buttons presentation-only, and duplicate all secondary actions in a context menu. The problem is the context menu wasn't sufficiently discoverable in practice, and sighted users who relied on keyboard navigation (either with or without a screen reader) expected to be able to directly reach the visible buttons.

If a context menu alone were a good approach, this would be covered by #762, but the discoverability problem is enough to make me think there needs to be a pattern for surfacing the secondary action buttons directly.

Nested vs. sibling options

Exposing the buttons directly runs into two spec + support problems:

1. Putting the secondary action buttons inside the tab/option/treeitem/etc. runs afoul of "Children: presentational" in the spec, and has known support problems.
2. Putting the secondary actions adjacent to the tab/option/treeitem/etc may or may not violate the "Required Owned Elements" part of the spec, depending on how Clarify "required owned element" #1033 falls out.

I did some testing of practical support for nested vs. sibling buttons within composite widgets, with both the working test cases and results tables on this test page. It seems to pretty clearly come down on the side of sibling buttons having better support.

Aside from the test results, I don't personally have much of an opinion on the specific approach used, but I think we have a strong need for explicitly defining some sort of pattern defined for these cases.

[scottaohara]

spitballing here, but i wonder if there couldn't be some sort of special allowances to secondary related controls, as long as they had a programmatic association with the required children - theoretically giving them a reason to be there.

using the tab with a close button example, having those as nested children is weird. but they aren't allowed children of a tablist. but what if there were a special allowance where if, say, the button had an aria-controls association with the tab, then it would be allowed in the tablist? this way, the following would still not be allowed:

<div role=tablist>
  <button>what am i doing here? i think i'm in the wrong house...</button>
  ...
</div>

but the following "would"

<div role=tablist>
  <div role=none class=tab-container>
    <button role=tab id=hi>hi</button>
    <button aria-controls=hi>close</button>
  </div>
  ...
</div>

please, feel free to poke all the holes in this. just first thing that came to mind, and would give aria-controls something else to be useful for.

[JAWS-test]

See: #1385

[smhigley]

@scottaohara I like your idea :). I'm not sure exactly how it'd be defined in spec language, but I'd be in favor of some sort of Allowed Child Elements thing that replaces Required Owned Elements, and has a list of roles + some term for anything associated via aria-controls.

@JAWS-test I saw that issue, and it's definitely helpful to link the two to illustrate that secondary actions is a common issue that many people run in to :). That said, this issue is more about how include buttons that are visually present in the accessibility tree, which wouldn't be solved with an attribute -- specifically non-screen reader use cases like keyboard interaction and voice control, screen reader touch exploration, and expectations of sighted screen reader users. I think the attribute is an interesting idea, but it makes sense to discuss the two separately.

[mcking65]

If they are children, won't screen readers then have to present the tab or treeitem as a container? When reading via touch or reading cursor, we'd ideally want the action buttons as siblings, hopefully associated siblings so the screen reader can tell you that the button is delte for tabx or for treeitem named x or something like that.

If they are children of the tab or treeitem, they effect accname calc. if they are not children, then we don't have to worry about name calc.

If they are siblings of the item but still inside the composite, the browsers will have to do some fancy footwork to address indexing, i.e., posinset.

I wish I could attend the deep dive. Looking forward to the outcome.

I'm super concerned about screen reader expectations if they are children of the item though.

[MelSumner]

It would be nice to have some sort of clear pattern and standardized role for this sort of thing. As long as we keep it distinct, because I don't want to break linting checks for nested interactive elements.

[joanmarie]

As a screen reader developer, I think that such controls are more naturally/conceptually children of the widget they control; not siblings.

And while I agree with @mcking65 that we need to be concerned about screen reader expectations, I also think we should do some debugging (i.e. in the browsers and where possible the screen readers) to determine why something isn't working as we expect before we conclude a particular approach is the wrong one.

[brandonthomas]

Any update on this @smhigley? We're seeing this in some of our code as well and would love to align where possible.

[aleventhal]

As a data point, the Chrome address bar suggestions and Google search suggestions can have additional actions as you up/down arrow. For example, a Remove (from future suggestions) button and/or "Switch to tab" (if already open).
The best way we could find for that case was that the tab key can access the additional buttons for the currently selected listbox option. The text of the option itself provides the keyboard hint so that's discoverable.

[smhigley]

Here's an attempt at somewhat-cohesive notes for discussion on thursday:

Pros and Cons of each approach:

Sibling pros

• Currently would have better practical support
• Don't need to untangle the nontrivial support blockers, including:
  • accname calculation needs to somehow exclude nested secondary actions (but not necessarily all nested interactive elements)
  • the nested interactive elements would need to be exposed somehow, likely through their parent
  • virtual cursor (for Windows screen readers) would need to be able to navigate within buttons, treeitems, options, etc.
• We can use aria-controls to make an explicit association with ARIA

Sibling cons

• Not as intuitive for authors
• There is no way to author this without ARIA, and it isn't clear to me how this could be spec'd in HTML in the future
• There is a high prevalence of nested interactive items in the wild today. If that pressures browsers and AT vendors into solving the current support issues, it makes even less sense for secondary actions to not be nested

Nested approach pros

• The relationship exists through the nested DOM structure, without additional ARIA (maybe)
• We might have to solve this anyway because so many people nest buttons, so it would fix two problems at once
• We could solve existing nested interactive issues with gridcell and summary, which are largely the same -- e.g. sorting and filtering buttons on columnheader cells that are then in the column name for every cell

Nested approach cons

• Right now HTML buttons/options/etc do not allow nested interactive elements. If used, this would only work with ARIA and we would need to convince HTML to change if we want parity
• ATs would need to change as well. <summary> shows some of the squirrely bits, e.g. with virtual cursor not reaching nested elements
• We need to figure out a mechanism for nested secondary actions to not contribute to the parent accname without suddenly breaking a lot of incorrectly authored code that depends on the current behavior
• We need to figure out a mechanism for the existence of nested secondary actions to be exposed on the parent, and doing so might remove the pro of not requiring additional ARIA

Possible options for handling nested secondary actions and naming:

• add an attribute like aria-actions that takes a space-separated list of ids
• add an attribute (not a role, for flexibility) to denote secondary actions

Outstanding questions:

If we go with nested actions, what do people do in the meantime?

For browser vendors: how hard would it be to use either an aria-actions-like attribute or a per-nested-element attribute to both calculate the parent's accessible name and expose that actions exist?

[stes-acc]

Don't forget the context menu of an item to access item-specific functions.