The idea of making a site accessible is not something new. What's new and what we have been seeing over the past several months is how designers and experience architects are approaching the story they are trying to tell with their designs. The more the experience team understands about the technicalities of ADA standards, the more approachable, semantic and accessible your site will be which, in turn, will provide more unique visits, a greater experience on mobile and polished SEO practices. These are just some of the things that inherently improve when implementing accessibility standards.
The Web Content Accessibility Guidelines (WCAG) were created by the non-profit World Wide Web Consortium (W3C). WCAG consists of a series of guidelines for making web content accessible. WCAG 1.0 was introduced in 1999, and has since been superseded by WCAG 2.0, published in 2008. The latest release is version 2.1 which was made official on June 5th, 2018. WCAG 2.1 mostly focuses on mobile technology, accessibility for people with low vision, and people with cognitive disabilities.
Comparing WCAG Levels
WCAG comes in three levels: A, AA and AAA; where A is the weakest and AAA the strongest. Level A conformity has a minimal impact but also minimal effect. It allows browser readers to more effectively navigate a site, but it doesn’t make a site compliant to the level the Department of Justice wants to see. The happy medium – and the one to keep on your radar is level AA. Level AA is not so light as to leave a large number of folks with disabilities behind, and not so restrictive as to greatly affect your site’s look, feel and functionality.
To summarize the different levels:
- Level A – Considered the highest priority and easiest to complete. This is the minimum level of conformance.
- Level AA – More detailed; satisfies all Level A and Level AA success criteria.
- Level AAA – Follows the strictest guidelines and is the most comprehensive in design. Satisfies Level A, Level AA and Level AAA.
When implementing accessibility standards, a large effort is put on the front end engineers to make sure they understand the rules and to know how to implement them within any given context. For example, a modal window. You see them everywhere on sites and you might think it's a simple component. When surrounding the modal with accessibility guidelines, it becomes a bit more complicated. For instance, if someone is visually impaired, you have to ask yourself these questions:
- How do they know the button will open the modal?
- How will they know it's a modal?
- How will they know when the modal is open or closed?
- How will they know how to close the modal window once it's open?
- What happens when you close the modal?
There are many attributes and pieces of code we will write in order to tell a screen reader what is happening on every move a user is making and, most importantly, what context they are in - whether it's a modal, piece of text, headline, button, etc...
Quality assurance is imperative when a site is implemented with WCAG 2.1 standards. Outlined below are three stages of testing that we do to ensure your site is meeting the WCAG guidelines that are required.
There are multiple tools that can be used to rake your page and give you a bug count as well as an accessibility grade. Some tools will also provide suggestions on how you can fix the issues it finds. Since dynamic content is a big part of a CMS, it’s important for the tool you choose to be able to run on a regular basis and provide reports in case someone enters some non-compliant content. Any problems should be fixed immediately to avoid any potential legal issues.
Non-visual Testing (Screen Readers)
Visually impaired customers will come to your site and expect to have the same experience as anyone else. These customers need to be able to navigate through the site with ease and never question where they might be in a multi-step process, a form, primary navigation, etc. We use industry standard screen readers to ensure that we can mock the way disabled customers might navigate your site and check that everything makes sense.
Manual testing is equally as important as non-visual testing. We follow a very specific matrix when testing pages manually.
A few examples might be:
- You can always see the keyboard focus when tabbing through the page.
- Keyboard focus does not unexpectedly shift to other elements.
- Tab order is logical.
- If dropdown menus exist, the keyboard can be used to select and open items in them.
- Dialog boxes or pop-up menus receive keyboard focus.