Discourse with a screen reader

We should probably go with the role for now… I suspect switching to H2 would break a lot of themes.


No problems, PR is in the oven.

This makes whizzing through topic lists so much more enjoyable on NVDA, you just hit h , h , h and move between topics.


It is too bad, h2 or h3 does make sense for the topic list. But that ship probably sailed 8+ years ago.


Hmm, not sure how I feel about the new region. It does add a tiny bit of extra speech to each post, but I don’t think it’s that bad, and it does add a bit of extra context to each post as you arrow through. I assume we can back it out at a later date if it turns out folks don’t like it?

I’m assuming these changes are live here? Seems so, and they do make the topic-browsing experience far more pleasant. Thanks so much for acting on this so quickly! When does the new release go live on hosted sites?


When we hit the deploy button :wink:. Your site is deploying now, should be live in ~20 minutes.



I assume we can back it out at a later date if it turns out folks don’t like it?

Yes absolutely, if the blind community feel this creates more noise that it actually helps I will be happy to roll it back.

The dropdowns that report to my screen reader as HTML <select/> s are almost entirely broken.

We have a library called SelectKit which we use in tons of places. You use that for selection of categories, selection of users when you create a private message, selection of “tracking state” for a topic (so you can say you are interested in watching a topic)

This library is absolutely not NVDA friendly, we are going to spend some time improving it, but I am sorry to say this is very complex work that may take a few weeks.

Today we rolled in a few more fixes which I am sure you will like. I recall you mentioned how hard it was for you to find the admin interface.

“go to another topic list or category” which exists at the top of the page is our “grab bag” area which includes links to site settings / admin panel / lists of topics in categories and more. @eviltrout changed it this morning so when you expand the list we focus to it. This certainly makes it a lot more obvious to NVDA.

I am spending lots of time learning about your experience, another issue I noticed today was the “lack of feedback” when you post a reply or a new topic. It is very hard for you to tell if it worked or not. We will try to at least do some focus tricks here to help you out. I do wonder if longer term we should add a “sounds” mode to Discourse so it gives you feedback about errors and success for various actions.

We have a long journey ahead, but I am very excited about it.

My goal - and Discourse’s goal - is not to be “as good” as PHPbb. What we want to be is your first choice cause we are better in all ways to the “old way”. It will take some time to get there, but we started the journey.


We could possibly use aria live regions for this; ARIA live regions - Accessibility | MDN. The common example is announcing the number of results after a search is submitted, but we could also have an empty div that we mark as a live region and add some “reply posted” text to it when needed.


live regions looks awesome, it may even be a possible solution for the select kit issues.

Oh looks like role=alert also does a great job with our various errors, adding it now!


@nolan a couple more cool fixes/improvements today. (note I am doing all my testing on NVDA)

  1. If you attempt to make post and it is too short, we provide an alert aria role, this makes the screen reader tell you what is wrong (post is too short etc…)

  2. I improved the “modal” focus logic, we will focus modals unconditionally now. This will allow you to discover the various keyboard shortcuts. A link to them exists in the “go to another topic list or category” section.

Changes are being deployed to your site right now.

Let me know what you think!


Okay, so I might be a bit nitpicky here. But the way topics are listed is kinda weird. It appears like the entire row is marked as a heading and not the individual columns. Like I said this is a really minor thing so I might just be nitpicking.


Oh wow, this thread seems to have blown up. I guess turning on browser notifications stops emails–need to see if I can fix that.

These changes are great! Thanks for them!

I concur about the topic list headings being a bit odd. I think I’d prefer it if the headings just bracketted the absolute essential details, since if I want the rest, I know where to get it.

If you look at the post display, for instance, the h2 role I added surrounds only the name and post time. Those are probably the details I care about most when pressing h/H to move through a post. For the topic list, I probably just care about the title and nothing more.

Ethin, I hope we’re referring to the same issue here, and that I captured your intent correctly. Please let me know if I’m off.


Also want to point out, @Sam that it’s not Orca friendly. Not sure if @Ethindp can help with Linux bug hunting or anything however, but at least on my (Ubuntu with Orca/Firefox) system, the drop downs are working a little bit

For instance, if I make a topic I can expand the category drop down and type in a category. I can open the state selection but it acts like a button if I expand that menu, I have to blindly (pun intended) hit the state menu and hope it’s what I’m after. I don’t know enough about Orca or ATSPI events to know if what’d work for one screenreader would work for Orca or if it’d be more work.


