Live chat resources can be extraordinarily helpful for internet users. They’re also excellent tools for creating and retaining customers — but poorly implemented live chat features can have the opposite effect. A chat dialog can interrupt a user, and some people with disabilities may be unable to interact with the chat service easily.
Here’s the good news: With proper planning, a live chat feature will not make a website less accessible. In fact, live chat can help accessibility by giving visitors a simple way to report problems, get answers, and ask for assistance. However, live chat needs to conform with the Web Content Accessibility Guidelines (WCAG) to be useful to all visitors.
To recognize the importance of live chat accessibility, it’s helpful to understand how chat dialogs can impact the on-page experience of people with disabilities. Here are some common scenarios where a chat feature could cause issues:
In this scenario, the live chat feature requires a keyboard or other pointer input (such as tapping on a touchscreen) to function. As a result, the user can’t interact with the chat agent. They may not be able to exit the chat dialog or access certain features.
Many people with disabilities use a keyboard — without a mouse — to navigate the internet. Unfortunately, designers and developers often test their websites with a keyboard and mouse, and as a result, they make mistakes that affect keyboard-only users. WCAG Success Criteria (SC) 2.1.1, “Keyboard,” requires all functionality of web content to be operable through a keyboard interface alone.
Read More: What is Keyboard Accessibility?
In this scenario, a visually impaired user accesses your site with a screen reader, which converts text to audio or braille output. Screen readers look for ARIA (Accessible Rich Internet Applications) language, which tells assistive technology software how to interpret certain types of web elements.
The chat service isn’t properly labeled with ARIA attributes or alternatives, so when the dialog box opens, the user can’t understand what’s happening. The service is missing an ARIA-live property, which is important for explaining visual elements in a live chat, and other missing labels prevent the user from utilizing the chat feature.
Per WCAG SC 4.1.2, “Name, Role, Value,” all user interfaces should have names and roles that can be programmatically determined. In other words, the website needs to communicate the function of all interface elements to allow assistive technologies to function as intended.
Read More: Introduction to ARIA for Web Accessibility
Timestamps tell users when the last chat message was received, and they’re useful elements during long conversations. However, they can be excessive when a person is using a screen reader. Every time the person receives a message, they’ll hear the timestamp.
That can make conversations confusing and time-consuming for the screen reader user. Live chat features should allow time stamps to be switched off (and in general, chat widgets should provide as many options as possible to accommodate different types of users).
Read More: Why Screen Readers Are Essential for Website Accessibility
In this scenario, the chat service uses a different color contrast ratio from the rest of the website. People with visual impairments may be unable to read the conversation or interact with buttons that control the chat dialog.
Color contrast ratio is a numerical value assigned to the difference in light between the elements in the foreground (such as the font) and the background. WCAG SC 1.4.3, “Contrast (Minimum)” requires a contrast ratio of 4.5:1 for normal text and 3:1 for large-scale text, with several exceptions for decorative elements.
The Bureau of Internet Accessibility offers the a11y® Color Contrast Accessibility Validator, a free tool that provides an instant color contrast analysis.
Read More: The Basics and Importance of Color Contrast for Web Accessibility
These types of issues can prevent someone from using the live chat easily. In some cases, people might not be able to close the chat dialog, which will prevent them from accessing other pages on your website. Needless to say, this creates a frustrating experience for your visitors.
Fortunately, the WCAG framework provides plenty of guidance for making chat accessible. We’ve listed relevant WCAG criteria above, but other WCAG success criteria may be applicable depending on your chat service’s features. It’s important to evaluate chat widgets carefully before going live.
Accessibility needs to be a priority throughout development, and third-party widgets aren’t always designed with the best practices of accessibility in mind. Research widgets carefully before adding them to your website.
Look for services that have accessibility statements; if a widget conforms with WCAG standards (and that conformance has been confirmed by third-party accessibility experts), you can reasonably assume that it’s keyboard accessible and properly labeled.
However, you’ll still need to test your website to make sure that you’ve implemented the live chat feature properly. You can perform some simple tests on your own by accessing your site without a mouse, using your keyboard to navigate the chat controls. With that said, the safest course of action is to audit your website after adding major features like live chat to ensure that you’re not making mistakes that could affect your audience.