Dropdowns for categories and tags are very problematic for screen readers

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. The focus must properly transfer to the input for searching. Right now, it gets stuck on that button, probably due to issue 2 above.
  3. 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!



Yes it’s on our list to improve, thanks for detailed report.


Thank you, that is good to know. Is there a GitHub issue or PR I could track?


Nothing to watch yet sorry.


I’ve seen this with Ember components before, so I don’t know if this is something you can fix in your code

I have some good news here, we actually own all the code for the tags and category dropdowns. We implemented them ourselves in a library call “select kit”.

We should be able to address all your concerns here, as soon as we have something for you to test we will let you know!

Thank you so much for such a detailed and thorough report!

I think the best thing to watch is this topic (since you created it, you are probably watching already)

We will reply here as soon as we have something ready.


Thank you, @sam! That is definitely good to hear.


Just an update on this, it’s at the top of my priorities but we are entering pre-release period and this might end up being a big change, so I won’t start working on it before at least 3 weeks.

I’m really sorry for the inconvenience this is causing, we are working a lot on accessibility since the beginning of the year, and I’m pretty sure that by the end of this year we will have achieved major progress.


Thank you, it is good to hear that this is being prioritized. It seems to be a fairly recent change, though, since the other Discourse instance I quoted is on an earlier 2.7 beta which does not have this problem. Or is this also theme-dependent? Feel free to CC me on any GitHub PR or such that involves this work. The user name there is the same as it is here.

1 Like

Yes I know what recent change it was, but afaik it was already not perfect before that change. But it was probably better indeed, will see if I can revert part of it Monday.


Any updates on this would be very much appreciated. This is a high-priority issue for screen reader users, as it prevents their ability to efficiently select a category when they are creating topics.

It’s almost done, Im on vacations and will release it when Im back in about 2 weeks.


Much appreciated!

Have a great holiday!



Just a note I expect something merged by the end of next week


I deployed the future update on Meta, you can try it from now if you have some time :+1:


Is it better @MarcoZehe?