Starting work to improve accessibility in Jitsi Meet

Hey Jitsi Meet team,

I work with France Université Numérique, a French public interest group making digital services for education. We and others use Jitsi Meet and we would like to contribute to improve its accessibility, on behalf of the French Inter-departmental Directorate of Digital Affairs (french content).

I know a lot of work was already done to make Jitsi Meet WCAG-compliant and it shows, the app is already greatly usable with screen readers and other assistive technologies 😃

As of today, we audited the Jitsi Meet web client following WCAG rules (through the RGAA) and by testing with keyboard-only navigation and screen readers. We also collected feedback from regular users of Jitsi that use screen readers heavily.

What is this "RGAA"?

The RGAA (<span lang="fr">Référentiel général d’amélioration de l’accessibilité</span>) is the French government’s set of web accessibility rules that you are legally required to follow when building or using a website or webapp as a public French organization. It is exclusively based on WCAG rules. The difference with WCAG is that the RGAA is an operational set of rules, that directly translates WCAG rules to HTML/CSS/JS specific guidelines.

We noticed a few things that should be improved:

• Some toggle buttons need to have more-specific labels for screen reader users. For example, the mute button is labelled “Mute or unmute your microphone”, which is quickly confusing when using a screen reader. Even if the button has a aria-pressed attribute, it doesn’t help that much because the user doesn’t know if pressing the button mutes, or unmutes, the microphone. Describing it as “Mute your microphone” in one case or “Unmute your microphone” in the other would greatly help screen reader users. This is one of the easiest change to make we saw, while also one of the most raised and blocking issue for people we talked to. Note that this was already discussed a bit in #3590.
  Related PR: https://github.com/jitsi/jitsi-meet/pull/12426
• When not using a screen reader, some buttons are not accessible via keyboard while that should be the case. You can notice this when trying to access via keyboard the buttons behind the “More actions” menu.
  Related PR: https://github.com/jitsi/jitsi-meet/pull/12657
• Some buttons have missing labels, making screen reader users pretty confused about what they are trying to interact with. This is noticeable for example on the “Performance settings” button
• The whole UI could benefit from using heading tags and/or region ARIA roles. They are often used by screen reader users to quickly jump between parts of the page. This would help navigate between the chat panel, the actions bar, the meeting participants panel, etc.
  Related PR: https://github.com/jitsi/jitsi-meet/pull/12427
• Some form inputs don’t have actual labels technically tied to them, making it hard for screen reader users to use forms. This is visible in the Profil and Sound tabs of the Settings dialog.
• Information is sometimes hidden to screen reader users, like it doesn’t exist. For example, in the meeting participants panel, the mute/camera indicators have no text alternative.
• Navigation with keyboard is sometimes confusing because the keyboard focus doesn’t follow the navigation. For example, activating the “Invite someone” button makes a dialog pop up, but the keyboard focus stays on the “Invite someone” button. The focus should directly change to be in the dialog.
  Related PR (more to come): https://github.com/jitsi/jitsi-meet/pull/12657

This list is not exhaustive but a good representation of accessibility-related work that could be done in Jitsi Meet.

We really want to contribute to fix all the issues we noticed and others, so that all users can fully use Jitsi Meet.

Note that most issues we noticed would not require changes in the actual visible UI, or at least, not big changes.

We would like to start work on all these issues right now and proceed by submitting one pull request for each issue we listed above if that’s ok with you.

Please let us know what you think 😃

Also, any additional feedback on accessibity in Jitsi Meet is more than welcomed.

Thanks

[saghul]

Hi there @Leimi

Hey Jitsi Meet team,

I work with France Université Numérique, a French public interest group making digital services for education. We and others use Jitsi Meet and we would like to contribute to improve its accessibility, on behalf of the French Inter-departmental Directorate of Digital Affairs (french content).

This is great news, thanks for getting in touch!

We’ll be happy to collaborate to get these resolved. Some responses below:

• Some toggle buttons need to have more-specific labels for screen reader users. For example, the mute button is labelled “Mute or unmute your microphone”, which is quickly confusing when using a screen reader. Even if the button has a aria-pressed attribute, it doesn’t help that much because the user doesn’t know if pressing the button mutes, or unmutes, the microphone. Describing it as “Mute your microphone” in one case or “Unmute your microphone” in the other would greatly help screen reader users. This is one of the easiest change to make we saw, while also one of the most raised and blocking issue for people we talked to. Note that this was already discussed a bit in

Yep, this should be fixable y having different labels considering the current state of the button.

• When not using a screen reader, some buttons are not accessible via keyboard while that should be the case. You can notice this when trying to access via keyboard the buttons behind the “More actions” menu.

You mean one can’t navigate the entries in the more menu, after opening it?

• Some buttons have missing labels, making screen reader users pretty confused about what they are trying to interact with. This is noticeable for example on the “Performance settings” button

👍

• The whole UI could benefit from using heading tags and/or region ARIA roles. They are often used by screen reader users to quickly jump between parts of the page. This would help navigate between the chat panel, the actions bar, the meeting participants panel, etc.

Today I learned 😃 That sounds useful indeed!

• Some form inputs don’t have actual labels technically tied to them, making it hard for screen reader users to use forms. This is visible in the Profil and Sound tabs of the Settings dialog.

I think we might be using fewer forms now, is there a way to link a label and an input together differently?

• Information is sometimes hidden to screen reader users, like it doesn’t exist. For example, in the meeting participants panel, the mute/camera indicators have no text alternative.

You mean the alt property? Yeah that makes sense.

• Navigation with keyboard is sometimes confusing because the keyboard focus doesn’t follow the navigation. For example, activating the “Invite someone” button makes a dialog pop up, but the keyboard focus stays on the “Invite someone” button. The focus should directly change to be in the dialog.

👍

This list is not exhaustive but a good representation of accessibility-related work that could be done in Jitsi Meet.

Thanks for putting the list together! It does show there is work to do. I didn’t find any of the items in it particularly troublesome, they all sound like bugs we’d like to see fixed.

We really want to contribute to fix all the issues we noticed and others, so that all users can fully use Jitsi Meet.

❤️

Note that most issues we noticed would not require changes in the actual visible UI, or at least, not big changes.

We would like to start work on all these issues right now and proceed by submitting one pull request for each issue we listed above if that’s ok with you.

Absolutely, please do! Making this change incrementally is the best way to go, so one PR per item sounds great. We can make faster progress on small PRs than on a gigantic one.

Thanks a lot for volunteering to work on this! 🚀

[saghul]

Via keyboard, yes.

When using a screen reader, the current situation is a bit annoying but not a real deal-breaker, since a screen reader makes any content on the page focusable, you manage to go through the menu. But when using a browser without any screen reader or other assistive technology, using only the “tab” key to focus interactive stuff, you can’t access these entries.

I see. Yeah, that sounds like a bug that needs fixing.

Just to be clear, I said “forms” but it’s something necessary to check on any form input (text, checkbox, radio, etc.), whether it’s part of an actual form or not.

There are multiple ways to add a label to an input. You can have an input tag as a child of its label in the DOM, you can have <label id="input-tag-id">, you can set aria-label or aria-labelledby attributes on input tags… I’ll start working on this pretty soon actually 😃

Got it. Thanks for working on this!

Well yes, but it’s kind of like with form labels, there are multiple correct ways to add a “text alternative”. Depending on the code context, sometimes one way is a better fit than the other. I didn’t mention anything too specific on purpose but yeah most of the time, setting the alt is the straightforward way.

👍

I’ll start opening PRs soon 👌

Wonderful! Please @ me so I don’t miss it and we can expedite reviews.