Better aria-expanded defaults for combobox

[WilcoFiers]

Under combobox it says:

Authors MUST set aria-expanded to true on an element with role combobox when it is expanded and false when it is collapsed

Requiring authors to set the aria-expanded attribute explicitly, even when the correct value can be inferred from aria-controls seems like an unnecessary point of failure. Have the few user agents do the lifting on this, instead of making every author do it.

I thought about leaving a similar comment for aria-controls, but that one's a little tricker, as the control might not be in the DOM in its collapsed state, so its default can't be guaranteed.

[JAWS-test]

even when the correct value can be inferred from aria-controls

How it can reliably inferred from aria-controls? There are several ways to show and hide the selection list, and it is difficult for AT to know what state the list is in

[jnurthen]

marking 1.2 for now

[WilcoFiers]

How it can reliably inferred from aria-controls? There are several ways to show and hide the selection list, and it is difficult for AT to know what state the list is in

If aria-controls doesn't refer to an element in the DOM, or it refers to an element with the hidden state set to true.

[JAWS-test]

And some stupid web developers only hide the controlled area visually and/or mark it only with aria-hidden. I.e. there are many methods and for AT it is hard to determine.

[mcking65]

@WilcoFiers, I am not opposed to this kind of simplification, but am not sure the investment is worth the potential benefit.

this is only beneficial to authors if consistently implemented across all browsers. If there is one browser that does not do it, then authors have to apply the correct value of aria-expanded. It is probably easier for authors to code aria-expanded than it is for them to ensure it works correctly in all browsers.

We currently have similar issues with aria-level, aria-posinset, and aria-setsize. This has created challenges in the authoring practices where we provide versions of some patterns that declare these properties and versions that do not.

It's a bit late to add this to ARIA 1.2. We could probably get 2 implementations, which would get us through the process, but we would not get them all. This is the kind of requirement where we would want positive confirmation from all the leading browser developers that they agree with the lift before pushing it into the spec.

BTW, If we did this for combobox, would it then create an expectation with authors that it also works with menu buttons, accordions, disclosures, parent menu items, and parent tree nodes? Browsers could have similar algorithms for those patterns and widgets. But, that would be a significantly larger investment by browser developers.

My recommendation is that we not do this. However, if the group consensus is to add it to ARIA, then I recommend we target ARIA 1.3 and only keep it if we can get broad agreement.

[carmacleod]

The ARIA Working Group just discussed Better aria-expanded defaults for combobox.

The full IRC log of that discussion

<carmacleod> github: https://github.com//issues/1177
<carmacleod> mck: waiting for feedback. think we should close or move to later, but want feedback from reporter

[jnurthen]

@WilcoFiers moved to 1.3 based on no objection from you to @mcking65 comments above

[WilcoFiers]

No objection to deferring this for 1.3.

[jnurthen]

@mcking65 any updates

[mcking65]

It is not clear to me we have a consensus path forward on this issue.

I believe this issue is requesting:

1. Change aria-expanded from required to supported for role combobox.
2. Specify a default value of aria-expanded=true for role combobox.
3. Change the normative authoring requirements for role combobox such that authors are required to specify aria-expanded only when the combobox is expanded.

Is that correct?

If so, what are the benefits of the above changes?

@WilcoFiers, it might be the case that I am completely overlooking the problem that inspired this suggestion. Without a better understanding of the problem, I see some potential downsides to making the above described changes:

1. Increased complexity of validation.
2. Increased opportunity for author error.
3. Increased complexity of authoring guidance, APG examples, and aria-at testing.
4. New user agent implementation work that may not happen due to a lack of high impact benefits to authors or users with disabilities.
5. Reduced interoperability if user agent implementation is uneven.

[jnurthen]

@WilcoFiers can you please respond