Web Accessibility and Accessibility API

Web content is marked up with host language markup and accessibility APIs.

The accessibility API maps the markup into an interface that browsers and other apps can access.

The accessibility API includes a number of interfaces that browsers and other apps can plumb into.

The accessibility API acts as an intermediary between the browser and the screen reader.

The accessibility tree is a hierarchical representation of elements in a UI or document, as computed for an accessibility API.

In modern browsers, the accessibility tree for a given document is a separate, parallel structure to the DOM tree.

Generally speaking, modern web browsers wait until after style computation to build up any accessible objects.

Browsers wait in part because generated content (such as ::before and ::after) can contain text that can participate in calculation of the accessible object’s name.

CSS styles can also impact accessible objects in other various ways: text styling can come through as attributes on accessible text ranges. Display property values can impact the computation of line text ranges.

These are just a few ways in which style can impact accessibility semantics.

An accessible object will generally include a few things: a form, a label, a range input, and a div with a role of “button.”

The label will take its Name from the contents of the label element, and the input will take its Name from the id attribute.

The div will be mapped as a button with the name “Log Mood,” and the button will be surfaced as “invokable” to screen readers and other ATs.

The div can also be included in the accessibility tree if it has a role of “button.”

Standards define some rules around when user agents should exclude elements from the accessibility tree. Excluded elements can include those hidden by CSS, or the aria-hidden or hidd attributes.

Accessibility is the responsibility of browsers.

Browsers do this by sending accessibility API notifications about various events.

ATs can subscribe to these notifications to receive information about changes in content.

Testing with screen readers and dev tools is essential for robust accessibility.

Robust accessibility testing could probably be summarized as follows: testing with users after your own manual test passes is great!