How to make sense of ADA website compliance.

Navigating the complexities of WCAG 2.0.

The Americans with Disabilities Act (ADA) was signed into law on July 26, 1990. Recently, there has been increasing legal pressure to treat websites as “places of public accommodation,” which means they would need to be accessible to people with disabilities. The Department of Justice is preparing guidelines for this and financial institutions around the country are trying to determine what measures they should implement.

Why is ADA compliance important?

ADA compliance can be intimidating. Depending on the size of your website and how recently the code was updated, it may involve hundreds or thousands of small changes to your content and markup. All of these changes need to be identified, performed, and checked over. In many cases, they require content specialists to weigh in. Why should you take on a project like this? There are some good reasons.

Some of your potential customers have disabilities

You probably don’t need to be reminded that competition in the banking market is fierce. Differentiating yourself amongst a staggering number of local, regional, and national banks, credit unions, and fintechs gets more challenging every year. Financial institutions everywhere are trying to incentivise and reduce barriers to conversions by implementing switch kits, online signups, and signing bonuses. But right now, as you read this, people with disabilities are shopping for financial institutions. Navigating the web can still be a frustrating experience for them, but if you take measures to improve your web experience for these individuals, you can start developing brand loyalty before everyone else jumps on the bandwagon.

How your visually impaired customers will experience your site

Many visually impaired individuals use screen readers to view web pages instead of computer monitors. Screen readers will either utilize a speech synthesizer to read the content to the visitor or render it on a refreshable braille display. While a monitor will present the page information to the viewer by interpreting the styling of the page, a screen reader will present the information by interpreting the structure of the page. That structure is largely defined by correct use of html markup and meta information.

If you’ve set up your site properly, users of screen readers will not need to tediously wait for each word of a page to be read to them in order. Many screen readers offer features that provide the user with lists of hyperlinks or headlines on the page. This is why descriptive link text and logically structured headlines are essential to a modern content strategy.

Curious how your website experience translates to a screen reader? Try the Fangs add-on for Firefox.

Upcoming Regulation

The DOJ is expected to release guidelines in 2018. However, many banks are choosing to update their sites in anticipation of these guidelines and to avoid lawsuits in the meantime.

How to know which level is right for you

There are three levels of compliance defined in WCAG (Web Content Accessibility Guidelines) 2.0: A, AA, and AAA. A is the most basic level and AAA is the most accommodating to individuals with disabilities. While we wait on guidelines from the DOJ, many financial marketers find themselves reading through the lists of requirements, trying to determine which level is appropriate for their institution. Unless you moonlight as a web developer, you may find it difficult to fully understand them. However, the general assumption is that level AA will become the official standard in 2018 and many financial institutions are moving to implement those guidelines now.

THE BASICS

The WCAG 2.0 standards are organized into four sections: Perceivable, Operable, Understandable, and Robust. Below is a summary of the concepts in each section with a focus on AA level requirements. If you’d like to review all the requirements, you can find a comprehensive list here.

Perceivable

  • Any content on your site that isn’t presented as live text should have a text-based alternative.
  • If you have live audio content, you should provide captions.
  • It should be possible to understand and operate your content without relying on sensory characteristics such as shape, size, visual location, orientation, or sound.
  • Color should not be used as the only visual means of conveying information. For instance, if you want to have an infographic that uses color to distinguish different categories, make sure there’s a redundant labeling system that complies with WCAG 2.0 standards.
  • If audio lasts more than 3 seconds, the user should be able to pause it, stop it, or turn the volume down independently from the overall system volume level.
  • You should maintain a certain contrast ratio (4.5:1 for level AA) for text and images of text.
  • Users should be able to resize text up to 200 percent without loss of content or functionality.
  • Images of text should be avoided in most cases.

Operable

  • Users should be able to navigate and operate your website using standard arrows, tabs, and exit methods on a keyboard. There should be a mode of operation in which the keyboard focus indicator is visible.
  • If anything automatically moves, scrolls, or blinks, the user should be able to pause, stop, or hide it. Nothing should flash more than three times a second.
  • Users should be able to bypass blocks of content that are repeated on multiple web pages (such as navigation menus).
  • Titles, headings, and labels should be used logically and descriptively.
  • Focusable components should receive focus in a logical order that preserves meaning and operability.

Understandable

  • Browsers should be able to detect the default human language of your website.
  • When any component receives focus, it should not initiate a change of context. (The state of the interface shouldn’t drastically change as a result of tabbing or mousing over an element.)
  • If any interface component will cause a change of context, the user should be notified of this prior to using it.
  • Navigation mechanisms that are repeated on multiple Web pages should occur in a consistent order.
  • If an input error is detected, the error should be described to the user in text and the item in error should be identified.
  • If user input is required, labels or instructions should be provided.
  • If the webpage allows for legal commitments, financial transactions, or data updates, the user should be able to reverse the submission or have the opportunity to review the submission before finalizing it.

Robust

  • Markup elements should have complete start and end tags, should be nested according to their specifications, and should not contain duplicate attributes. All IDs should be unique, unless specifications allow for exceptions.
  • The states, properties, and values of user interface components which can be set by the user should also be able to be set programmatically.

NEXT STEPS

If you’d like to ensure your site complies with WCAG 2.0, the first step is to audit your site content and markup. You’ll want to run an automated report to identify potential issues (at your chosen compliance level) and manually review them to assess any changes. Fixing the issues can be tedious work and reports should be run regularly to track progress. Once complete, we recommend monthly reviews of reports to ensure that no new issues arise as a result of ongoing content updates and site maintenance.

You may have a lot of work ahead of you, but you’ll be doing your part to help make the internet better for everyone.

Need some help?

If you have any questions or are interested in having your website assessed for ADA compliance, please contact Nathan directly at nc@adventurehousenyc.com.

With over a decade of experience working with websites, Nathan helps clients by advising on UX, developing strategies to achieve their digital business goals, and coordinating teams with diverse skill sets.