Read receipts are noisy for screen readers

[ndarilek]

I assume these are the read receipts, anyway. My screen reader presents a bunch of alt attributes containing Matrix IDs throughout the message flow. This makes reading individual messages, or continuously reading the logs, a noisy proposition.

I'd suggest adding an aria-hidden="true" on the element containing the read receipt position in the chatroom, then exposing this information via some other means. I'm probably more interested in looking up how far an individual user has read in a chatroom, but I don't know if there are room-specific detail pages for members. But in any case, hiding these from screen readers would be a good first step.

Maybe there can be a panel that displays a table, showing users and their position in the room? I noticed that, when I click on the overflow row of icons on Android, I seem to get a list like this. A table sorted from least to most active would be helpful.

Thanks!

[ara4n]

I've hidden RRs by default in matrix-org/matrix-react-sdk@d0d056e. Will leave this open to work out a better way to show them...

[pvagner]

@ndarilek I think this is now addressed partially after @JaniM has turned most of the divs into accessible buttons in JaniM/riot-web@5edb5f6 - now also merged into develop and deployed on riot.im/develop.
At least for me with Firefox on Linux with Orca I don't have these receipts spoken when reading by line, by word or by letter. However I can tab / shift+tab over the buttons corresponding with individual receipts and activate to show member details screen.
When focusing and activating these buttons with the enter or a space bar press perhaps something happens however I fail to identify that action and I can't work out if this is an issue or not.
Also if there are more than 5 receipts associated with a message + sign is not focusable / activatable so full list can be expanded with the keyboard alone.
As I have said the verbosity issue is addressed for me. Need to verify with other browser vs AT combos whenever possible.

[lukebarnard1]

@pvagner, sounds like the only remaining problem here is the "+n" that allows expansion of the read receipts?

[lukebarnard1]

Having tested it, I observe that clicking, pressing space and pressing enter all do the same thing now, which is to expand and contract the list.

[pvagner]

@lukebarnard1 Thanks for your time looking into this.
Unfortunatelly now I think my previous comments on this were mostly all wrong and we do have more serious issues here.

• All the message read receipts are placed inside a div.
• Clicking any of them expands or collapses the displaying of all of them. So I was wrong saying they are opening user profile or similar.
• They are turned to so called accessible buttons thus they are keyboard focusable.
• All of them are hidden from screen reader users by using aria-hidden.

At first we are making them all focusable and then we are hiding them from screen reader users. This is not recommended at all and I assume it might evenn create more issues than it solves.

I would propose keyboard uX like this

• Revert the code that is turning individual RR in the collabsed state to accessible buttons.
• Since clicking all of them causes the same thing to happen no matter which one is clicked it would be nice to only expose single keyboard focusable control by turning the outer div encapsulating all of the rr's in collabsed state including the +number figure to accessible button.
• The individual RR's while the view is collabsed should have aria-hidden set to true or to make it more obvious what we are trying to do we might exchange aria-hidden=true for role=presentation
• this accessible button would react to keypresses and expand the view with all the RR's.
• In order to provide more pleasant experience to screen reader users we should set aria-label on this with the string similar to the following
  If there is only one RR: %{username{s seen at %{time}s
  If there are two RR's sorted from oldest to newest: %{user1}s and %{user2}s seen at %{user2Time}
  if there are 3 RR's: %{user1}s, %{user2}s and %{user3}s seen at %{user3Time}
  if there are more than three: %{user1}s, %{user2}s and %{other}s more seen at %{lastTime}s
  With the aria-label in place browsers will not be calculating accessible name for the accessible button from its child DOM nodes and by using aria-hidden=true or role=presentation we will instruct screen readers not to present individual non focusable RR's to screen reader users.
• Expanding the view would make the individual RR's into accessible buttons similar how it's working now. Activating the buttons in the expanded view would show user menu or profile whatever similar to clicking the user avatar on the message timeline.
• When the view with RR's is expanded interacting with something outside or pressing the esc key or tab or shift+tab key would collapse it again similar how the traditional popup menus are working.
• Pressing arrow keys when the view with RR's is expanded would navigate over the individual RR's similar to a popup menu.

I know this is a lot of work but I'd imagine we will need very similar behaviour for many other components such as user popup menu, message tile popup menu, room menu and similar if we wish to really move forward with the accessibility support.