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]

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: #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 #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?

[skolmer]

This PR will fix the atlaskit toggle components used in the web interface #8423

[rkingett]

Even when the state is reported, I can't quite tell, using a screen reader, if I'm muted or unmuted, or if my Camera is off. For the various buttons, could we have states like, hand raised, hand lowered, like Zoom has it. Their accessibility practices are a very good basis to get an idea of what to do for these types of controls.

[ssawczyn]

Judging by the comments, I believe this should have been addressed although I can't confirm. @t3chguy do you know if the dynamic aria-label stuff ever made it into a release? For example, the aria-label on mute should say "mute" when the state is unmuted but then should toggle to "unmute" when the state is muted. I know this sounds backward, but general expectation is for the control to say what it will do if activated. Let me know if this is unclear, I know it may seem a bit confusing.

[pvagner]

I am using jitsi-meet-nightly and I think the aria-label has never been a thing. Instead aria-pressed is used to communicate the button toggle state.
The label says something like microphone mute toggle, video mute toggle and similar. The result is not very optimal as scren readers on the web usually say something like microphone mute toggle not pressed button when it's unmuted and microphone mute toggle pressed button when it's muted. I'd tweak those aria labels to simply say microphone mute, video mute and so on. Then pressed would mean it's muted and not pressed would signal it's not muted and it seems logical.

However android app has a different experience. On android it is reported as being selected. It's communicated as selected property on the corresponding AccessibilityNodeInfo or AccessibilityEvent class. The issue is that not all screen readers on android do report this property. Thus for android it would be better to tweak aria label to unmute the microphone when it's muted and tweak aria-label to mute the microphone when it's unmuted.

Greetings

Peter