You're only supposed to blow the bloody doors off!

You're only supposed to blow the bloody doors off!

BristolJS, Bristol May 2017

You're only supposed to blow the bloody doors off!

Screen readers

Software that translates on-screen content into synthetic speech

Jaws NVDA Voiceover Narrator

Virtual/browse mode

Windows screen readers create a virtual copy of the browser contents

Virtual/browse mode demo: text

Virtual/browse mode demo: headings

Forms/focus mode

Windows screen readers pass keys straight through to the browser

Forms/focus mode demo: forms

Keyboard intercept chain

Screen reader
Mac OS
Screen reader

Keyboard shortcuts: problem

Keyboard shortcuts: workaround

Keyboard shortcuts: solution?

Keyboard shortcuts: solution

Platform controls

Windows 10 bold checkbox
Focusable, Focused, Checked

Accessibility APIs

UI Automation (UIA)
MS Active Accessibility (MSAA)
IAccessible2 (IA2)
Mac OS
OSX Accessibility Protocol (AXAPI)
Accessibility Toolkit (ATK)
AT Service Provider Interface (AT-SPI)

Web controls

<label for="this">Bold</label>
< type="checkbox" id="this" checked>
Focusable, Focused, Checked

Accessibility mappings

Define how role, state, properties, and keyboard focus are handled in the browser

HTML mapping support

Browsers may support an element, but not accessibility support it

A browser may accessibility support an element, but a screen reader may not

DOM tree

DOM tree for

Accessibility tree

Acc tree for

Polyfill accessibility

Add accessibility semantics with ARIA

ARIA: don't use it

Use native HTML whenever possible

Native HTML


Screen reader demo: native HTML

ARIA: unless you need to

The <div> and <span> elements have neutral semantics

Missing semantics

<span id="button">Tequila!</span>

Keyboard demo: missing semantics

Tequila! button

Screen reader demo: missing semantics

With added semantics

<span id="button" role="button"

Screen reader demo: with added semantics

ARIA: don't break native semantics

<button role="heading"

Screen reader demo: broken semantics

ARIA: make it work with a keyboard

When you create custom components it's your responsibility to make it work with the keyboard

Supplement existing interaction

<a href="#here" id="button" role="button">Tequila!</a>

var button = document.getElementById('button');
button.addEventListener('keydown', function(event) {
    if (event.keyCode == 13) {

Provide all interaction

<span id="button" role="button" tabindex="0">Tequila!</span>

var button = document.getElementById('button');
button.addEventListener('click', doSomething, false);
button.addEventListener('keydown', function(event) {
    if (event.keyCode == 13 || event.keyCode == 32) {

Screen reader demo: provide all interaction

Keyboard intercept chain

Using the application role

<body role="application">...</body>

Removes the screen reader from the keyboard intercept chain

Roles that trigger applications mode

Many ARIA roles trigger applications mode automatically, including:

Application mode: tablist

<ul role="tablist">
  <li role="presentation">
      <a role="tab" href="#p1" aria-selected="true" aria-controls="p1">Blanco</a>
  <li role="presenttation">
    <a role="tab" href="p2" aria-selected="false">Reposado</a>

Screen reader demo: application mode with tablist

Screen reader demo: application mode with tablist and keyboard interaction

Accessibility Object Model (AOM)

JavaScript accessibility API for the future


You're only supposed to blow the bloody doors off!

Thank you