Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's very unnatural to send read receipts for keyboard only screen reader users #5679

Closed
pvagner opened this issue Nov 24, 2017 · 3 comments
Closed
Labels
A11y A-Read-Receipts O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Info This issue is blocked awaiting information from the reporter

Comments

@pvagner
Copy link
Contributor

pvagner commented Nov 24, 2017

Description

One day I have noticed when I'm chatting from Riot-Web then move to Riod-Android I see the messages I have already read on Riot-Web after tapping Jump to first unread message on Android.
I assume that since I'm using Riot-Web with a screen reader I am not sending out read receipts when I should be doing so.
I've originally asked about this in a #riot-web:matrix.org discussion on 22nd november 2017.
The problem might be that many screen readers (all I know of) do implement so called virtual buffer or a virtual document navigation model (also known as browse mode in some cases) to help visually disabled users to navigate all the web content including static text which is not designed to be focusable or interactive in any way. This paradigm has a lot of shortcomings and there are initiatives that are trying to get rid of this navigation model. If you are interested, see this article on the Mozilla wiki.
When such a navigation mode is active screen reader consumes all the keypresses thus leave less events to handle at Riot side of things to work out when to send the read receipts.
Some screen readers are consuming arrow keys, page up / page down keys, home and end keys, space, enter, tab, letters, numbers and punctuation symbols including their variants with modifiers held down, while other screen readers are only consuming what they need. It includes arrow keys, page up / down, home and end for emulating document like navigation experience.
I don't have clear proposal on how to overcome this, so I will just describe how I am using Riot.

Steps to reproduce

  • Make sure you are in a Riot chatroom in an accessible browser (such as Firefox on Linux) and a screen reader running (e.g. orca on linux)
  • Switch to browse mode, navigate to the main landmark and read the content by pressing up and down arrow keys
  • When new content arrives repeat this to read new content
  • You may like to use quick navigation of your screen reader to navigate to the complementary content where there is a list of rooms to move to a different chatroom to look what's is going on there
  • If you have to write a message make sure you are in a browse mode, then press the screen reader specific so called quick navigation key for jumping to the editable text (frequently this is letter e)
  • After finding the rich text input field switch into so called focus / forms mode if your screen reader has not switched automatically
  • Type in your text and hit enter

If I am using Riot this way I can't notice me posting read receipts unless I write a message.

Log: not sent

Version information

  • Platform: web in Firefox on Linux although I expect this to work the same way on Windows

For the web app:

  • Browser: Firefox 57. Firefox 56 and earlier is not affected as much as it does not correctly scrol all the content into view when navigated via screen reader. It has been changed because handling infinite scrolling with Firefox 56 and earlier was problematic to screen reader users. Here is relevant Mozilla bug.
  • OS: Arch Linux
  • URL: riot.im/develop

Links

I think being able to read a bit on Screen reader testing might be relevant, so I've tried to find some suitable articles.

@lampholder lampholder added I18n T-Defect S-Major Severely degrades major functionality or product features, with no satisfactory workaround P2 labels Nov 24, 2017
@turt2live turt2live added this to the Accessibility Improvements milestone May 16, 2019
@jryans jryans added A11y and removed I18n labels Mar 5, 2021
@Palid Palid added O-Occasional Affects or can be seen by some users regularly or most users rarely X-Needs-Info This issue is blocked awaiting information from the reporter and removed P2 labels Aug 24, 2021
@Palid
Copy link
Contributor

Palid commented Aug 24, 2021

@pvagner I assume this hasn't been entirely solved yet. Is the progress from #302 still relevant?

@pvagner
Copy link
Contributor Author

pvagner commented Aug 24, 2021

I think this is no longer an issue with Firefox 91 and orca on linux. I'll test on windows later.
Scrolling the timeline has been reworked since I have reported it some three years ago.
I can do the following:

  • Open a room with unread messages and press Jump to first unread message at the top of the timeline.
  • Read a few messages with screen reader switched into browse mode.
  • Close and reopen the browser tab with element and press the Jump to the first unread button again.
  • Notice how the new position has been scrolled to.

@Palid
Copy link
Contributor

Palid commented Aug 24, 2021

I'll close the ticket if that's no longer an issue, though we probably want to immortalize your feedback somewhere so it won't get lost.
@novocaine @kittykat have a look at this please, I'll try to figure something out in the meantime too.

@Palid Palid closed this as completed Aug 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A11y A-Read-Receipts O-Occasional Affects or can be seen by some users regularly or most users rarely S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect X-Needs-Info This issue is blocked awaiting information from the reporter
Projects
None yet
Development

No branches or pull requests

6 participants