Jitsi-meet: Toggle buttons on the UI not accessible with VoiceOver on Mac OS and Google Chrome

[parhamdoustdar]

I'm using VoiceOver as a screen reader on Mac OS. When I open a new channel, the toggle buttons like microphone and video don't report their status to my screen reader, so I never know if my microphone is muted, for example.

Please look at the documentation on how you can easily make this accessible for screen reader users.

Thanks a lot in advance!

[saghul]

Thanks for the report Parham!

[kayleachampion]

Adding my +1 here; I'm getting reports that meet.jit.si isn't working via the JAWS screen reader either; perhaps the same issue?

[saghul]

@karthikmuralidharan Anything specific we should be doing so JAWS works? I wouldn't know where to start to be honest.

[kayleachampion]

Definitely not an expert, but it looks like you can test with a range of screen readers (several free ones): https://stackoverflow.com/questions/43340690/is-there-an-online-emulating-screen-reader-tool-to-test-against-a-custom-web-pag

JAWS is definitely dominant out there but my bet is that if the page works with one of the readers, they all will work.

A google-skim of links about the ARIA standards suggests that compatibility is mostly about CSS -- page structure and tags -- as well as making sure there's keyboard navigability on the page. https://codeburst.io/seven-ways-to-make-your-web-app-more-accessible-411a8c716fcb

[parhamdoustdar]

I wouldn't know where to start to be honest.

That's normal. For this specific case, all you need to do is the following:

• Tell the screen readers that the mute buttons are a "switch". You can do that by adding role="switch" to the markup of the button. Since when the page loads everything is unmuted, you should also have aria-checked=false to signify that the switch is off.
• Every time that a click event is fired on the buttons, set the aria-checked attribute to either true or false depending on if the switch is on or off.

If you are on the Mac, you can test by running VoiceOver (press Command+F5, or hold down Command and press the touch ID button 3 times). When you run VoiceOver, hold down the option and Control keys and move around by pressing left and right.

On Windows, you can download the NVDA screen reader for free and test through that -- if that works, Jaws would also work.

[saghul]

Thanks for this folks!

[MarcoZehe]

This affects literally all controls, not just the toggle buttons. Normal buttons are also not accessible, and those that open menus, neither.

1. For normal buttons:
   
   
   
   • Add role="button" to the element.
   
   
   • Add a keyboard handler that fires the click handler on Space or Enter.
   
   
2. In adition for menu buttons:
   
   
   
   • Add aria-haspopup="menu".
   
   
   • add aria-expanded and a value of false if the menu is collapsed, true if it is expanded.
   
   
3. For all, including the switches, add tabindex="0" to make them tabable with the keyboard.

For additional information, and a list of all patterns you can theoretically use with custom HTML controls, if you cannot use native HTML ones such as <button>, see this W3C document and the attached examples.

[saghul]

Thank you!

[shoogle]

Would be great to see this fixed! Users need to be able to navigate the interface using just the keyboard:

• Press tab to move focus to different buttons
• Press spacebar to push the button, etc.

Buttons need text labels so that screen readers can identify what they are for. The text label can be hidden so that it is not visible to sighted users.

[shoogle]

The app is almost there already. A blind user can easily create or join a call by typing a custom URL like https://meet.jit.si/<MyCustomCallName>, so they just need a way to mute/unmute, toggle video on/off, and bring up the list of dial-in numbers. These tasks could even be accomplished via hotkeys if it proves too difficult to make the interface properly accessible.

[t3chguy]

Being the resident accessibility guy for riot-web, an app which embeds jitsi-meet, I will try and pick up some low hanging fruit here to make it somewhat accessible.

[shoogle]

You might find the Accessibility Insights browser extension for Chome helpful. It shows what information is being exposed to screen readers (not much at the moment).