Discourse with a screen reader

This is strange since this behavior is very consistant on my windows machines.
Now tested on Chrome Canary Google Chrome Version 111.0.5536.0
try the following.
Go to:
https://meta.discourse.org/
Find the topic in the list of topics:
Does Discourse offer anything similar to WordPress custom taxonomy?

MMove to the last colum in that row with the text:
Currently this reads 3t in my Danish setup.
Pressing enter should move the focus to the last reply in that topic. but that is not what is happening.
When I press enter nothing happens usual since the page is not updated so the screen reader does nothing.
However if I read the line I am still on the first line on the page not the expected heading for the last topic posted in the thread.

NVDA seem to move focus a bit but not even into the topic itself. Both bscreen readers have worked as expected until about the time when I postedabout this problem.
Changing to firefox Firefox Nightly Version 110.0a1
This works as expected in the example above pressing the 3t that moves to the latest post in that topic the focus is placed as expected.

4 Likes

This appears to have regressed.

Specifically, for a while it worked on lots of self-hosted instances I’ve used but is failing on sites you’re hosting for my employer–specifically https://community.fly.io, and a certain discourse.team internally-hosted forum whose URL you can probably pretty easily determine from the above. :slight_smile: Both appear to be using the same version of Discourse.

It’s definitely a hardship because we do lots of work on Discourse, and as a blind employee I’m always losing my place in both internal discussions and in support conversations with our community members. Returning to previously-read posts takes 20-30 seconds of work for me to find my former place.

Feels like my old 14400 baud modem days. :slight_smile:

Thanks for any help.

2 Likes

Sorry for the noise. I just did a bit of digging, and this works on Firefox but not on Chrome. Fly mandates use of Chrome for work so that’s why it bit me there and not everywhere else, where I use Firefox.

Glad it isn’t quite as big of a regression as I thought it might be, but it’d be nice to get this working on Chrome too. Using NVDA, and Chrome with no extensions installed.

4 Likes

Hi Nolan! :wave:

Sorry to hear it isn’t working in Chrome. As this topic is quite long, could you elaborate on the particulars of the regression? It sounds like it isn’t returning to your place when you load a topic, but I want to make sure we are addressing the issue.

Let us know. :slight_smile:

3 Likes

Yeah, that’s exactly it. Clicking topics in Firefox returns focus to the last-read position nicely and reliably. In Chrome it doesn’t.

Thanks.

2 Likes

Hi,

Nice others are finding the same since this could not be replicated when I posted about it. I gave up on firefox for other reasons and have learned to live with this behavior but it would be really nice to have it changed to the expected behavior.

Claus

1 Like

Thanks for confirming, @nolan and @thoeg. :+1:

Our team is checking into this; in the past we had difficulty reproducing the issue, and now we can narrow our efforts to Chrome.

We’ll update you, here. :slight_smile:

2 Likes

Whoah. Totally blown away by the responsiveness of the community of core devs here on Discourse!

It may seem small to some, but – wow – truly, I am calling out your humanity here for all to revel in!!!

This is sooo what I love about open-source and the collaborative spirit!!!

4 Likes

I was checking it seemed that the problem with focus moved to a specific topic in a thread sometimes now seems to work, but not always. Then I was rreminded about something that seems to be a regression along the way.
After each post in a topic you have a number of butttons,
like, however that button reads “you like this post” instead of just giving you the option to like it.
Then there is the “reply to post number XX” this text is not translated that is the reply part of the string reads reply in the Danish translation tso a bit of 2 related issues here.
Claus

Apologies for the delay here, Nolan. I just tested this with NVDA (via an online service called Assistiv Labs), and it seems to work for me on both Firefox and Chrome. When using the keyboard shortcut for navigating back, I see the focus is on the article that I had previously opened.

The testing environment is Chrome 115, NVDA 2023.1

Is there a particular step sequence that consistently leads to the issue?

Try the following where I see the issue in Chrome and Edge each time:

open:
https://meta.discourse.org/tag/accessibility

Move into the table the first topic is this one.
Move focus over in the last colum that says:
3D
This should when activated move focus to the last topic in that thread.
The problem is that in Chrome and Edg it does not however in Firefox it does.

1 Like

@thoeg I think that button texts can be customized using

Hi,

But not as a user and since the text is misleading and appear on several sites this is another accessibility issue.

But, to solve the problem you are experiencing, the administrator of the Discourse forum where you are a user could change those button texts on your forum. You could contact them.

So it’s not really an issue with the Discourse software.

But I do agree with your idea that the button texts (being all the same) are a bit confusing – you could consider starting this issue as a new topic, especially if you can suggest a specific improvement or solution?

Hi!

What screen reader de you use? I’m not familiar with this feature as I’ve never used it, but I’d like to learn a bit more and have a look at this issue :slight_smile:

Thank you, Claus, I can reproduce this! Here’s a video showing the behaviour (at 0:09, the last post should get a dashed blue border, but it isn’t working.)

I also noticed a second issue, in all browsers, including Firefox. If I go through the same steps but end up on a topic that has a small post (a closed topic, an auto bump, an assignment, etc.) as the last post, the focus isn’t properly set to the last post either.

We will look into this shortly.

3 Likes

I just merged a fix for the two items discussed above @nolan @thoeg. For reference, this is the PR: A11Y: Fix selecting topic when navigation via keyboard by pmusaraj · Pull Request #22996 · discourse/discourse · GitHub (this should land on meta in about an hour and other sites later this week).

1 Like

If this fix as you said has gone live a while back it has not fixed my problem. Tested today in Chrome and Edge as described both with jaws and nvda. Exactly where focus lands differs between the screen readers, but it does not land where it should on the latest post in the topic.
Claus

1 Like

In my testing, with NVDA on Chrome, Windows, the focus lands on the last reply in the topic. It doesn’t display the focused element, we’re using a hidden element to switch focus, but if I press Tab after navigating to a topic, it will consistently focus the author of the post.

Sorry it took me a while to respond–I’ve been traveling and am finally getting caught up on things.

Sorry if this is obvious and is what you’ve been doing, but I’d suggest listening to what NVDA says when clicking a topic rather than just relying on vision.

If I go to https://meta.discourse.org and click the welcome post in Firefox, the first thing NVDA speaks is the heading level 1 with the username, post date, etc.

If I do something similar in Chrome, nothing is spoken. Maybe focus visually lands where it should but for some reason that doesn’t speak.

It could be a difference in how Chrome and Firefox’s accessibility implementations work. If I use Back in both browsers, focus correctly lands on the active post and that is spoken. If I load a post in Chrome though, hit h a few times to bounce to a later topic, hit Back, then click the post again, pressing h seems to take me to the first visible post rather than to my last read position. This is still true across multiple Discourse-hosted forums.

This feels like a timing issue. Is the element that the accessibility-related code is attempting to focus present in the DOM? Maybe adding a short setTimeout before the focus with something like 50 MS might solve it? That’s generally how I approach these sorts of issues but I may be off.

Thanks for all your work on this.

2 Likes