You can’t control atspi events from firefox so that isn’t an issue. The issue is just the role that’s presented to the screen reader – tell the browser using ARIA that a control is a combo box if it acts like a combo box. Remember: follow ARIA design patterns unless what your trying to do has no design pattern (which I imagine is pretty rare, that document is pretty comprehensive).
@nolan Yes, that was what I was referring to. The table navigation via headings through the table (and posts) slows me down because:

  1. All columns are a heading, or multiple headings – it reads like multiple. So it reads like this: topic title. Pause. Information for topic. Pause. Information for topic. Pause. etc. Orca, unlike NVDA, will read an entire table row when arrowing through it (or, in this case, using h to go through it) instead of individual columns like NVDA does.
  2. Posts are similar. All the post information is, again, separate headings, and are read as above.
    A solution would be to merge the respective columns containing only the important info into a single heading if that doesn’t break the visual layout. (To be honest, I’m not really a fan of the heading navigation through a table thing – it just isn’t how a table works and headings aren’t really supposed to go there.)
    One last small problem: all the headings appear to be the same level. This is problematic because screen readers allow me to jump around the page by different levels. Since all the headings are the same. I can’t jump between the topic heading and the related posts heading – I have to consequently read the entire topic, which gets annoying, especially on topics with huge numbers of posts.

At the moment we have the ARIA heading role on the entire row. I will move it so it is only on the essential information, the first column of the big table. (status, title, category, unread count and so on).

Should I go a step further and just put the role on the topic title only? I guess this does make stuff a big faster as long as you remember to navigate left and right for information about topic status, category and so on.

@celtichawk thanks! @joffreyjaffeux is option for a solution for dropdowns that should be compatible across JAWS, orca and NVDA. As I mentioned, it may take a bit of time, but we are working on it right now and hope to have something to show you in the next few weeks.

@ethindp I think I have an idea for the header situation in topics. We can put the header role on a single element like “username” and then give it an aria description of “Sam posted 3 hours ago”, then I guess it would say:

“Post #3 region Sam posted 3 hours ago” as you h through stuff. Should we try this?


I’d say give it a go. I actually like that idea. (Man, templates are awesome!)


Hmm, the first column is probably sufficient. Playing with this a bit more, I like that it not only reads the title, but also the unread status/count as well. I suppose I could live with it reading the rest as it does now, since thankfully that’s spoken last. But the first column only is more in line with what I’d expect.


Hi Nolan,

Was looking at changing this today but the TD element already has the role “rowheader”. I worry about fiddling with that.

I have a few options here:

  1. Change the role on the TD (table column) containing all the key info.

  2. Introduce the role on the link-top-line SPAN, it contains critical info but excludes categories and tags.

  3. I really don’t want to do this, but we could add a wrapper DIV

Which solution should we pick here?


Claus also raised issues with how quirky the heading role is. I am thinking maybe we just give a heading role to the “link” alone.

That way:

  • You do not read anything about status (locked, pinned etc)
  • You press H
  • You hear the title of the topic
  • You press H
  • You hear the title of the next topic

If at any point in time you want to discover special things about the topic or interact in a richer way you would press up or down to get more info.

It is not a perfect solution, but feels like a bit of an improvement to landing on the “pin” link or having the entire row read out.


Actually the use of a table to show the list of topics in a forum is really really good. All screen readers I know of that excludes Orca can navigate tables so if you get the correct row and colum information you have good navigation. The reason for requesting the headings on topics was to get a stable way to navigate an open topic. I see no good reasons as such to have the headings added in the table, but if done right they do not cause problems


I’d like to give a huge thanks to the people in this thread. I help admin a couple of discourse instances and have noticed most of the things mentioned here. I’d never put the effort into figuring out what could be done about it until yesterday the one forum got updated and things changed, for the better!!
Then this morning running across this thread gives me a lot of optomism that things will keep improving.
I don’t have a lot of specific suggestions, you’ve covered most of my pain points so i’d say keep on this road.
There is one that i don’t think was mentioned, at least not in this thread. That would be an accessible way to quote someone in a thread. If i want to quote someone i usually do it like this.

insert quote here.

But i wish i could use the proper quoting method. I don’t know markdown well enough to just write it out, and even if i did that sounds a bit painful. I’m curious what other tricks people use for quoting others in a thread if you can’t use a mouse?