Need to check roles which support aria-expanded

[joanmarie]

Because aria-expanded is supported on these roles:

• button
• combobox
• document
• link
• menuitem
• section
• sectionhead
• window

The full set of roles it is supported on is:

• alert
• alertdialog
• article
• banner
• cell
• columnheader
• complementary
• contentinfo
• definition
• dialog
• directory
• feed
• figure
• form
• grid
• gridcell
• group
• heading
• img
• landmark
• list
• listbox
• listitem
• log
• main
• marquee
• math
• menu
• menubar
• menuitemcheckbox
• menuitemradio
• navigation
• note
• progressbar
• radiogroup
• region
• row
• rowheader
• search
• select
• status
• tab
• table
• tabpanel
• term
• timer
• toolbar
• tooltip
• tree
• treegrid
• treeitem

Is an alertdialog really expandable? What about a progressbar? And I'm not an author, but what is the advantage of making main expandable? Let's sanity-check these.

[mcking65]

Definition of aria-expanded:

Indicates whether the element, or another grouping element it controls, is currently expanded or collapsed.

In practice to-date, aria-expanded is applied to the controlling element, e.g., button, treeitem, menuitem, or row in a treegrid. Applying aria-expanded to a controlled grouping element is not helpful, especially since in most cases the element is not even present in the accessibility tree; it is often hidden with display:none.

The current set of roles that support aria-expanded is based on the idea that we would apply aria-expanded to the grouping element. This would really only work well if:

1. The grouping element has a visual representation that was rendered in both the expanded and collapsed states;
2. The grouping element is focusable and interactive;
3. The grouping element does not have a separate controlling element for expanding and collapsing.

It is possible to imagine such an element. Perhaps a focusable div that expands and collapses when activated. If someone were to make such a thing, the question then becomes: which of the container or grouping types of roles could describe it without violating other requirements associated with those roles?

We also need to consider whether there are roles that should support aria-expanded but do not. Checkbox does not currently support aria-expanded, but a checkbox can control visibility of a section of content.

Questions and principles

1. Should we avoid adding limitations that are not absolutely necessary to avoid clearly predictable AT interoperability problems?
2. Does applying a role that the ARIA taxonomy classifies as a structure to a focusable and interactive element violate any normative requirements? For example, does making a region focusable and interactive necessarily cause problems?

Keep case is clear for

• button
• combobox
• gridcell
• listbox
• menuitem
• row
• rowheader
• tab
• treeitem

Remove Case is Clear for

• alertdialog
• cell
• link
• menu
• menubar
• menuitemcheckbox
• menuitemradio
• tooltip

Add case is clear for

• Checkbox

Muddy waters surround

• alert
• article
• banner
• columnheader
• complementary
• contentinfo
• definition
• dialog
• directory
• document
• feed
• figure
• form
• grid
• group
• heading
• img
• list
• listitem
• log
• main
• marquee
• math
• navigation
• note
• progressbar
• radiogroup
• region
• search
• status
• table
• tabpanel
• term
• timer
• toolbar
• tree
• treegrid

[jnurthen]

I agree with all the removals except for link. A link can certainly control an expandable region.

[jspurlin]

@mcking65 I agree for the most part but there's a few other roles that come to mind that don't seem to be addressed yet: option, textbox, and searchbox.

Those are some other roles that have aria-haspopup but does not support aria-expanded (there might be more, but these are the one's I've run in to most recently). For the textbox/serachbox example, if it displays results I've seen examples state to make the input a comboBox. The issue with that is you must use a listbox with a comboBox (for the "menu" scenario), and a listbox must contain option(s), but options currently do not allow for aria-expanded...

[mcking65]

I'll make a separate PR to remove aria-expanded inherritance into menuitemradio and menuitemcheckbox; those need to be addressed before closing this issue.

[css-meeting-bot]

The ARIA Working Group just discussed Need to sanity check roles which support aria-expanded.

The full IRC log of that discussion

