Windows/Mac differences in presentation of some HTML-AAM implicit roles

[cookiecrook]

While working on HTML-AAM automated role tests, I noticed there were a few implicit role expectations that seemed to align with a Windows-style rendering, but did not align with the macOS renderings.

In particular, this test of a select list without a size attribute:

<select data-testname="el-select-combobox" data-expectedrole="combobox" class="ex"><option>a1</option><option>a2</option></select>

Yields: assert_equals: expected "combobox" but got "button" in WebKit on macOS.

A true combobox is always (or almost always?) rendered as a text field with text-carat insertion and an associated menu. That's not the case for simple <select> menus on Mac. They actually render a button that triggers a menu.

Screen shots of simple select (not a "combobox"):

I think this represents a platform-level user interface different that should be conveyed to the user of assistive technology. A Mac VoiceOver user would expect they could literally type or select text in a combobox, and that's not a valid assumption here.

In a related but inverse scenario, macOS renders <input type="number> as a text field with enclosed steppers, as opposed to the Windows-style "spin button."

Screen shot of simple number input (not a "button"):

Note: I'll try to add some screen shots of the equivalent Windows control to further the discussion.

In summary

• It's possible some of the HTML-AAM implicit roles need changes, or platform-specific allowances. (This HTML-AAM issue.)
• It's seems clear to me that some presentation-specific role names (spin button, progress bar) in ARIA can result in UI confusion. It may be worth considering replacing these with less UI-centric synonyms, perhaps progressbar -> progress and spinbutton -> number or spinbutton -> stepper. (New ARIA issue?)

[JAWS-test]

The difference in select is indeed relevant, but in spinbutton (input type=number) I don't see the difference between Mac and Windows, m.E. in both the HTML element is implemented the same. That the ARIA role spinbutton allows additional variants is correct, but has nothing to do with the operating systems (see https://github.com/w3c/aria-practices/issues/1155)

[JAWS-test]

Related: https://github.com/w3c/core-aam/issues/111

[spectranaut]

Discussed in the ARIA working group today: https://www.w3.org/2023/04/20-aria-minutes#t05

[scottaohara]

Reminder to consider the points raised in this issue when working on this one: https://github.com/w3c/html-aam/issues/473

[smhigley]

Another consideration that came up in the call -- certain attributes like aria-invalid are valid on a <select>, but not on a button role.

[JAWS-test]

Another consideration that came up in the call -- certain attributes like aria-invalid are valid on a select, but not on a button role.

Also true for

• aria-errormessage
• aria-readonly
• aria-required

Furthermore, a select has a value and a label, a button has only a label, no value.

[spectranaut]

To schedule after TPAC