input[list] maps to invalid combobox

[Jym77]

<input type="text" list="foo"> maps to

combobox role, with the aria-controls property set to the same value as the list attribute

However, combobox require an aria-expanded state (both in ARIA 1.1 and 1.2) which is not set here.
This result in such inputs with suggestion list mapping to invalid combobox 😞 and authors need to manually handle the aria-expanded state (and often forget it just because they don't know about it…)

I'm however not sure that the expansion can be automagically set (not finding anything obvious in HTML specs).

[scottaohara]

This issue is inaccurate, and thus I'm closing it.

If you follow the mapping for combobox over to CORE AAM, the combobox role already takes care of the aria-expanded state. list does not map to aria-expanded, which is why it is not called out here, as this list attribute has nothing to do with the exposure of the expanded/collapsed state.

Furthermore, the requirements of the ARIA spec are for authors building custom ARIA comboboxes. To assert that authors need to explicitly declare aria-expanded when using input list=... is incorrect.

[Jym77]

I'm glad this is not a problem but I'm struggling a bit understanding the how and why of it. I feel I need a bit more explanations and pointers 😕

---

If you follow the mapping for combobox over to CORE AAM, the combobox role already takes care of the aria-expanded state.

That's a bit I fail to follow. I am not super fluent with reading the Core AAM…
When I look at Core AAM for combobox I do not see anything telling me how to handle aria-expanded. Similarly, Core AAM for aria-expanded (plus two following entries) doesn't link to combobox and doesn't help me understand how it's mapped (likely I don't really know how to read these tables and therefore don't understand them…)

The closest thing I'm finding that could relate to that is the first point of General rules for states mapping stating

User agents MUST compute managed states VISIBLE/INVISIBLE, SHOWING/OFFSCREEN, etc.

But then the definition of managed states makes this feels a bit circular:

Accessibility API state that is controlled by the user agent, such as focus and selection.

So, user agents must compute "managed state" and "managed states" are state controlled by user agents. That doesn't help me figure out whether aria-expanded is a managed state or not 🤔

The State and Property Change Events for aria-expanded seems to indicate that aria-expanded must be changed by user agents when some events are fired. Is this the bit you refer to when you say that in the Core AAM "the combobox role already takes care of the aria-expanded state"?

---

list does not map to aria-expanded, which is why it is not called out here, as this list attribute has nothing to do with the exposure of the expanded/collapsed state.

The list attribute indeed has nothing to do with the aria-expanded state, but it changes the role of <input> elements. <input type="text"> has a role of textbox which has no required state of property (ARIA 1.2 definition of textbox), and therefore maps to a valid textbox. On the other hand, <input type="text" list="foo"> has a role of combobox which requires both aria-controls and aria-expanded (ARIA 1.2 definition of combobox); The HTML AAM tells me what aria-controls should be, but not what aria-expanded should be. While the list attribute has nothing to do with aria-expanded, its presence does change the role and therefore the required states and properties.

---

Furthermore, the requirements of the ARIA spec are for authors building custom ARIA comboboxes.

I'm also not sure I understand that.

I get it that if an author wants to build a combobox (or any other role) with <div role="combobox">, then they need to make sure the combobox has all the required states and properties, owned elements, contexts, …

But then, I also thought that "native" comboboxes (or other roles) built by user agents also need to have all the required states and properties, … I'm reading your answer as implicitly saying that user agent built components are not required to follow ARIA specs. Which sounds so weird that I think I'm completely missing the point 🤔

---

Digging through Chromium sources, I've found several places where aria-expanded seems to be managed. I don't fully understand what happens there; nor am I certain I've found the bit concerning combobox. But it does look like Chromium is reacting to some events by toggling aria-expanded, which is good. I am however not sure why they do it (well, I mean, I know why but I can't find for sure which piece of specs tells when and how to do so).

---

We've been running some tests with a colleague, between a "native" text field combobox:

<input type="text" list="foo">
<datalist id="foo">
  <option value="foo">foo</option>
  <option value="bar">bar</option>
</datalist>

and the ARIA example one. The later is built with an <input> without list attribute, and manually setting role="combobox" and managing aria-expanded.

