Revisit allowed roles for aria-expanded

[smhigley]

After #681, it looks like the current roles that support aria-expanded are:

• application
• button
• checkbox
• combobox
• gridcell
• link
• listbox
• menuitem
• row
• rowheader
• tab
• treeitem

Also inherited into:

• columnheader
• menuitemcheckbox
• menuitemradio
• switch

I was curious about the use cases for the following roles specifically:

application
Similar to document, I'm not sure when it would make sense to give the application root itself aria-expanded

listbox
I often see confusion around how to properly implement a custom <select>, and one of the common patterns is a <div role="listbox" tabindex="0" aria-expanded="true/false">. I haven't run into any indication that this is a supported pattern, and I've run into some support issues with it (though more investigation would be needed if it is desired). If that's not an accepted pattern, I think it'd make sense to not support listbox. Some examples where you can see the listbox used as <select> in the wild:

• https://www.telerik.com/kendo-angular-ui/components/dropdowns/
• https://developer.microsoft.com/en-us/fabric#/controls/web/dropdown

gridcell
I'm less sure about this one, but it seems like a better experience to have a button nested in a grid cell when it's desirable to trigger an expanded element. Is there a use case for having aria-expanded on a grid cell that isn't covered by a button?

rowheader / columnheader
Similar to gridcell, is there a use case for having aria-expanded directly on a row or column header rather than having a child button?

row
I know this is valid in a treegrid, but I've run into instances of it being added to a row in a table or grid (e.g. for a grid row that has some sort of supplemental content that visually appears below the row). Using aria-expanded on a row doesn't seem like the proper approach for those use case, so if treegrid > row is really the only allowed case, perhaps the documentation could be edited to make that more clear?

[jnurthen]

(chair hat off for comments below)
application: As application is now essentially used for a widget (or composite) which doesn't have a matching role available it makes sense to me to allow aria-expanded. We don't really know what the author might be trying to do so we shouldn't restrict them too much.

listbox: if we could get agreement on this it might be a simpler mechanism to create a select than we currently have. I'd be in favour of investigating this as a simplification to current techniques all of which are unsatisfactory IMO

gridcell/rowheader/columnheader Pivot tables? It really is the cell you are collapsing/expanding in this case not a button inside it. Logically to me it should be on the cell itself.

row I think I agree we should limit this to rows in treegrids.

[smhigley]

@jnurthen those are interesting points! I'd be happy to do some more investigation for some of them (commented below):

• application: would that be an argument to include the application role in most of the attributes in Revising what ARIA attributes should be considered global #999? It seems like it should be all or nothing, unless there's something specific about aria-expanded that I'm not thinking of.
• listbox: I'm not sure I agree with that approach. A <select> maps to a readonly combobox on Windows, and a popup button that opens a listbox on Mac/iOS. I'm not aware of anywhere an expandable listbox would be a familiar pattern to a large number of users. I'm willing to make a reduced test case and run tests on it though, to get a feel for current support.
• gridcell/rowheader/columnheader: Pivot tables are an interesting one! I checked out Excel on desktop to see what they did, and they do not have the ExpandCollapsePattern on any cells. For column headers, they have a separate menuitem as a child of the cell. Row headers do not have a separate child control or the ExpandCollapsePattern, so I'm not completely sure how they work, but expanding rows seem like a better fit for a treegrid pattern. I've reached out to screen reader users who are familiar with more advanced Excel functionality (including pivot tables) to hear what they would prefer, and I'll update here when I hear back. In the meantime, do you know of any other tools where pivot tables are common and what approach they take?
• row: 👍

Thanks!

[smhigley]

I revisited aria-expanded grids and listboxes, and did some support testing for each:

• listbox:

  • macOS VoiceOver: does not recognize the listbox as a form field, and does not support expected/announced keyboard interaction
  • iOS VoiceOver: ignores the listbox entirely, does not reach it by swiping or jumping by form field
  • NVDA + Chrome and FF: works fine, but announces as a list
  • JAWS + Chrome and FF: works fine, announces as a collapsed listbox
  • Narrator + Edge: does not reach it when navigating by form field, and very odd announcement: "selected, selection contains 0 items" when reaching the listbox with tab.

• grid cells and headers:

  • NVDA + FF: reads expanded/collapsed
  • Narrator + Edge: reads expanded/collapsed
  • JAWS + Chrome: reads expanded/collapsed in tables, but not grids
  • iOS VoiceOver: expanded/collapsed not read

[smhigley]

After talking with @mcking65, I wanted to revisit this with an addition he brought up -- aria-expanded on tabs. With that addition and based on the conversation above, how would people feel about removing or revising aria-expanded on the following roles?:

• tab
• listbox
• row, except when in a treegrid

[carmacleod]

• tab
aria-expanded has been in tab as a SHOULD since ARIA 1.0. I'm not sure what the reason for removing it would be?
• listbox
  It looks like listbox was added back in after the 02-May-2019 sweep to remove aria-expanded support from container roles. Something to do with select elements being mapped as listbox when multiple, and/or size > 1. That discussion was never completely resolved. However, I would argue that when a select is multiple and/or has size > 1, causing it to be mapped as a listbox, then it does not need aria-expanded because it isn't rendered as a dropdown. So I agree with removing it from the ARIA spec, because it's confusing. @joanmarie ?
• row, except when in a treegrid
  Makes sense to me to revise row support of aria-expanded to say "only if in a treegrid". In fact, that would make it consistent with the HTML-ARIA spec for row, which already says:

  if child of role=treegrid:
  aria-expanded (state)

[mcking65]

We added expanded to listbox after our last f2f in Toronto as a potential solution to custom select@size=1. At that time, we didn't have the support for making needed changes to combobox to solve the select@size=1 issue and were hunting for other approaches. Our experience with collapsable listbox in APG surfaced some critical shortcomings with that approach, e.g., you can't mark a button that represents a collapsed listbox required.

Now, we have complete resolution of that issue with the ARIA 1.2 combobox changes and there is no need for expanded on listbox. We could deprecate expanded on listbox. Then, we could either warn against using that pattern in APG and point people to the select-only combobox or remove the collapsable listbox example completely.

[jnurthen]

@smhigley please move to 1.4 if you will not have time in the 1.3 timeframe

[smhigley]

I'd like to at least remove the listbox aria-expanded attribute + aria-practices example in 1.3 :)

[a11ydoer]

@smhigley
Please point me aria-preactice example with URL you are referrng to.

[JAWS-test]

There is currently no meaningful use for aria-expanded on a listbox. Therefore it should be removed

[smhigley]

The APG example has since been removed. I think now the only role from the original list I would still like aria-expanded support to be removed from is listbox.

I can make a PR for that, and get this rolling again