Digital Accessibility (A11Y)

Foundational knowledge for building digital experiences that are accessible to all audiences.

Table of contents

  1. Why Make Digital Experiences Accessible?
  2. How Assistive Technology Works
  3. Accessible HTML/CSS
  4. Accessible (Web) Javascript
  5. Accessibility Tools & Resources

Why Make Digital Experiences Accessible?

The Americans with Disabilities Act requires that all state and local governments (ADA Title II) and business open to the general public (ADA Title III) build digital experiences that are accessible.

Various web standards have been developed to check conformance with the ADA. The most notable are Section 508 (developed and used by USA federal gov) and WCAG (developed by W3C and used by USA federal gov).

Additional references:

How Assistive Technology Works

At a high level, there are various accessibility specifications and APIs that define what information and functionality a computer can expose to assistive technology (AT). For example, on the web, the browser takes the DOM and converts it to an ‘accessibility tree’ which exposes all the relevant accessibility information and available controls to the accessibility API which is then used by AT. The Firefox Accessibility Inspector does a really nice job showing us what this looks like for any webpage.

Accessible HTML/CSS

A web browsers uses HTML document to expose key information to AT. The key metadata are:

  • role: define what an element is or does. Many of these are so-called landmark roles, which largely duplicate the semantic value of structural elements, such as role="navigation" (<nav>) or role="complementary" (<aside>).
  • property: used to give them extra meaning or semantics. As an example, aria-required="true" specifies that a form input needs to be filled in order to be valid, whereas aria-labelledby="label" allows you to put an ID on an element, then reference it as being the label for anything else on the page, including multiple elements, which is not possible using <label for="input">.
  • state: define the current conditions of elements, such as aria-disabled="true", which specifies to a screen reader that a form input is currently disabled. States differ from properties in that properties don’t change throughout the lifecycle of an app.

By default, HTML has reasonable defaults for accessibility information and controls when used correctly. For example see how built-in HTML elements map to ARIA roles. For that reason, these are the most important a11y considerations when writing HTML/CSS:

  1. Use the right HTML element.
  2. E.g. Use a <button> instead of a custom-styled <div>.
  3. Use the right HTML document structure.
  4. E.g. Don’t store your entire page in an HTML <table>. Use headers, sections, articles, and landmarks instead.
  5. Provide meaningful text lables (i.e. innerText for <a>), and text alternatives (e.g. alt attribute for <img>).

Additional references:

Accessible (Web) Javascript

When building custom components and experiences in Javascript, the most important thing to keep in mind is that we’ll have to write our JS so that we add back in the basic information and controls that AT expect. This means setting WAI-ARIA attributes appropriately.

Accessibility Tools & Resources