jscholes
commented
3 years ago Update following Feburary 4th community group meeting: we ideally need more examples of where hint text from a screen reader conveys information considered critical to an assertion passing. In the case of macOS behaviour for combo boxes:
- For an editable combo box (https://github.com/w3c/aria-at/issues/340), as noted above VoiceOver only indicates that text can be typed in the control as part of the hint text.
- Question: is the role of combo box on the Mac sufficient to convey editable state on its own? I.e. should all controls that are identified by VO as combo boxes be considered to be editable?
- Currently, no. The select-only combo box (https://github.com/w3c/aria-at/issues/331) is identified as a combo box in Safari, but a pop-up button in Chrome.
- The Chrome behaviour matches that of native select-style widgets.
- We should file an issue against the Core Accessibility API Mappings, which currently include a mapping of "AXComboBox" for anything with a combobox role, regardless of whether it is editable or not. If a combo box is select-only, is it reasonable for macOS user agents to present a pop-up button instead?
This came up on an ARIA-AT CG call recently. For some controls, JAWS and macOS VoiceOver speak some associated help/hint text, which in VoiceOver's case is often quite substantial. Help text announcements are enabled by default, so will be heard by human testers. The question is, should these messages contribute to the passing or failing of assertions in any way?
A practical example: on the Mac, the main announcement for an editable combobox doesn't convey editable state, but the hint text does. If we provide testers with an assertion that the editable state was conveyed, should it pass or fail? Note that AFAIK, the help text isn't repeated when querying information about the control e.g. with VO+F3, so the assertion will fail in at least some circumstances.