Skip to main content

Accessibility Playbook

Everyone who is building products for the web should understand the medium and the role semantic HTML plays in accessibility.

HTML elements are so much more than their native styling, which can always be removed or changed with CSS. They convey specific information to screen readers, as well as keyboard controls and behaviors that may vary across different browsers and operating systems. Ignoring these important features in the pursuit of a custom-designed control, or just using a nonsemantic <div> instead will unexpectedly change context and/or interactions for assistive technology users.

HTML stands for HyperText Markup Language. “Markup” is the key. Think of HTML as a way of telling the browser, “this text is a level 1 heading,” “this is a button,” and “these links are navigation links.”

ARIA is a set of attributes that can be added to HTML elements to extend their accessibility.  Unlike semantic HTML, ARIA attributes are not always required for accessibility and should only be added on a per-case basis where necessary.

Semantic HTML vs ARIA

It’s been said that the first rule of ARIA is don’t use ARIA. That is often misunderstood as “don’t use ARIA at all.” But what that really means is to prioritize using semantic HTML and the native behaviors that already exist within, and then use ARIA where either:

Think of ARIA as a bridge to add additional accessibility support to a custom component that doesn’t exist natively. 

The W3 has 5 rules of ARIA.

  1. If you can use a native HTML element [HTML5] or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state, or property to make it accessible, then do so.
  2. Do not change native semantics, unless you really have to.
  3. All interactive ARIA controls must be usable with the keyboard.
  4. Do not use role="presentation" or aria-hidden="true" on a focusable element .
  5. All interactive elements must have an accessible name.

Interactive HTML elements are particularly difficult to recreate through ARIA and JavaScript because chances are a developer will not be aware of them all, and some of their nuances between different browsers and operating systems. For example, an HTML button already has included behaviors for the ENTER key—which fires on keydown, and can be fired repeatedly while holding the key—and the SPACE key—which fires on keyup and will not fire if you navigate off the button while the SPACE key is pressed. 

Designers and Code

Designers might not ever need to write front-end code, but it is critical that they know how semantic HTML and ARIA can directly impact the user experience for those using assistive technology. When designers only spec out the visual design, engineers are left to design the experience for assistive technology.

Providing accessibility annotations in design specs can mitigate against engineers implementing a user experience for disabled users that is misaligned with the visual presentation. 

For sighted users, it might be obvious where the main navigation is located on the page, which is often a distinct bar across the top. Without placing those links inside a semantic <nav> element, as far as screen reader users can tell, it would be as if a navigation bar was never designed.

Headings are one of the most important ways for users to understand information and relationships on the page, so content designers must consider how the page structure is communicated when all visual styling is stripped away.

Designers can make a tremendous difference simply by understanding how assistive technology works, and how HTML and ARIA can improve or degrade the user experience. 

How We Know We’re Doing This

  • Our designers use accessibility annotations correctly
  • We use semantic HTML and ARIA appropriately
  • Our code reviewers are looking at HTML element choices and ARIA use

How We Know We’re Coming up Short

  • We use ARIA where HTML alternatives exist and can be used
  • We overuse ARIA
  • We intentionally do not use ARIA at all
  • We use divs by default without considering semantic alternatives

Darker blue background

Accessibility Playbook

We created this playbook to help digital product teams develop more inclusive habits to improve how they approach supporting accessibility on their projects.