<input> mapping constraints for role=combobox

[jlp-craigmorten]

Follows on from w3c/html-aam@bbf646a.

There have been prior changes in html-aam to update the mapping of the element (with type attribute in the Text, Search, Telephone, URL, or E-mail states with a suggestions source element) in the combobox scenario which deviate from the html-aria spec.

Filing this for consideration to make the equivalent changes to the html-aria spec for the role mapping definition of the element in the combobox scenario for consistency:

• Alignment on the list vs aria-controls constraints: "with a list attribute" in html-aria vs "with the aria-controls property set to the same value as the list attribute" in html-aam.
• Alignment on whether invalid type also falls into this scenario: currently present in html-aria but missing in html-aam
• Alignment on the suggestions source element constraint: currently missing in html-aria but present in html-aam, see "with a suggestions source element"

Alternatively, some changes for alignment may instead be better placed in html-aam, happy to raise suggested issues.

Pertinent areas:

• https://w3c.github.io/html-aria/#docconformance
• https://github.com/w3c/html-aria/blob/gh-pages/index.html#L1995
• https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings
• https://github.com/w3c/html-aam/blob/gh-pages/index.html#L1977

[scottaohara]

this seems to be more an issue about differences in wording for a spec geared towards implementers (aam) vs conformance checkers/authors (aria in html)?

I did however make a quick update to HTML AAM in the input type=text comments to refer to what HTML already specifies for the missing/invalid type attribute.

can you be more specific about what other updates you were anticipating per the other bullets? As i'm reading them, I'm not sure there's anything that needs to be done per the different audiences per each spec.

[jlp-craigmorten]

The main bullet was confused on was r.e. the use of list vs aria-controls (i.e. the first bullet - you've covered the second and have now come to realise the "suggested source element" wording is equivalent to "list" in the third point).

In aam I'm reading it to mean that the role of combobox is only applied to the input element if:

• It has a list attribute
• It has an aria-controls property
• And the list attribute value must match the aria-controls property value

The latter two points aren't mentioned at all in the aria in html spec.

aam:

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

aria in html:

input type=text, search, tel, url, email, or with a missing or invalid type, with a list attribute

It could well be that I'm simply misreading the specs(!), as you suggest perhaps the difference in audience is muddling me...

Is the requirement around the aria-controls something that implementors are expected to be doing (i.e. implicitly setting to the list attribute value) and therefore not something authors are required to set, or something that is being expected of authors, i.e. if you want a spec compliant combobox you must ensure you explicitly add the aria-controls property set to the same value as the list?

---

To add context to why I raised, the aria-controls aspect of the combobox role has previously caught out the maintainers of aria-query which has impacted the likes of the Testing Library packages and community. This has been reverted, but would be good to understand if it is a requirement or not going forward.

REF:

• input type="search" isn't considered of role "searchbox" A11yance/aria-query#511
• Image and combobox are not being detected by the getByRole. testing-library/dom-testing-library#1238

[scottaohara]

unfortunately it does look like there is a misunderstanding on your part for what HTML AAM is saying.

What's listed in HTML AAM are the mappings that implementors are expected to make, and are not requirements for authors. So per:

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

That's not saying authors need to add an aria-controls, it's saying the mapping for input type=... list=foo is a role of combobox, and the aria-controls property mapping for the element needs to reference the element with the ID matching the list attribute value.

i've made another update to the spec to link to the list attribute mapping table from this element's mapping table, as further mappings for aria-controls are outlined there. but yeh, unfortunately this just seems to be a misunderstanding of what this spec is saying compared to the aria in html spec which is more specific to author requirements for valid use of ARIA on differnet HTML elements.

[jlp-craigmorten]

Really appreciate the time taken to hand-hold me here @scottaohara! Thanks for the clarification.

[scottaohara]

maybe we should setup some time to talk about the goal of aria-query and to make sure requirements of these specs are being properly implemented in that package, @jlp-craigmorten. re: looking through A11yance/aria-query#515, there are some mentions of constraints being removed / variations between aria in html, aria 1.2 and html aam - but those also seem to be a bit off (at least from how i'm reading them?) the specs aren't misaligned, so much as they're telling different parts of the same story

for instance:

Removed aria-multiselectable constraint on datalist for listbox role. This is new in HTML-AAM Working Draft, but not in WAI-ARIA 1.2 nor HTML-ARIA W3C Recommendations.

there isn't really anything "new" in html aam, nor would it be appropriate/expected for the other specs to make mention of the specific mapping that HTML AAM is calling out. the only overt constraint for authors concerning this element/aria attribute would be defined in ARIA in HTML (the attribute is not allowed on the element because it's ignored by HTML). ARIA alludes to this at a high level in 8.5 Conflicts with Host Language Semantics.

[pkra]

@scottaohara @jlp-craigmorten perhaps we could file an issue on the ARIA spec to set up a dedicated deep dive call?

[jlp-craigmorten]

the specs aren't misaligned, so much as they're telling different parts of the same story

I fear again this is largely my error on interpretation there 😓 hopefully for the most part, despite my misunderstanding, the majority of changes in the PR are still correct, opting to lean towards the aria in html spec over the aam one (which going by your comments sounds correct from an authoring perspective). The issues prompting the change were mostly because the aam spec had been used as the source of truth (and perhaps in some places misinterpreted) in an earlier PR.

I'm not particularly associated with the aria-query repo beyond an invested interest (I have some screen reader automation projects on the go consuming it) but happy to chat nevertheless if believed useful! Conversations r.e. the repo are likely better placed with @jessebeach who afaik is the lead (or at least most active) maintainer (apologies for out of the blue tag!).

Happy to assist if/with any grunt work needed to have the package correctly reflect the appropriate specs.