The U.S. Americans with Disabilities Act (ADA) of 1998 establishes broad requirements to provide people with disabilities access not to just physical locations but also to information, including electronic information.

The ADA, and specifically the ADA’s Section 508 which addresses electronic information, creates the requirement for the providers of Electronic and Information Technology (EIT) to provide access to people with disabilities.

Broadly speaking, technology providers should consider themselves required to provide platforms with tools that allow people with disabilities to access EIT, and publishers or owners of EIT should consider themselves required to use the tools to provide access.

While Section 508 ostensibly applies to federal agencies, it has been interpreted, litigated, and ruled upon broadly to include, in practice, almost any electronic information and electronic information provider.

In the plainest terms and the most common scenario, anyone with a website should heed the ADA.

Trade Groups Address ADA with WCAG, VPAT Guides

Recognizing the need for a wide range of businesses and agencies to understand and comply with the ADA’s hundreds of broadly interpreted sections, a number of trade groups have created guides.

The Information Technology Industry Council (ITIC), for example, established the Voluntary Product Accessibility Template (VPAT), and the World Wide Web Consortium (W3C) established the Web Content Accessibility Guidelines (WCAG).

While W3C makes periodic updates to the WCAG (pronounced wick-agg), most recently on June 5, 2018, with version 2.1, the guide overall aims to provide "a single shared standard … to make web content more accessible to people with disabilities.”

The guide counts web content as both natural information (like text and images) and the code and markup used to structure and present natural information (like alt tags and metadata). Disabilities named in the guide are visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities.

The World Wide Web Consortium forms the Web Content Accessibility Guidelines around four principles -- Perceivable, Operable, Understandable, and Robust – and cites dozens of scenarios with specific solutions.

WCAG: Perceivable

The initial WCAG principal is that web content must be perceivable – web content must be presented to users, including users who are disabled, in a way that users can perceive.

For example, text colored in red to indicate a problem may not register as red to a person who is color blind. Therefore the message that there is a problem may not be perceived. The better practice is to have more than one way to perceive the content -- for example, marking problems with a warning icon in addition to coloring them red.

Another basic scenario is presenting web content to people who are blind. People who are blind commonly use screen reader technology that translates text into synthetic speech (another method is technology that translates text onto a physical strip of dynamic braille).

But how would such technology work for web content that is not text, such as a photo? A solution is to use a text alternative, such as an HTML alt tag. The alt tag provides a textual description of the photo so the screen reader (or braille hardware) can "read” the photo and the photo can in turn be perceived by a person who is blind.

In both examples, providing a second way to perceive web content makes the web content perceivable to more people. The more ways provided to perceive the web content, the greater the number of people who can perceive it -- including people who have disabilities.

WCAG: Operable

A house metaphor might be useful in describing the WCAG operable principle.

While the content of the house might be perfectly perceivable in its own right, the content remains inaccessible to people who are unable to use the door knob. Recommendations within the WCAG operable principal include making all web content and functionality available from a keyboard, like tabbing through clickable links and options. This allows people who are disabled to use keyboard alternatives such as speech input to simulate keystrokes and operate all of the functionality that is otherwise available.

Likewise, the house contents is not accessible if the door snaps shut before people have time to walk inside. The WCAG operable principal includes recommendations to allow users, including users who are disabled, enough time to read and use content. One such recommendation is for web content that includes no time limit in which to complete an action, so that people have all the time they need to complete the action.

The content of the house also is not accessible if the directions to the house are so confusing that people get lost. Recommended by the WCAG operable principal are descriptive links, labels, titles, and other ways to help users navigate, find content, and determine where they are. It’s sound web content and Search Engine Optimization advice regardless of the ADA, and it is particularly useful in the context of assistive technology that helps people with disabilities navigate from heading to heading or title to title, for example.

The WCAG operable principal also addresses seizures, recommending for example that web content contains no element that flashes more than three times in any one second period.

WCAG: Understandable

The WCAG understandable principal concerns itself, straightforwardly, with making web content readable and understandable.

One of the recommendations of the WCAG understandable principal is to mark the HTML with the language attribute so that the language of the web content can be automatically determined. Identifying the language makes it easier for translation software to convert the language to braille, or for speech synthesizers to orient to the syntax of the content. Marking the language of the web content makes it easier for assistive technology to read the web content.

The WCAG understandable principal also recommends web content that is predictable, such as consistent HTML labels for functionality. If one form field is labeled "Search” and an identical form field is labeled "Find,” assistive technology used buy a person who is blind will convey two different types of functionality when in fact there is no difference.

The final portion of the WCAG understandable principal refers to input assistance that help users avoid and correct mistakes. An example is error identification, like automatically letting a user know that data they typed is invalid for a field – in text so that assistive technology can read it.

WCAG: Robust

Finally, WCAG calls on web content to be robust, meaning that it’s compatible with assistive technologies.

The WCAG points out that the visual appearance of elements help sighted people determine the use of the element, such as the ubiquitous X at the top right of a browser window used to close the window. How does a person who is blind interact with that element?

One way is to provide the X an Accessible Rich Internet Applications (ARIA) attribute in the HTML or Cascading Style Sheet. The ARIA attribute provides the element a text-based entity that assistive technology can identify and convey to a user who is disabled.

WCAG’s Recurring Concept: Multiple Ways to Access Everything

The Web Content Accessibility Guidelines from the Worldwide Web Consortium identifies dozens of scenarios in which web content may become inaccessible to a person with a disability and therefore in violation of the Americans with Disabilities Act. The WCAG also provides possible solutions for each scenario.

Keep in mind, however, that no guide can cover all of the scenarios for all disabilities. One may argue that even the ADA itself doesn’t cover every scenario since the ADA is at all times open to legal and other interpretation, including on accessibility issues that have yet even to be raised.

The WCAG takes great care to state repeatedly -- dozens of times in fact -- that its recommendations and techniques should not be presumed to be sufficient in all situations.

Instead, the WCAG forms around the principals of perceivable, operational, understandable, and robust web content to encourage web content providers, and web content platform providers, a guide to making web content accessible.

Recurring throughout the course of the WCAG is a concept of structural redundancy. For everything there is to do with web content, there should be more than one way to do it.

Web content should be able to be perceived by more than one method; website functionality should be operable by more than one method; web content should be able to be understood by more than one method; web functionality should be able to be accessed by more than one method; and so on.

Providing additional ways to perceive, operate, understand, and direct web content makes web content more accessible to those who might not be able to access it in the most common ways.

The more ways provided to perceive, operate, understand, and direct web content, the greater the number of people who can access it.

Bottom line: As a publisher, for everything that can be done on a website, provide more than one way to do it.

What Makes a Website WCAG Conformant?

The accessibility of a website is a combination of the page markup and the website design, down to every webpage.

However the website is published, hand-written or using a content management system (CMS), the website and all of its pages need to support low-level best practices like ARIA, well-described HTML elements, and valid language constructs.

Ultimately the design and page markup of the website dictates compliance. There is no definitive test, no defined benchmark, and W3C does not endorse any specific tool. Technically, there is no proof of conformity, but there are a number of tools that score the level of accessibility, including Google Lighthouse, which is become an increasingly popular evaluation tool.

Ultimately laws and society at large determine accessibility and conformance, which is always evolving, making it necessary for publishers to define their standard and to regularly test using the latest tools and adjust accordingly.

Essent recommends that webmasters use the Google Lighthouse tool to see how their website scores on accessibility. The tool also lists what actions can be taken to improve the score.