Add aria-activedescendant

[teameh]

See this video on why this is important:
https://classroom.udacity.com/courses/ud891/lessons/8311490720/concepts/83106568490923#

(Screen readers are currently not reading out the items in the combobox)

To do:

• Add id's to all items
• Add aria-activedescendant to the input and reference the id of the selected item
• add aria aria-posinset & aria-setsize
• ...

I can work on this if you like, but #169 is blocking me.

[CMTegner]

Hi! This is great! We really hope you can help us out with this, as you already stated this is very important. We're here to facilitate in any way we can (I hope my answer in #169 was good enough to unblock you for now).

Regarding #1: The consumer has control over creating the menu items, so we probably want to put some though into how we handle this problem. Perhaps we could sniff the options and add IDs where they're missing.

[teameh]

Thanks, yeah that resolved my issue. I'm a bit busier than a month ago but I'll see what I can come up with.

Regarding #1: The consumer has control over creating the menu items, so we probably want to put some though into how we handle this problem. Perhaps we could sniff the options and add IDs where they're missing.

Or we could wrap the each item in an div and give it a random id?

[CMTegner]

Or we could wrap the each item in an div and give it a random id?

We could do that, but then the consumer is losing complete control over the dropdown markup (since the hierarchy will be menu > our wrapper > item).

I don't mean to devaluate your time, but could you summarise why IDs are important in this context? I want to watch the video when I have time, right I'm just working on getting through the backlog.

[wmitchell-cambria]

Heya. I came across this in investigating getting a screen reader (ChromeVox) to be able to read the items as they are highlighted by the autocomplete component. We think that if the aria-activedescendant property were set, then the reader would be able to pick up on the results.

I was curious if you have a plan for implementing this yet. Our items all have id attributes, so we are hoping to find some way to set the role as the highlighted item is changed. It sounds like sniffing the rendered items has some flaws, though. Do you have a better approach in mind? We're happy to make a PR to contribute back here, if we can find a way to get it working smoothly.

Or, maybe we are off base and there is another way folks have found to have a screen reader identify the highlighted items? It's been a couple years since this was active, so maybe somebody else has an easier way forward?

[catamphetamine]

@wmitchell-cambria

Or, maybe we are off base and there is another way folks have found to have a screen reader identify the highlighted items? It's been a couple years since this was active, so maybe somebody else has an easier way forward?

It is the way.
The other way is to move focus from the input to the list items.
See this article for more info:
https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/

I'm currently modifying our own home-made autocomplete to meet ARIA stuff.
This component claims to be "WAI-ARIA compliant" and that's a conscious lie because it's not.
Seems that the developers even didn't bother reading into what "WAI-ARIA compliancy" really is.
Throwing false claims left and right, how typical for modern frontend development.

To be clear: we didn't ever use this particular component nor will we ever be.
I just got here from Google looking for the ways WAI-ARIA support is claimed to be "implemented" in popular autocomplete components.

---

By the way, react-autosuggest seems to be the one actually supporting WAI-ARIA stuff.
https://react-autosuggest.js.org/