For the last few months, we’ve been working on making our LiveChat Chat Widget accessible and ensuring it meets the WCAG requirements. We had to get acquainted with success criteria, translate them into specific technical tasks, then validate our solutions and introduce corrections.

The whole project was very challenging, especially choosing between conflicting interpretations of the requirements and match. We repeatedly had to clarify a specification to match specific parts of the application that did not match the available examples. We want to share the knowledge gained during the project and explore how we adapted the LiveChat Chat Widget application to WCAG 2.1 level AA requirements. We decided to create a series of posts about the most complex technical aspects of making web applications accessible.

Web Content Accessibility Guidelines

As mentioned before, the LiveChat Chat Widget meets WCAG 2.1 requirements. What does this mean exactly? Web Content Accessibility Guidelines (WCAG) is a standard for web content accessibility provided by the World Wide Web Consortium (W3C). WCAG defines testable success criteria grouped into three conformance levels: A, AA, and AAA (the best). However, level AAA is usually not required for the entire content of a webpage because it is impossible to meet its success criteria for some parts of the content.

Sample success criterion: text contrast. Level AA requires that the text must have at least a 4.5:1 contrast ratio in most cases, but level AAA requires a 7:1 contrast ratio.

WCAG comes with an easy-to-navigate, detailed reference guide, along with techniques documented with examples, code, and descriptions of test procedures.

Another important document is Aria Practices, which provides developers with practical examples of how to implement specific solutions so that they are accessible to people with limitations.

Why we should care about accessibility

We understand accessibility as enabling people with limited abilities to use a website or web application. Taking care of accessibility should be done from the very beginning of every project — there are several reasons for this.

1. According to the WHO’s ”World report on disability” from 2011, 15% of the global population live with some form of disability. That translates to a massive number of visitors that benefit from improvements in this area. 2.2 billion people have a near or distance vision impairment. The issue of accessibility is often seen as a problem that affects only a negligible minority. We pay very little attention to these problems, and actions to improve the situation have been disproportionate to the actual scale of the problem.
2. Taking care of website accessibility brings profit to every user. Meeting color requirements is essential for people with severe vision impairments, but it’s also helpful for those with impairments classified as “moderate” or “mild.” Valid document semantic structure is useful for every tool that needs to better understand the content of your website. It can improve multiple other aspects, like SEO. Alternative image descriptions can be applicable in the case of bad network conditions or failure.
3. Many countries require a particular category of institutions to ensure website accessibility. In the USA, such requirements for public institutions and those cooperating with them are imposed by the American Disability Act (ADA). In the case of the European Union, similar requirements are imposed by the Web Accessibility Directive. The requirements of these documents are often specified at the level of state law in the United States or the countries of the European Union.
4. Taking care of accessibility should be part of caring for a responsible brand image.

In the case of LiveChat, in the document “The LiveChat Software Living Constitution” we have a clearly defined vision: “Customer communication without barriers.” Such a vision means that we have to treat accessibility as the most important topic we should be dealing with.

Work areas

When thinking about people with limitations, we should take into account the needs of people with visual, hearing, mobility, and cognitive impairments. In the case of our application, the most demanding tasks can be grouped into three areas:

Keyboard navigation

Making sure that the app interface can be fully used without the need for additional input devices like a mouse or trackpad. The user should know which item is currently focused; keyboard navigation should be logical and comfortable.

Screen readers

Content should have correct semantic structure; interactive elements should have proper aria tags, and all state changes should be announced to the user. Meaningful non-text content should have an alternative text description. This enables screen readers to work correctly with your website, together with other accessibility tools, for example, Voice Control on devices with iOS systems.

Visuals

Colors should meet minimum contrast requirements and shouldn’t be used as the only way to indicate app status.

Summary

We’ll cover each of these areas in detail in the following posts. Behind each of these points, there are many additional needs. In our posts, we will focus on the problems and requirements of the Chat Widget application; it is not a complete guide for any type of application.

Besides this, we will describe how to start the process of customizing already running projects: how to test the compliance level of an application and how to use test automation to avoid regression in this area.

We hope these articles will help developers and designers look closely at the topic of accessible web applications and provide practical tips. Unfortunately, despite the dynamic development of browsers, standards, and technologies, a lot of work in the area of accessibility still requires manual implementation. Commonly used interface elements, such as modal pop-ups, have well-defined requirements for keyboard navigation. Unfortunately, browsers do not provide built-in mechanisms for them. Had the native focus-visible pseudo-selector support been released earlier, we might have prevented the practice of disabling outline from being popularized for active elements. On the other hand, developers have more and more tools to test the accessibility of their websites, like the Emulate vision deficiencies in Chrome DevTools, the Accessibility tab in the Firefox devtools and the Axe browser extension.