Now, the point is that both NVDA and Jaws behave differently on these. Both of them announce the "ARIA example" one saying it's "collapsed" but don't say anything similar about the "native" one. It doesn't means the native one is bad, of course. But it shows that these are handled differently, and especially when it comes to their expanded/collapsed state. So they seem to handle aria-expanded in different ways. Again, it doesn't mean one of them is bad, just that there is some difference here.

---

I'm actually having the same question (I don't dare say "problem" now 😅 ) for <select> combobox…

<select>
  <option>Foo</option>
  <option>Bar</option>
</select>

This has a role of combobox according to the HTML AAM, but here also the HTML AAM doesn't says what aria-expanded (nor aria-controls!) should be, and I don't find where this is set.

Does that piece of HTML builds a valid combobox? (and why?)

[scottaohara]

Thank you for your detailed response, I think I better understand where the disconnect is here. I likely am not answering all your questions with what follows, and truthfully you have a lot of questions that would require far more time than I am able to spend.

At a high level I will say this, I think what HTML AAM can do here is make mention of what properties browsers should (or 'may' - as not all the platform apis are exactly the same, and the expectations for each can be different) be exposing with certain roles. This clarification would be in alignment with adding some clarity of what "Use WAI-ARIA mapping" means - issue #122. As you should have also noticed, the ARIA specification makes mention of far more than aria-expanded for a combobox. aria-haspopup, aria-autocomplete, aria-activedescendant... an element's role mapping and individual attribute mappings may not cover every single state/property – browsers can handle these differently in their native implementations, and what is exposed to the user may be different as a result.

I'm reading your answer as implicitly saying that user agent built components are not required to follow ARIA specs. Which sounds so weird that I think I'm completely missing the point

My statement was specifically about authors. I made no assertions about requirements for user agents, so you have misunderstood/assumed something I was not stating. My point with my previous comment was that if an author is building a custom ARIA combobox, then they need to follow the rules of the ARIA specification. If they implement a native HTML 'combobox' (via input list=foo or select) then they need only follow the HTML specification. Saying to authors that they need to add ARIA attributes to these native controls is poor advice, and could very well make things worse if author defined states/properties are not in alignment, or unnecessarily/unexpectedly overrides how the native element behaves - which can be different depending on the browser / OS (platform).

HTML AAM states to use the combobox role for select and input list=foo. The mappings for the combobox role are defined in Core AAM, which HTML AAM links to. Core AAM defines the platform mappings for the combobox role, AND points to the ARIA specification to outline everything needed to implement a combobox. If a user agent is not following those requirements, then a bug can be filed against the user agent - not an author. An author can be advised to not rely on a native feature if it has poor accessibility support - but I would submit that if a user agent implementation of a native combobox is working as expected for that particular platform, but it is not exposing the expanded/collapsed state, there may very well be good reason. As you said:

Again, it doesn't mean one of them is bad, just that there is some difference here.

[Jym77]

Thanks for the answer, I understand a bit better how these documents articulate. A few more questions and precisions…

• combobox indeed refers to much more than aria-controls and aria-expanded. But these two are required while, say, aria-haspopup isn't. As an author, I could build a good custom combobox by only handling aria-controls and aria-expanded. As a user, I would expect a combobox to have these two states/properties, but I wouldn't expect aria-haspopup. Hence me focusing on these.
• I'm certainly not advicing authors to add the ARIA attribute on native elements. Sorry for my poor choice of words. Due to not seeing how aria-expanded is set on native combobox, I was under the impression that input list=foo would create a bad combobox (by strictly following specs). To me, that issue looked a bit like value should map to aria-valuenow for input[type=range] #314 where a mapping is indeed missing from the HTML AAM.

---

Maybe I should have given more context on my question…

