Digital Commerce for an Accessible World
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.
Digital 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.
Legislation & Standards
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.
Americans with Disabilities Act
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.
Web Content Accessibility Guidelines (WCAG)
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).
Requirements by Country
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. |
Approach to Compliance
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.
Common Accessibility Recommendations
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.
Text In Images – Text that is part of an image is not readable by a screen reader, and should be avoided. The content component for the offending image should be updated to contain a text attribute, and the look and feel of that text should be managed in the stylesheets. Search Engines tend to penalize sites that have text in images, so fixing this issue will also improve SEO.
Tab Order – Individuals with visual impairment rely on screen readers, which navigate through a page in tab order. The tab order of the site should navigate through the page elements in a logical order. Keep an eye out on your shopping carts or other product lists. The screen reader should navigate through the elements of the first product before moving to the second product. In general, tab order should follow standard reading order for the site’s language.
Tables v. Divs – When possible, use tables to represent tabular data. This facilitates the appropriate tab order without having to make specific updates to update tab order.
ARIA Landmarks – ARIA landmarks are essentially page element metadata that tell a screen reader what the element is. They can be used to indicate banners, form elements, navigation and other landmarks on a page. For more detail on ARIA landmarks, refer to the W3C ARIA Landmarks General Principles.
Alt Text – Similar to ARIA Landmarks, alt text indicates to screen readers what an image or other element depicts. When alt text is missing, it may be skipped over or generically described by a screen reader. Alt text should contain enough information to succinctly describe the image in a few words.
Icons as Buttons – When buttons or other clickable elements do not have text associated to them, it is difficult for screen readers to determine their purpose. Buttons without text should use the appropriate metadata (ARIA landmarks and alt text) in order to facilitate the screen reader experience.
Text Color Contrast – Colorblindness is a common visual impairment that should be considered when thinking about accessibility. Without sufficient color contrast, people with colorblindness may not be able to differentiate page elements. Graphical data such as charts that are often color coded should either use colorblind-friendly methods for distinguishing data, or have a colorblindness toggle that switches from a standard view to a color-blind accessible view. There are also a number of online tools to verify contrast such as https://accessible-colors.com/.
Conclusions
Equal access to technology is an increasingly important topic that has too often been disregarded by a spectrum of companies. Accessibility should be as important to a business as any other site functionality. Accessibility issues cause users to abandon a site, and litigation and regulatory penalties stemming from non-compliance is costly.
Pick a compliance standard (we recommend WCAG 2.1 AA, 2.2 when it is available in early 2021) and just do it.
Still have questions on compliance, or want an in-depth accessibility audit? Contact Us for some help! We have a ton of experience in accessibility for eCommerce and we’d love to help you solve your accessibility issues.
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.