I will try this later, however this is not the solution since you are not performing the steps a real screen reader would do. Since I move to a specific post it can be assumed I want to read that post. Tab is not a reading command but a way to move focus to the next element that can gain focus. A reading command would be using t the arrow down keys or the SayAll command specific for the screen reader. At least arrow down that is my prefered reading command fails focus is not where it is visually at all but usually before the list of posts.
Of course tab could be the dirty way to solve this bug but not as such the solution of the bug itself.
Thanks @thoeg@nolan, much appreciated. I think I see what the issue is. We’re currently using an empty span element to set the focus to the post. This element has both aria-hidden=true and tabindex=-1, and I think that makes the element invisible to screen readers.
I think it may be best to switch focus to the first focusable element in the post. In most cases that will be the username link, i.e. the post author.
This makes sense. Ariahidden should hide the element and -1 prevent it from getting focus. If this element would take focus to the subject heading it would be fine. It could be interesting to see what happened if you just set the tabindex=0 instead,
Yes, I hear you @anni_anni, we will fix this. I tried a first attempt last week, but had to revert it because it had some undesired side effects. Will try with a different approach very shortly.
Ok, at last, another attempt at a fix for this has been merged. The current implementation is to set focus to the first focusable element in a post, which, in most cases, will be the post author’s username. When navigating to a post and hitting Tab, it should look like this in Chrome:
I still see the old broken behavior on Meta and community.fly.io with Chrome, but can confirm the fix works on our discourse.team site. Are these running different versions of Discourse? I’m using the same version of Chrome with the same profile.
Hmm, all three sites may be in slightly different versions of Discourse, but I believe all of them have the change linked above. Meta, specifically, is always up to date with the latest changes in our tests-passed branch, so I’m a bit concerned that this isn’t working here…
OK, I have a bit more info for you on this, observed on our discourse.team site where I reported this working.
If I click into a brand new post I’ve never read, I don’t get any spoken feedback, and focus seems to land randomly on what I’d assume to be the first page of posts.
If I click into a previously-visited topic, focus lands correctly and I do get spoken feedback.
This behavior seems consistent between Firefox and Chrome now. I think before Firefox correctly placed focus on the first post when viewing a new thread. It’d be nice to have that behavior back if possible so the first-read and return experiences behave the same. I’m glad that it at least seems to restore my last read position in Chrome now at least since that’s required for work.
Wild that these behaviors were so different between Firefox and Chrome.
That’s great to hear! I did indeed limit the changes here to navigation to posts that aren’t the first post of a topic. For returning users that will often be navigation to topics you’ve already read but that now have new replies.
This is good to know, I think we have a path to iterating and fixing this. If you can share the exact order of commands that you use, it would also help.
On my regular Chrome browser, if I head to a new topic that I haven’t read and hit Tab, the focus lands on the topic title, which seems reasonable to me but it’s probably not enough for your use case.
Thanks again for your continued feedback, much appreciated!
This is strange with jaws and Chrome and testing on a new topic on meta, I saw a new behavior from jaws. Aftter pressing enter on the topic title I get the usual information about the page that has just loaded standard jaws behavior. the same will happen when I go back into the topic list and press enter on the same topic I focus is just put on the last read post. This seems to have solved at least 2 issues here. I have not tetsted the go to last post in the topic list but my guess is that this will work.
However of course not everything is good, but this may not be related at all. When I use the back button to go back to the topic list Focus is lost I am not placed back at the topic I opened and was reading. This can be a jaws/chrome bug we have seen similar before but it could also be on your side. I will have to check with nvda.
I just tried with nvda and chrome and here nothing works that is I can no longer just press enter on any of the topic titles in the table. I am sure this used to work. Of course since I am a jaws user this will nnot bother me but for nvda users this is another story.
Since nvdadid not really work I cannot test the problem with focus when going back from a topic to the topic list.
JAWS is however reliable here focus is placed at the top of the page.
In newest Chrome on our discourse.team site, clicking a previously-visited topic brings me back to where I stopped reading, and NVDA correctly announces the heading of the post with focus.
Unfortunately, clicking into a new topic doesn’t drop focus on the first post in the topic. Likewise, using “h” to attempt to put focus on the first post fails. I have to manually find it to start reading.
Note that position does seem to be correctly set in new posts on Firefox. Seems it’s just Chrome for some reason.
All things being equal, I’m glad position is restored on previous threads since that’s the biggest pain point for me. I do hope we get correct consistent behavior across both use cases, though.
This is correct as well. The current implementation specifically skips setting focus if the target post is the first post. I tried adding the same thing to the first post, but it would often result in unnecessary scrolling when loading a topic URL and that was too disruptive for all users.
This should work. I’ll do some testing and see if we can fix this.
Wanted to flag another papercut that’s been bugging me for a while.
When posting a new topic, the dropdown to add tags/categories is a bit weird. First, the label for me is “Filter by”. I don’t know if that’s visually displayed or not, but it took literal years of me posting on Discourse before I realized that’s how tags were added. The use of “Filter” to me implies something like “filtering something out of water,” not adding a new thing. If that’s displayed visually then do what you will with that feedback, but if that’s ARIA-only then it might benefit from some adjustment.
Next, clicking into the tags list gives me what seem like radio buttons. If I press Space on these (I.e. as per the ARIA radio group pattern), this seems to trigger a search. Yes, I can hit Enter here instead, but I’m used to hitting Space for triggering button interactions because my thumbs are right there.
It’s certainly not a blocker, but it’s definitely more difficult to discover, and I have to put extra thought into remembering/re-figuring out how it works each time I make a post. Historically I’ve clicked into individual categories, but that’s limited my ability to use multiple tags.
I think a better fit for this interaction might be the ARIA combobox pattern. Specifically, the editable combobox behaves in a much less confusing way. If I type in “A”, I can arrow down to “Alabama”. It isn’t presented as a radio button, so my automatic response isn’t to press Space there, but if I do then it inserts the space as expected. Could be all that’s needed is removing the radio button presentation, but it could probably be a bit less chatty about result counts too.
If I type an emoji in the post edit box (E.g. :)) and focus lands in that emoji while editing, I can’t up/down arrow to the previous or next line. I have to arrow left/right out of the emoji first.
Guessing this is due to autocomplete behavior? I wonder if this behavior could be disabled either in cases where there’s only a single match, or unless Enter or another key is pressed? I’d understand autocomplete behavior for initial entry and edits, but it’s definitely been tricky trying to debug why I can’t move focus in some instances and this seems to be why. Some sort of manually-triggered dropdown for edits feels like the right choice here.