As a tool vendor for the automated checker Alfa, we do have a rule that check that elements with role have all their required states and property (https://alfa.siteimprove.com/rules/sia-r16). This expands a bit on the corresponding ACT rules (https://act-rules.github.io/rules/4e8ab6) The ACT rule only checks elements with a role attribute (i.e. custom elements) while ours also checks elements with implicit role.

We had quite a few discussions (internally) as to whether we should indeed test native elements or just rely on the UA to correctly build these elements. We end up deciding to keep the rule as is precisely because it let us detect bugs in UAs or in specs. Typically, we've figured out that #314 was a problem with the AAM (6 months after it was found in the AAM, but still 🤷 )

Recently, we've been reported that we were flagging an <input list="foo"> as missing aria-expanded. Since, as you point out, it would be crazy to require authors to manually handle ARIA stuff on native elements, I gave it the same treatment as #314 and assumed something was missing here.

I guess I was wrong.

---

If I'm summing up the discussion correctly, it would be that the AAM is to be seen as the minimum mappings that UA should do; but they may do more for the stuff that is not specified (i.e., the AAM is not exclusive).

That is, as an UA writer, if I decide to map <input type="text" list="foo"> to a button; or to maps its aria-controls to bar, I am a bad UA writer. But what I do with aria-expanded is what I want (well, sort of), and the HTML AAM doesn't tell me what should happen with it, it's up to me (as UA writer) to handle it satisfyingly…

That is freaking me out a bit 😕 But I guess I'll have to find a way around it…

[scottaohara]

re: aria-haspopup not being required -

it's not required to be declared by an author, but it is very much necessary for a combobox. The reason it is not required by an author is because the combobox role has an implicit aria-haspopup=listbox. At the platform level - as mentioned under MSAA/IA2 & ATK there is a state for haspopup (again note, aria-expanded is handled under the combobox role here too.) So, shifting again to user agents - it would be highly expected for a UA to make sure this information was implemented in their combobox...

Re: telling authors to add ARIA attributes to native elements -

SiteImprove is apparently currently flagging input list=foo as some sort of failure due to lack of aria-expanded, which is being interpreted by at least one developer as indicating he needs to add aria-expanded to his native HTML combobox. Native comboboxes (windows/macOS) can expose the expanded/collapsed state without it ever being announced by a screen reader. The HTML select element exposes an expanded/collapsed state, but this is not announced... and that's ok.

Re: the Alfa checks expanding on the ACT rule only checking elements with a role attribute -

I'd submit that Alfa may be going somewhere it shouldn't here. An author shouldn't get flagged for an issue with an HTML element(s) - unless it is a potential warning about a possible short coming with the accessibility support for the element in question. The information is here, in core aam, and in ARIA for how these elements/roles/attributes are standardized. Where rules like this can be helpful, though, is in making sure that web authors are not using ARIA incorrectly and thus potentially mucking up a native implementation. (this issue was helpful in making me realize ARIA in HTML has a gap here w3c/html-aria#364)

Re: issue 314 - that is a gap with the spec matching reality. The attribute and noted aria-* referenced in that issue have a direct one to one attribute correlation and need to be called out here - which is different from the issue you raised here. It's already covered by the combobox role definition in core aam / requirements of ARIA (also yes, 6 months for that issue... PRs are always welcome, as otherwise things get worked on as time permits....)

Re: your summary, specifically "it's up to me as a UA writer"

Your "well sort of" is the key there. Again, here HTML AAM is pointing to Core AAM. Core AAM is defining mappings for the role, and all the aria-* attributes. THe ARIA specification outlines the requirements for creating a combobox - so, as a UA writer, you follow the requirements, and if you notice that there is a gap in a native implementation that is not made by a web author, then that's a gap with the (in this case) browser. Not an author error.

[Jym77]

@scottaohara Once again thank you for your patience and your answers.
It seems I misunderstood deeply how the Core and HTML AAM work (I must confess I never read the Core AAM thoroughly…) I guess it's back to the drawing board for me 😕
(I've hacked around that specific issue for now, and will spend time later to investigate deeper and build a correct solution (likely reverting the rule to explicit roles only but given it was built that way and later changed, I want to make sure I understand what happens)

(also yes, 6 months for that issue... PRs are always welcome, as otherwise things get worked on as time permits....)

Apologies for my poor choice of words (and emoji).
I didn't meant that "6 months is too long and this should have been fixed". I meant that we (=Siteimprove) "discovered" that problem 6 months later than you (=HTML AAM) did. So our discovery wasn't that helpful in that precise case (we didn't report a new issue).
I know all about lacking time to fix stuff and I'm definitely not blaming anybody for having issues that are several months old (or more…)
Sorry again for conveying the wrong meaning.

[scottaohara]

appreciate the follow up, @Jym77 and thank you for the conversation.