Revise allowed aria-* attributes for HTML comboboxes and listbox

[scottaohara]

ARIA's role=combobox and role=listbox have a number of supported, inherited, and with combobox, required attributes.

With their current native HTML equivalents select, input list=foo and select size=1+ or multiple, many of these attributes that are necessary in the construction of fully custom ARIA equivalents either have no actual usefulness, or can conflict with with strong native semantics and functionality of the HTML elements.

ARIA in HTML needs to specify which aria-* attributes are not valid for authors to use on these implicit combobox and listbox elements.

This issue supersedes issue #277 and #364.

[scottaohara]

Initial thoughts:

input list=foo Authors MUST NOT use aria-activedescendant, aria-autocomplete, aria-expanded, or aria-haspopup on inputs with a list attribute.

select (combobox) Authors MUST NOT use aria-activedescendant, aria-autocomplete, aria-expanded, or aria-haspopup, aria-readonly attributes on a select element with an implicit combobox role, or a menu role.

Note: aria-multiselectable is not a supported attribute on role=combobox, so the SHOULD NOT rule that the spec has for this now is unnecessary.

select (listbox) Authors MUST NOT use aria-activedescendant, aria-haspopup, aria-orientation, aria-multiselectable or aria-readonly attributes on a select element with an implicit listbox role.

related #385, but is applicable here since ARIA 1.2 combobox pattern specifically moved away from using aria-owns, and UA rendered listbox elements won't respect aria-owns for options in any way that would be useful to users.

re: aria-readonly, the native HTML readonly is not allowed on select if rendered as a combobox or listbox. The state is not exposed when testing on macOS browsers. While a valid attribute for ARIA versions of these controls (unsure on actual support there either, though), it likely would not make sense on the native HTML versions.

[JAWS-test]

aria-readonly is not output by JAWS+Firefox, JAWS+Chrome, NVDA+Firefox, NVDA+Chrome on HTML select multiple, select size>1, select size=1 (in form mode and in reading mode).

aria-readonly on elements with implicit role=listbox (select size >1 or select multiple) results in the following incorrect output in reading mode of the screenreaders in Chrome:

• JAWS: selection list is not output (as if it were not present, this also applies to the quick navigation with C or F5 and the element overview with INS+F5, INS+Ctrl+C).
• NVDA: selection list is output with all list entries and the selected list entry is not perceptible (without aria-readonly only the selected list entry is output and the others are not).

I was very surprised by the results because I assumed that I could use aria-readonly on HTML elements as well, at least on those whose implicit role is identical to the ARIA roles where aria-readonly is allowed. This does not seem to be the case. My question would be whether this is a peculiarity of the HTML element select and the aria-readonly attribute, or applies generally? To my knowledge, most ARIA attributes also work fine on HTML elements. I would be in favor of ARIA working as expected with HTML and am against introducing too many exceptions. This would mean that

• aria-readonly must also work on the select element and the screen readers make a mistake here or
• aria-readonly should be allowed in the ARIA specification only for ARIA roles where readonly is also allowed in HTML.

[JAWS-test]

aria-readonly is also not output by JAWS+Firefox, JAWS+Chrome, NVDA+Firefox, NVDA+Chrome on ARIA role=listbox (in form mode and in reading mode).

The bug in reading mode (element is not noticeable at all, not even in the element overview and quick navigation) occurs with role=listbox with aria-readonly=true in Firefox and Chrome. This would be an error of the screen reader, because currently aria-readonly is allowed.

Similarly, readonly is not output for role=combobox (https://github.com/FreedomScientific/VFO-standards-support/issues/481, https://github.com/nvaccess/nvda/issues/8763)