Hi there to the team!
The dropdowns as they currently appear on this Discourse instance are very problematic for screen readers. They are a - sorry - mess of inappropriately nested ARIA roles and not working keyboard functionality. I’ve seen this with Ember components before, so I don’t know if this is something you can fix in your code, and then maybe float upstream, or have to wait for some upstream component author to fix. However the way it is now, these are close to impossible to use for screen reader users. Sorry for being so blunt, but it is that urgent.
Here are the problems:
- The dropdowns for categories and tags are themselves declared as a div with a role “combobox” on the outside. However, according to the ARIA authoring practices, for such comboboxes or autocompletes, the role should normally go on the direct parent of an input, or on the input itself. I also see an aria-owns attribute there that has me very worried. aria-owns should really only be used if the author are absolutely sure they know what they’re doing. Experience as an accessibility advocate for 15 years working with this ARIA stuff has shown me: 99% of the times it is got wrong. So this probably needs to just go away.
- The next child is a button, or rather, a div with role “button”. That alone is an error, since a button can’t be the child of a combobox. It is forbidden. This may be solved by getting rid of that aria-owns, I actually don’t know how badly this tangles up things with one another.
- But it gets worse: The next child is a normal input element. The button semantics from the parent completely obscure this. Never never never NEVER!!! nest interactive elements within a button. It is the accessibility death to any semantics. Buttons may only contain graphic or text children that convey its meaning. Even buttons that open a popup menu must have these menus as siblings, not children. Screen readers are not able to figure out which is the actual active elements. And buttons are not containers.
- The list, once opened, does not have its active element spoken when arrowing. Considering the mess with the button and obscured input element above, this is not surprising. It is a hit or miss game finding the right category and/or tag. For example, while composing this post, I had to open that dropdown for the cateogry three times before I found the UX category.
To clean this up, several things must happen:
- If the button is supposed to bring the input and list into focus in the first place, it needs to be a separate control that un-hides an adjacent combobox or edit combo, or whatever autocomplete mechanism is intended. This probably earlier instance of Discourse at https://forums.classicpress.net still gets this right, but some time later this was badly broken and is on Discourse Meta now. This may be solved by untangling the mess caused by aria-owns, see above.
- The focus must properly transfer to the input for searching. Right now, it gets stuck on that button, probably due to issue 2 above.
- When selecting a different element from the list using the arrow keys, aria-activedescendant must be changed to point to the ID of each corresponding option item so accessibility focus can fire. Again, the previous implementation of Discurse quoted above gets this right.
This pertains to all dropdowns I’ve seen so far, both in the main view as well as when composing a forum post.
I am happy to help with testing if need be. But if you release this, you will massively regress screen reader users.
Tested on Windows 10 with NVDA and Firefox and Chrome/Edge.
Thank you for reading and sticking with me through this long and urgency-filled post!
Marco
