Jitsi-meet: Accessibility issue: unknown state of toggle buttons in web page and android app

[grishakonzalaev]

I use screenreader NVDA and last firefox browser.
I can read All elements in the pages of jitsimeet exclude state of toggle buttons. For example^
NVDA speeks me^ toggle mute video, but it not speeks state muted or not.
My suggestion^ add to accessibility label future state after pressing.
For example^ toggle mute video, toggle unmute video.
it needs to make also in android app.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pvagner]

Unfortunatelly there are more issues with the web app.
The controls need more semantics, keyboard navigation and consise labelling.
On Android most controls are native to the platform thus their role and focusability are correct however most of them are missing so called content descriptions.

[varac]

Come on, please jitsi devs, take more care of such accessibility issues, resulting in a more inclusive application !

[MarcoZehe]

I added some more info to this related issue.

[t3chguy]

For the webapp this is now mostly resolved: https://github.com/jitsi/jitsi-meet/pull/5432

[ssawczyn]

This issue still exists, tested with Chrome/Firefox on both Mac and PC using NVDA and VoiceOver screen readers. Issue is that since UI controls are custom DIVs and not HTML elements, and the aria-label doesn't dynamically change, a screen reader user cannot tell the current state of mute/video and other toggles. A few suggestions:

• Add tabindex="0" to each of the UI control DIVS so that they can gain keyboard focus.
• Add a visual focus indicator using CSS to each interactive UI element.
• Dynamically modify aria-label to indicate what will happen if the user activates the control "mute video" "unmute video" "mute audio" "unmute audio" ...
• Add aria-pressed="true" and dynamically toggle to "false" as this will indicate to screen readers whether a toggle is pressed or not pressed. Note while I would recommend dynamically changing the aria-label as described above, adding aria-pressed would also convey state as the screen reader will say something like "mute video button pressed".
-

For more info on button implementation and associated ARIA, see: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles/button_role

[t3chguy]

@ssawczyn It doesn't look to have been deployed, but is fixed in local development builds of the master branch. The above PR does all of those things (except the visual focus indicator)

[MarcoZehe]

It looks like the changes @t3chguy made in #5432 haven't made it to the production under meet.jit.si yet. And maybe other servers either. I tested yesterday, and it wasn't there yet. :-(

[damencho]

@MarcoZehe can you test on beta.meet.jit.si, please? And report if more changes are needed, thanks.

[MarcoZehe]

@damencho This looks much better already. There are still a few places in the More Options menu etc. where items such as the Shortcuts or some other entries are only clickable divs instead of buttons or menu items etc., but I was told by @t3chguy that he might have a follow-up pull request for those.

One other question: Does stuff from this web client also go into the iOS app, or is that a completely separate codebase where issues should be filed and fixes provided separately?

[t3chguy]

@MarcoZehe https://github.com/jitsi/jitsi-meet/issues/5681 is for the More Options menu

[damencho]

That is the same codebase for web, android and ios.

[damencho]

@MarcoZehe @t3chguy Thanks for doing this.

[t3chguy]

Indeed the codebase is the same but the accessibility hooks are different for react-native than for react-web and my PR focused only on Web as it is the only place I have accessibility experience at this time.

[MarcoZehe]

The docs for React Native accessibility properties are here.

[t3chguy]

Thanks! Good to know, if I find myself with an abundance of spare time to learn react native development flows and learn ATs on mobile (android, no access to ios dev) then I will update here but it does not seem likely at this time, unfortunately.

[Echolon]

@saghul maybe we reference to this issue instead of the meta issue without actual content? Otherwise, shall I delete this with reference?