<joanie> Topic: Need to sanity check roles which support aria-expanded
<joanie> github: https://github.com//issues/681
<joanie> mk: To summarize what I have in my pull request description:
<joanie> mk: There are minor changes to the definition of aria-expanded
<joanie> mk: Previously, it said to put it on element which gets expanded or collapsed or controls something which does
<joanie> mk: Now it needs to be on a focusable element which controls or owns the thing which gets expanded or collapsed.
<joanie> mk: Example, a treeitem which would get a child group upon expansion would have aria-expanded.
<joanie> mk: Emphasis: aria-expanded goes on the element which does the expanding/collapsing.
<joanie> mk: I also had to reword an author-related normative statement.
<joanie> mk: There had been some content in there related to the benefits for different users.
<joanie> mk: This might be practices, but it seemed unneeded in the spec.
<joanie> mk: The rest is changing what roles aria-expanded is supported on.
<joanie> mk: I removed it from some, but doing so caused it to be removed from other roles where it belongs, so I had to manually add it there.
<joanie> mk: In the pull request, I put a list of all the things it got removed from
<mck> alert
<mck> alertdialog
<mck> article
<mck> banner
<mck> blockquote
<mck> caption
<mck> cell
<mck> complementary
<mck> contentinfo
<mck> definition
<mck> deletion
<mck> dialog
<mck> directory
<mck> feed
<mck> figure
<mck> form
<mck> grid
<mck> group
<mck> heading
<mck> img
<mck> insertion
<mck> label
<mck> landmark
<mck> legend
<mck> list
<mck> listitem
<mck> log
<mck> main
<mck> marquee
<mck> math
<mck> menu
<mck> menubar
<mck> navigation
<mck> note
<mck> paragraph
<mck> radiogroup
<mck> region
<mck> search
<mck> select
<mck> status
<mck> subscript
<mck> superscript
<mck> table
<mck> tabpanel
<mck> term
<mck> time
<mck> timer
<mck> toolbar
<mck> tooltip
<mck> tree
<mck> treegrid
<joanie> mk: so that's the extent of the pull request. The wording part is something we should probably discuss
<joanie> bg: is it on listbox?
<joanie> mk: yes, it still is.
<joanie> mk: There are three roles that really shouldn't have it, but do have it.
<joanie> mk: columnheader, menuitemradio, menuitemcheckbox
<joanie> jn: columnheader could collapse a column.
<carmacleod> Here's Birkir's email. The use case is displaying new form content when a user selects a checkbox in a form. https://lists.w3.org/Archives/Public/public-aria/2016Feb/0084.html
<joanie> mk: But then the columnheader goes away and you couldn't re-expand it.
<joanie> jn: I agree this is a stretch, but...
<joanie> mk: I would rather remove it and wait for someone to make a case for it.
<joanie> jn: I think this is a safe thing to do.
<joanie> jn: And it clarifies exactly where it belongs, namely on the element that expands things.
<joanie> mk: To change it for the three extra things, I would have to change the ontology.
<joanie> jn: Please don't. Let's keep it simple.
<joanie> mk: I will do this as a separate pull request (the ontology change)
<joanie> jd: I think it's a potentially good idea to make the change
<joanie> mr: I was pulling up all the different APIs to see what aria-expanded maps to.
<joanie> mr: The descriptions suggest it applies to the parent
<jamesn> jd: what is the difference for someone who consumes it?
<jamesn> mr: don't think there is a functional difference
<jamesn> jd: unless core-aam has something I'm no0t aware of
<jamesn> jd: if the thing the user arrows to is the tree item - that is the thing I'd already expect to have the ewxpanded on.
<jamesn> mr: example I'm thinking of is a button that controls something else but its children arent being expanded
<bgaraventa1979> q+
<jamesn> mk: if you have a button controlling a div and that div contains content then aria-expanded goes on the button that way the user when focus is on the button can hear the state change
<jamesn> mk: they know (or could) as AT user by aria-controls. When collapsed you are controlling something that is not there
<jamesn> mr: if no UX problem then not a problem but a different assumption here
<jamesn> mr: if not concerning ok
<jamesn> jd: only going to be on the interactive thing that does the expansion. ATK state expanded is in the right place
<jamesn> ... state expanded belongs there
<jamesn> ... if you think otherwise docs need fixing
<jamesn> mr: when they are 2 different objects maybe confusing
<jamesn> jd: "children"
<jamesn> ack bg
<jamesn> bg: aria tabs aria-expanded was meant to be on the tab panel and no technology supported that
<jamesn> bg: differences between platform mappings and what you are talking about - states and properties only exposed on the thing with focus.
<jamesn> ... ir aria-activedescendent
<jamesn> s/ir/or/
<jamesn> ... historically s&p only exposed on active element
<joanie> mk: It also got even more popular with native mobile, where these disclosure patterns are needed
<joanie> mk: Screen reader users are even more used to hearing expanded/collapsed on the button.
<joanie> mk: What doc were you quoting Melanie?
<joanie> mr: I checked pretty much all of them (UIA, ATK, MSAA, etc.)
<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/api/UIAutomationCore/ne-uiautomationcore-expandcollapsestate
<melanierichards> https://developer.apple.com/documentation/appkit/nsaccessibility/1535045-accessibilityexpanded
<melanierichards> https://developer.gnome.org/atk/unstable/atk-AtkState.html
<melanierichards> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Accessibility/AT-APIs/MSAA/States
<joanie> mk: I didn't actually check core-aam
<joanie> jd: It doesn't change anything
<melanierichards> https://docs.microsoft.com/en-us/windows/desktop/WinAuto/object-state-constants
<joanie> jd: I think the doc problem is that in native toolkits, the expansion took place on children/descendants. ARIA makes it possible to have owned elements, controlled elements, and the like that the doc writers didn't know existed.
<joanie> mk: in tree grid, you are focusing rows.
<joanie> mk: and rows can be controlling child rows.
<joanie> bg: But I'm thinking static tables.
<joanie> mk: In that case you'd put it on a link or button or something in the cell.
<joanie> jn: Do we want to review anything more?
<joanie> jn: Preview link?
<joanie> https://pr-preview.s3.amazonaws.com//pull/972.html
<joanie> group: (reads silently)
<joanie> jn: Do we have a definition of a grouping element?
<joanie> mk: Not really, but it's anything that is grouping other stuff.
<joanie> jn: But what about a single child element? Is there always a grouping element.
<joanie> bg: If it were a button, it wouldn't make any sense.
<joanie> cm: Nit: "controled" should be "controlled"
<joanie> mk: What is tapered prompts?
<joanie> group: (crickets)
<joanie> mk: It's in related concepts for aria-expanded, and I left it there
<jamesn> "Tapered prompts are those that may change with each attempt. Information-requesting prompts may become more terse under the assumption that the user is becoming more familiar with the task. Help messages become more detailed perhaps, under the assumption that the user needs more help. Or, prompts can change just to make the interaction more interesting."
<joanie> jd: Having searched DuckDuckGo for "'tapered prompts' smil", the first results are our specs.
<joanie> jd: Let's remove it. Agreed?
<joanie> mk: Sure.
<joanie> mk: I'm leaving switch.
<joanie> jd: huh?
<joanie> mk: It's in related concepts.
<joanie> group: (remove it)
<joanie> jn: If no one knows what they are....
<joanie> mk: changes pushed
<joanie> cm: More SMIL references!
<joanie> jn + jd: New issue and pull request please. Right now we're trying to fix aria-expanded
<joanie> cm: Understood.
<joanie> group: (More nit fixing and discussion)
<joanie> jn: What about on application?
<joanie> jd: I think it probably should be.
<joanie> jn: Different issue?
<joanie> mk: The current issue is to ensure we have aria-expanded on all the roles it belongs on, and not on the roles where it doesn't.
<joanie> mk: I'm willing to add it.
<joanie> mk: The definition of "undefined" is weird.
<joanie> jn: It needs to be there. It can be expanded, not expanded, or not expandable at all.
<joanie> jn: aria-expanded implies you can change its state
<joanie> mk: I disagree.
<joanie> mk: If you have a treeitem and the tree is expanded and cannot be collapsed, does that mean....
<joanie> jn: You're right. It doesn't say that you can expanded it necessarily.
<joanie> s/can expanded/can expand/
<joanie> bg: If you have a listbox with multiple items showing, it's technically expanded.
<joanie> s/technically/visually/
<joanie> bg: I have had people suggest that using something like CSS to show one or a few elements means that the element in question is collapsed/expanded.
<joanie> bg: But I don't think that makse sense in terms of using aria-expanded.
<joanie> mk: Undefined, "The element does not own or control a grouping element that has an expanded or collapsed state"?
<joanie> mk: I was trying to capture what you said, James.
<joanie> jn: Don't worry about that. Let's try to keep it simple and not add words that someone might misunderstand.
<joanie> jd: Do we need to test removal?
<joanie> mc: We don't need to test the non-implementation.
<joanie> jn: We can do this through the validator.
<joanie> hs: We have a validator (axe-core) and can add a rule for this condition.
<joanie> jn: Can we add it to ACT?
<joanie> mc: Let's file in issue in github.
<joanie> jn: Or I can just email Wilco.
<joanie> mc: When we do a wide-review draft, we might wish to explicitly point this out.
<joanie> mc: We might want a detailed changelog
<joanie> jd: Are we going to land this today? If so, one of us should do the detailed changelog entry today so we don't forget.
<joanie> jn: Anything more?
<joanie> jd: Land it.
<joanie> jn: Land it.
<joanie> jn: Objections?
<joanie> group: no.
<joanie> jd: I will merge it and do a changelog.
<HarrisSchneiderman> https://github.com//issues/517
<melanierichards> scribe: melanierichards

[zcorpan]

I found this when researching for writing a new section in aria-practices for Controlling Widget States.

Here are the issues me and @spectranaut found:

• tabpanel - what is the advantage of using aria-expanded when aria-selected already indicates which tabs are selected?
• The spec is inconsistent about whether aria-expanded should go on tabpanel, tablist, or tab.

For a multi-selectable tablist, authors SHOULD ensure each visible tabpanel has its aria-expanded attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes set to false.

https://w3c.github.io/aria/#tab

For a multi-selectable tablist, authors SHOULD ensure each visible tabpanel has its aria-expanded attribute set to true, and that the remaining hidden tabpanel elements have their aria-expanded attributes set to false.

https://w3c.github.io/aria/#tablist

...but aria-expanded is a supported state on tab, not tabpanel or tablist

[jnurthen]

@zcorpan Can you please open a new issue for this. This issue has already been merged.

[zcorpan]

done #1032