This October is the 75th National Employer Disability Awareness Month, and the Department of Labor’s theme for this year is “Increasing Access and Opportunity.” At Avatria we’ve seen a number of instances where web accessibility is neglected, and we’ve been a part of building accessible eCommerce experiences for clients of all types and industries. This October we wanted to put a spotlight on the topic of Accessibility in Digital Commerce, outline the legislation and standards to be aware of, and offer a simple approach to compliance.
The value of omni-channel commerce is nothing new—most companies cite it as a goal, some claim to have achieved it, and plenty of experts talk about its importance—but a critical component of building an omni-channel experience is often overlooked. Most conversations focus on the where and when of shopping, leaving the how serving as omni-channel’s unspoken third pillar. But to create a truly omni-channel experience, we must discuss the how, and to do so, it’s imperative to talk about web accessibility.
Put simply, web accessibility is the subject that covers how people with a variety of disabilities use the internet, and adaptations made to websites to provide a seamless experience to these consumers. Because so many websites are built around text and images, considerations for web accessibility often focus on people with visual impairments.
To interact with digital technology, many people with disabilities use special tools known as “assistive technology.” If websites don’t accommodate those tools and limitations, then people with disabilities will not be able to use the website. The most prevalent type of assistive technology are screen readers, which read page elements out loud to a user. Users can then move through a page using their keyboard and navigate a website. There are browser plugins that are used, however most screen reader users use a desktop app such as JAWS, NVDA and VoiceOver (the built in screen reader that comes with MacOS). Because of their prevalence, much of the Web Content Accessibility Guidelines (WCAG) is oriented towards screen reader users.
Building an accessible website isn’t just a best practice for supporting a truly omni-channel experience. Most major jurisdictions require some level of accessibility support by law, and so it’s important to understand what regulations and standards govern your website.
Unfortunately, that’s not always easy. Similar to privacy regulations, accessibility regulations are a patchwork quilt of inconsistent laws and competing standards that are confusing to understand and follow, especially at the global level. To help, we’ve summarized some of the most important ones below.
In the United States, the Americans with Disabilities Act (ADA) of 1990 is the most relevant federal law under which web accessibility falls. Given its age, the text of the ADA is largely outdated for the purposes of the internet (like many laws, given how changes in technology tend to outpace the legislative process). However, the Department of Justice and the court system have interpreted the ADA’s broad (and sometimes vague) language to mean that “accessibility” extends beyond physical accessibility and includes the internet. As a result, the ADA requires that businesses must provide a usable online experience for people with disabilities, but does not go into any level of detail around specific requirements.
Given the shortcomings of the ADA, understanding the WCAG is incredibly important to achieving accessibility compliance. Published by the World Wide Web Consortium (W3C)—an international, non-governmental body that establishes common standards for the web—the WCAG is a set of accessibility recommendations updated regularly to account for updates to web technology.
The WCAG has 3 levels of conformance: A, AA and AAA. Each guideline within the WCAG is tagged with a conformance level for which it is required. By definition, everything within level A is included in level AA, and everything within level AA is included in level AAA. As such, level AAA is the most stringent level of conformance in the WCAG. To see what’s included, W3C publishes a very handy and filterable quick reference guide to help achieve compliance.
In addition to the varying levels of conformance, there are different versions of the WCAG as it is updated over time. WCAG 2.1 is the most recent guideline published, however WCAG 2.2 is scheduled for publication in early 2021. The AA conformance level is typically what is recommended based on what various countries require (more on this below).
While the WCAG is intended to be a global standard, many countries have not adopted it legally as their standard. As such, it’s important for businesses to understand what each country requires to achieve compliance, especially if a company does business in multiple countries. The table below includes a summary of compliance for a selection of common jurisdictions; to learn more about requirements for countries outside of this list, please contact us.
Country or Legislative Body | Required Compliance |
---|---|
European Union | WCAG 2.0 AA (https://europa.eu/european-union/abouteuropa/accessibility_en) |
United Kingdom | WCAG 2.1 AA (https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction) |
Canada | Broadly, WCAG 2.0 AA, but requirements differ from province to province |
Australia | At a federal level, the Australian government vaguely refers to the WCAG, but specific version and conformance level is unclear. The state of South Australia requires WCAG 2.1 AA |
China | Given the differences in Chinese and Latin scripts, China has adapted WCAG 2.1 for its own purposes. |
United States | For non-governmental entities, the language is vague, but certain elements of WCAG have been adopted. |
As we’ve seen, compliance varies not only country to country, but also within countries. When we put forth our recommendation for GDPR and other data privacy compliance, our recommendation was to comply with the most stringent and restrictive rules as a foolproof method to be compliant everywhere. Our recommendation for Accessibility compliance is similar. Even for businesses that are not international, a good approach to compliance is to pick the most updated set of guidelines (currently WCAG 2.1) and a conformance level that matches the strictest conformance level required by a jurisdiction (AA). When the WCAG 2.2 becomes available in early 2021, we would recommend achieving AA conformance in it as well.
It’s easy to fall into the trap of only considering publicly facing websites when evaluating your business’ compliance with the WCAG. It is important, however, to consider logged-in experiences as well. While exposure and liability may be more limited for logged-in experiences, they are still required to be accessible. Beyond customer-facing technology, it is important to also consider back office tools. Accessibility is not just for customers—it’s for everyone, including your own employees using internal tools. Oftentimes business tools are out of the control of the companies using them, so it is important for companies to raise accessibility issues with their technology partners and vendors.
To ensure that your solutions are up to snuff, it’s vital to test your experiences with the actual tools people with disabilities use. Just like you wouldn’t build a wheelchair lift without testing it in a wheelchair, you shouldn’t build web technology without testing it using a screen reader. Just like you might test in Chrome, Firefox, Edge and Internet Explorer, consider adding a screen reader or two (there are standalone desktop apps as well as browser plugins) to your list of supported “browsers.” There are other browser plugins such as SiteImprove that can help quickly assess a page for accessibility issues. However, while these plugins are helpful, they should not be solely relied upon to achieve compliance.
There are all sorts of issues that can break WCAG compliance, however there are several items that we see most commonly. This is not an exhaustive list, and the WCAG Quick Reference should be used as a definitive list of accessibility requirements.
Disclaimer: The content within this article is meant to be an informational guideline only and should not be interpreted as legal advice. Please consult an attorney for any legal questions.