Use these tips to improve the accessibility of your video calls

community-team Moderator, Dailynista admin
edited April 2023 in Discussion

Making website information and interactions accessible is often the difference between someone being able to use your app or find another one (if it exists!) that accommodates them.

Barriers, such as different physical and mental abilities, geography limitations, language and device restrictions affect a huge number of app users, which means making more accessible apps can improve user experience (UX) for a lot of people. More than that, accessible apps also improve UX for everyone (including you!) 

Why are accessible apps important?

  • Developers who pay attention to accessibility, or “a11y” as it is often called, ensure that their WebRTC apps can be used by as many people as possible.
  • Video apps that consider a11y are typically easier for everyone to understand and use. Design considerations like low contrast colors are impossible to read for some folks, but they’re also harder for anyone to read.

Whether you’re building a live video app for the first time, or managing an existing website that uses WebRTC, these tips should help you improve its accessibility:

Use POUR to determine the current accessibility of your app

POUR is an acronym for:

  • perceivable
  • operable
  • understandable
  • robust

These principles, developed by W3C can be used to identify areas of your site that need a11y improvements.

  • Perceivable: Is your video app available to the senses, such as vision, touch, and hearing?
  • Operable: Can participants interact with any elements that are meant to be interacted with regardless of the device they’re using?
  • Understandable: Is the app easy to understand visually and when using a screen reader?
  • Robust: Is your live video app compatible with various browsers, devices, operating systems, network and conditions?

Now let’s look at some solutions for how to improve your app’s accessibility rating.

Use semantic HTML

Semantic HTML refers to using appropriate HTML elements in your code to help communicate to the browser and screen readers how to understand the page’s content to its listener. It also makes it easier for developers reading the code to know what each section of your markup is, and it makes the page more SEO-friendly.

Here's an example of semantic HTML:

  • If you are building a web form to use with your app, writing the form with semantic HTML would use a <form> tag, with an <input type=”submit”> at the end to submit the form. This is in contrast to using a <div> element as a wrapper around input elements. We know it’s a form, so we should use the form element so the screen reader can know, too.
  • In essence, you always want to use the element that represents what the element actually is (such as a <header>, a <footer>, an unordered list <ol>, etc.) This is in contrast to using non-semantic HTML, which would use a vaguer container element, like a <div>.

Make all interactive UI elements accessible via devices other than a mouse

As a general rule, any element in the video call UI that can be interacted with should be accessible via multiple types of devices. This means we shouldn’t rely on every app user being able to interact with our app the same way. For example, not everyone can use a mouse and may rely on keyboard navigation instead. To support a broader group of app users, app UI should be navigable in several ways, whether it be with a keyboard, mouse, or other device.

What does this look like in practice? Be sure that app users not using a mouse don’t get trapped navigating through your app UI. This means they should be able to tab through elements, submit forms or inputs without needing to click a button, or escape optional views, like modals, with their keyboard. If you have elements on the screen that can’t be escaped, you’ve just trapped your app user there (and you probably lost a customer).

Use focus traps

Focus traps are loops of focusable elements within a parent element on a web page. They’re especially useful in elements like a modal where we can assume the app user doesn’t need to interact with the rest of the page while the modal is displayed.

When an app user opens a modal with a focus trap, if they tab through the contents of the modal and get to the end, tabbing again should bring the user back to the first tab-able element in the modal.

…but avoid keyboard traps

A “keyboard trap” occurs when a user gets trapped on an element if they’re only using a keyboard. (Think back to what we said about making sure the entire UI is navigable without a mouse. This means letting people go back to previous elements, too.)

You can prevent keyboard traps by making sure elements like modals can be closed with a keyboard’s Escape key or by pressing the Cancel button. You should always give users an “out” too in components like a multiple-stage form. A cancel button goes a long way for someone who decides they want to go back to a previous view or element.

Add skip links

The gif above shows how skip links work on Daily. Does your site use skip links or other accessibility features? Let us know in the comments!

Skip links allow participants who don’t use a mouse to move faster to the site navigation or main content and avoid having to move through all the elements in the page’s header. Skip links are styled to be off screen unless they’re tabbed to, which means you won’t even know they’re there if you’re just using a mouse.

You can include more than one skip link; ideally, you want users to have the option of skipping to whichever section they may want to jump to without having to tab through the entire page.

Adding this small addition can make your app users’ experience of your site much more enjoyable. No one wants to hit Tab 20 times before getting to the actual content they care about.

Create hidden labels for screen readers

Creating hidden labels ensures that screen readers can read elements that don’t use words, such as an icon. For example, you can use the <VisuallyHidden> React component in an icon’s contents, which is really just a <span> with text that is styled to not be visible.

It’s important to note when you are visually hiding an element meant for a screen reader, you should not use visible:hidden; or display:none;. Both of these CSS properties will hide the element visually and hide it from a screen reader, which is not what we want. Instead, you can style the element to not be visible but using style properties like:

span {
    clip: rect(1px, 1px, 1px, 1px);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;

…but remove hidden elements from the tab order

If an element is in the DOM but the user is not meant to be aware of it, remove the tab from the order.

For example, tooltips that are not shown unless hovered over don’t need to be read by the screen reader while the user tabs through the elements because the buttons they’re related to are already being described by the screen reader.

You can remove elements from the tab order by using tabIndex={-1} on the HTML element. Be careful with this property, though! Browsers do a great job of organizing tab order without us manually updating it. So, be sure it needs to be hidden before updating it.

..and finally, ask people who understand a11y test your site

Once you have updated the a11y of your video app, have it tested by people with different abilities, and pay them for it! People who are familiar with a11y deficiencies in websites are well worth the expense. They'll be able to confirm the impact of the changes you have made and help identify additional work that should be done.

Do you have additional tips for improving the accessibility of a website or WebRTC application?

Let us know in the comments!