Last week I used Discourse with a screen reader (NVDA) for a day and this problem was my #1 frustration, so I very much want to fix it.
When you enter a topic from a topics list like /latest, Discourse scrolls you down to and highlights the first unread post in the topic or to the last post if there are no unread posts. This works great for sighted users, however screen reader users are not made aware of this because the focus is not moved at all when you enter a topic so screen readers will just start reading from the top of the page.
I’ve deployed a theme component here on Meta to test my fix for this problem. Can anyone that uses a screen reader test the fix and see it it makes things better (or worse ) please? Enter a random topic, read a few posts, leave the topic and enter it again, can you easily tell that Discourse put you at the first unread post? Any improvements we can make?
Oh this is very nice and does seem to help quite a bit, though I haven’t tested it exhaustively. I do think it’s a solid improvement.
One suggestion I’d make: If I click a topic, read to the end, then press Back in my browser, is mouse focus kept on the previously-clicked topic? I can tell you right now that my next biggest frustration will be having to navigate back to the topic I clicked into in order to find the next topic. If I click a topic and press Back, could keyboard focus be placed on that topic’s link in the list?
Oh and BTW, there’s some weird control labeled something like “Select % name or value” below the last post in a topic. Is something not correctly escaped? I don’t know the exact value of what was spoken since I’d probably have to copy the phrase directly from NVDA’s speech buffer. It didn’t appear in the page text itself.
@osama I think there is a small regression here, tested on both Chrome and Safari. As I scroll through the topic list, there is a focus “ring” on the first topic of the next payload. Here is an example:
@ndarilek how is the current experience for screen reader users? I’m looking for a discussion board to integrate in a learning management system that was built with screen reader users in mind. Thanks.
A lot better than it used to be, and very usable, though I’m a bit worried that it may have stalled.
In particular, I’m not sure my concerns from post 88 were addressed, and as I predicted, these are a pretty big annoyance for me now that many of these accessibility changes have propagated out to Discourse installations. If I click a topic, read through it, then click Back, focus seems to land way up top in the originating thread list. So for instance, if I’m looking at the 50th post in a category, click it, read through, then click Back, focus is then thrown to something like the 20th post in the originating list. I then have to return to where I was (I.e. the 50th post where I clicked the link) then continue browsing. This usually involves me having to remember the thread title, hoping it was unique enough, then searching the page for that title to hopefully land on the link I’d originally clicked. I’m guessing it returns focus to the first visible post link in the category, but it should really return focus to the post that was last opened. It sounds like a small thing, but multiply it over 5-10 reads with me having to take a minute or two to refind my original position, and I usually fatigue out of participating in the community after a few repeats. I’ve literally stopped reading a number of Discourse forums not because I didn’t find them interesting and want to participate, but because the friction of having to find my focus again for the half dozenth time was a bit too much.
So in short, I’d say it isn’t bad and is certainly a lot better than it used to be. But I really wish this issue in particular could get addressed, because if screen reader users are tapping out after a few minute-long sessions of “find the old focus,” then those are voices that aren’t participating in your community. I know resources may be spread a bit thin, but as an accessibility professional, I’d feel confident in saying that this level of friction is likely a bit too much to encourage the kind of long-term participation most Discourse communities hope to achieve.
Having said that, I’d still like to take a moment to acknowledge that things are much better than they were a bit over a year ago. Thanks a bunch for that!
That sounds like a problem that should be fixed, and I think that someone might, but that’s not my job.
A thing that you might try as a workaround until then is to continue scolling down to the bottom of the topic where the suggested topics are. It’s a decent possibility that one or more of those topics will be an appropriate place to go next. I don’t know if it’ll help or not.
Nolan, thank you so much for baring with us here! I am going to make sure we invest some time over the next month resolving the focus issue (we test on NVDA, hopefully it will catch JAWS and orca as well)
Let us know any niggles (or major annoyances) you discover, we want your experience using Discourse to be delightful.
Just this month @kris.kotlarek implemented aria labels for our composer warnings. This means that if you try to submit a topic and forget to enter a title we properly call out that it is missing!
Hi Nolan, I’m very sorry that this has taken us so long to fix, but I have some good news! The issue was fixed last week and since then it’s been deployed to every Discourse instance that we host including this site. Could you please try and let us know if it’s working as you’d expect? Any additional improvements would you like us to make?
Also, the “Select % name of value” problem that mentioned here:
was fixed by @joffreyjaffeux back in January. Do you still encounter that problem?
Oh this is very nice. I browsed another instance for a few minutes and it behaved rather well. Focus correctly returned to the previous topic when backing out, or to my place in that topic when I returned.
Thanks! This makes Discourse much more enjoyable to use.
I am bak on a few things I would like to see improved for screen reader users.
Over the last days I have been wanting to use the users list on my small forum, but have found the nice table to be in reality useless. Brugere - Discourse Meta
It seems that the top row is filled with buttons that actually could have been the description for the colum in the table. My guess is that each of these buttons can rearrange the data in the table. Very nice but as long as none of the screen readers have any chance of figuring out the colum title the table is too complex with 7 colums to be o of any us as it is currently coded. Until you can navigate the table and have the colum title read out this is almost unusable.
Another issue especially in long threds it would be nice to be sure if you are answering to another post in a thread or creating your “own” answer. Currently the button read “reply” with some extra generic text no matter what or who you are replying too. It would be nice if the name of the person who answer or the number of the topic could be added to the reply button. and that the reply to topic but not to another post in the topic would be refrained differently.
So I am back with new frustrations. This seem to happen for me both with jaws, and NVDA, on Edge 106 and Chrome 106.
When you look at the table with the list of topics, there are 2 ways to get to the last reply. Either you could press the "this topic has x replies with… and you would get the choice of either go to the first or last post in the topic. Or you could press the “XX time” indication of when the last post last comment was added to the post. In both cases you could expect focus to move tto the post. However this does not happen anymore. Nothing happens when you press any of the links/buttons as described. and the screen reader focus is left at the top of the page.
I have not checked how firefox behaves to rule out that something in Chromium has caused this new behavior.
I jus changed my default browser to firefox nightly and here focus is moved to the relevant post as it used to be in the chromium based browsers, so this is a browser problem it seems, however really annoying if you are using Chrome or Edge with a screen reader.
I have been trying to reproduce this, but have been unable to do so. In my testing, it seems to be working correctly for me both on Windows and macOS in all the major browsers with Narrator, VoiceOver, NVDA, and JAWS.
It may have simply been a browser issue. Now that some time has passed and new updates have arrived, could you give it another try to see if you’re still experiencing this problem, perhaps on Chrome 109?