Beyond keyboard support: semantics for assistive tech

Making a site keyboard-accessible is a significant first step, but it only addresses users who can physically operate a pointing device if they choose to. Many users rely on assistive technology to interact with the web at all, often without a visual interface. Fortunately, the work you put into keyboard support lays a strong foundation for supporting these users as well.

To build for users like Victor Tsaran, who is blind and navigates the web with a screen reader, you need to understand how assistive technology works and how HTML expresses meaning beyond visual appearance.

What counts as assistive technology

Assistive technology is a broad term covering any device, software, or tool that helps a person with a disability complete a task. That can range from a simple magnifying glass to a complex screen reader. In a web context, it includes screen readers, braille displays, screen magnifiers, voice control software, switch devices, and browser extensions, some of which ship built into the operating system.

Browser zoom is a form of assistive technology. A custom game controller is another. The line between assistive and general-purpose technology shifts over time: speech synthesis began as a talking calculator for blind users and now appears in navigation apps and virtual assistants. Conversely, a smartphone's camera zoom, designed for general use, helps people with low vision read small text in the real world.

Users may come to your site through any of these tools. Many of them depend on programmatically expressed semantics to form an alternative, usable interface from your page's DOM. That concept starts with affordances.

Affordances and their semantics

An affordance is an object that offers its user the chance to perform an action. A teapot's handle tells you to pick it up there; the spout does not suggest the same use, even if you have never seen a teapot before. Good affordances make their use obvious through familiar form.

In a graphical user interface, affordances are designed to be unambiguous because there is no physical object to inspect. You interpret common form elements this way:

  • Radio buttons — "I can choose one of these options."
  • Check box — "I can choose 'yes' or 'no' to this option."
  • Text field — "I can type something into this area."
  • Dropdown — "I can open this element to display my options."

You draw those conclusions because you can see the elements. A user who cannot see the visual clues cannot grasp the affordance's meaning. The information must be expressed flexibly enough that assistive technology can build an alternative interface. That non-visual exposure of an affordance's use is its semantics.

How screen readers consume semantics

A screen reader is a program that reads screen text aloud in a generated voice, enabling visually impaired users to operate a computer. The user moves the cursor with the keyboard to control what is read. Victor Tsaran uses the built-in screen reader on OS X, VoiceOver, to navigate the web this way.

You can get direct experience with a minimal, JavaScript-based screen reader called ChromeVox Lite on a page that deliberately blurs the screen. The demo works in Chrome; a control panel at the bottom lets you explore content with Previous and Next buttons and activate elements with a Click button.

Using the demo, notice that the screen reader reports several pieces of information about each interface element:

  • The element's role or type, if specified.
  • The element's name, if it has one.
  • The element's value, if present.
  • The element's state, such as enabled or disabled, where applicable.

A screen reader constructs this complete alternate user experience because native HTML elements contain built-in accessibility metadata. Just as the rendering engine builds a visual interface from the native code, the screen reader uses the metadata in the DOM nodes to build an audible one. Well-designed native elements carry the role, name, value, and state that make this possible—and that is exactly the kind of semantics you ensure when you write thoughtful HTML.