Aria-practices: Example 1 and 2 of aria 1.1 Combobox | Suggestions are not announced to screen readers

[DanielaValero]

Hello everyone,

I was jut checking the examples with voice over, and noticed that only in the 3rd example the list of options is announced to the screen reader.

Below the steps to reproduce etc.

My question is:
My assumption is that the screen reader user should have a similar experience than users who don't use it, and that is what it makes it accessible.

In the examples 1 and 2, my assumption is that the screen reader user should be announced that there is a list of options for them to choose from.

Some days ago I did a research on different patterns for this, and made a very rough, not production ready codepen for how an autocomplete would look like if it's not a comboBox.

What is your view on this? I would be glad to make a PR if you think my assumptions and alternative of solution are relevant

---

Steps to reproduce

1. Go to link: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
2. Enable for example VoiceOver and navigate with tab to the first example
3. Type for example: "Apple"

Expected behaviour

The listbox of options is announced to the screen reader

Actual behaviour

The list is not announced, therefore all the screen user knows is that they are in a text field.

[JAWS-test]

As far as I know, it is halfway correct that the listbox of a combobox is not announced, because the screenreader user hears when focusing the combobox that it is a combobox and not an input field. It would be nice, of course, if the number of filter results is announced when entering text (analogous to input fields with autocomplete function), but this does not seem to be planned yet.

[DanielaValero]

Hello @JAWS-test,

I get then that having the feature of telling the user the number of available results (so that they know that there are options for them to choose) is something that for now we could implement directly in our component/project. And hopefully the spec will define something, so that it works out of the box. Right?

[JAWS-test]

Users know that there are list entries because of the combobox role. They don't know how many list entries there are, so I would recommend to output this additionally via a live region (aria-live=polite). I personally think it makes sense that the number of list entries should be output automatically.

[JAWS-test]

I think that the error is not on the listbox popup example page, but in the specification for role=combobox or the respective screenreader. E.g. <input list> <datalist> does not output the number of list entries, <select size=1> does. See also: https://github.com/FreedomScientific/VFO-standards-support/issues/218 and https://github.com/FreedomScientific/VFO-standards-support/issues/221

Editor note: please wrap your links in markup notation: [text](URL)

[ZoeBijl]

For what it’s worth: the Authoring Practices provides information on how ARIA should be used. However It does not provide guidance on how to deal with browser/AT bugs. Some backstory on this can be found in this mail thread.

I’ll leave further questions regarding this pattern’s example to @jongund.

[mcking65]

@DanielaValero, there are quite a few fundamental problems with the ARIA 1.1 combobox pattern.
We currently have several revisions to the combobox pattern in the
draft version of ARIA 1.2,
and a new version of the pattern and examples in the corresponding
draft of APG 1.2.

Screen reader support for the 1.2 pattern is better. And, if these changes make it into the final spec, in the coming year, we will be working with screen reader developers to resolve remaining issues via the aria-at project.

As of now, given the new pattern and examples, there is nothing further to change related to this issue, so I am closing it. After reviewing the latest combobox spec, pattern, and examples, if you still have questions, please open a new issue.