Disabilities, barriers and assistive technology

In WebAIM’s latest survey of screen reader users, 67.8 % said the first thing they do on a long page is move through its headings. A page without real headings takes that route away from two respondents in three before they have heard a word of it.

Each disability meets the web through different tools, and each tool depends on different parts of your code. You will be able to describe how blind, low-vision, Deaf, motor, cognitive and speech-disabled people use the web, match assistive technologyassistive technology: Software or hardware that disabled people use to perceive and operate computers and phones, such as screen readers, braille displays, magnifiers, switches and voice control. It works with what the browser exposes from a page. to what it needs from a page, and use survey and traffic data to choose the screen reader and browser pairs to test first, ending with a test matrix you can check.

Each disability meets the web through different tools

A blind reader moves through a page by headings and links, listening to a screen readerscreen reader: Software that reads out what is on the screen, or shows it on a braille display, and lets a person move through and operate a page from the keyboard or with touch gestures. NVDA, JAWS, VoiceOver and TalkBack are screen readers. or reading a refreshable braille displayrefreshable braille display: A device with rows of pins that rise and fall to form braille characters, showing a line of the text a screen reader sends to it. Blind and deafblind people read it by touch.. A reader with low vision enlarges the same page to 400 % and reads it one column at a time. A Deaf viewer follows its video through captions, and a person who cannot use their hands moves through it with a switch or with their voice.

W3C’s guide to how disabled people use the web groups abilities into five kinds: auditory, cognitive and learning, physical, speech and visual. It adds that people may develop impairments with age, and that some have more than one disability, such as “someone who is deaf and has low vision”, who may need captions they can resize (Diverse Abilities and Barriers). The table gives each group the tools and strategies W3C describes and the barrier that stops them first:

The right-hand column is the part a web team controls. Every entry in it is a decision in markup, style, script or content, which is why the same few failures lead large scans of the web such as WebAIM’s.

Assistive technology can only use what the page exposes

Assistive technology does not work from the source of a page. The browser turns your markup into a DOM, derives the accessibility treeaccessibility tree: The tree of objects a browser builds from the DOM for assistive technology: one node for each thing a person can perceive or operate, with its role, name, states and value. from that DOM, and gives every element a person could perceive or use a node with a role, a name and its current states. The operating system’s accessibility interface hands the tree on, and screen readers, braille displays, voice control and switch software all work from it. Follow one Send control along that path twice, once as a button element and once as an icon inside a div:

The second pass broke at the accessibility tree, and everything after it inherited the gap. The screen reader had no role or name to say; voice control found no control called Send. That second case has its own WCAG criterion, 2.5.3 Label in Name: when a control shows a text label, its name must contain that text, so that what a voice control user reads on screen is what they can say (WCAG 2.2). W3C’s guide gives the same advice in plain terms: button names in the code should match the text on screen, so a command such as “click send email” works (Tools and Techniques: Input).

Switch software works from the same tree. Android’s Switch Access moves through the items on the screen, “highlighting each item in turn, until you make a selection” (Android Switch Access help), so a person with one or two switches can reach everything the page exposes as operable, and nothing it does not.

Survey data shows which screen readers people use

One widely cited public source on screen reader use is WebAIM’s survey of screen reader users. Its eleventh edition collected 1,780 valid responses (WebAIM). For the screen reader respondents use most on a desktop or laptop, JAWS led with 55.0 %, then NVDA with 32.9 % and VoiceOver with 6.5 %. 91.8 % also used a screen reader on a phone or tablet, where 72.2 % named VoiceOver and 29.5 % TalkBack (respondents could name more than one). The pairs of screen reader and browser they used most often were these:

Two habits follow from the table. Test a screen reader and a browser together, because the browser builds the tree that the screen reader reads, and a page can work in one pair and fail in another. And read the survey for what it is: its own report warns that the sample “was not controlled”, so it may not stand for every screen reader user, and 54.1 % of respondents were in North America.

Where respondents live changes the order. In North America, 72.5 % used JAWS first and 15.6 % NVDA. In Europe the two were level, at 42.8 % and 42.3 %. In Asia NVDA led by 77.4 % to 17 %. NVDA is an open-source screen reader from NV Access (NV Access); VoiceOver is built into Apple’s systems (Apple), and TalkBack is the screen reader included on Android devices (TalkBack help).

Your audience’s traffic decides what to test first

The survey describes screen reader users who chose to answer it. Your analytics describe your own audience, but they cannot tell which visitors use assistive technology. A practical order of testing uses both: the audience’s traffic splits the effort between desktop and mobile and between Android and iPhone, and the survey splits the desktop share between its most common pairs, adjusted for the audience’s region. The program below does exactly that for two audiences, using only published shares:

// Which screen reader and browser pairs to test first, for two audiences. A heuristic, not a
// measurement: the audience's traffic splits the effort between desktop and mobile, and
// between Android and iPhone; the WebAIM Screen Reader User Survey #11 splits the desktop
// share between its most common pairs. Every number below is one of those published shares.

// Desktop pairs: % of survey respondents who use each pair.
const desktopPairs = [
  ['JAWS', 'Chrome', 31.2], ['NVDA', 'Chrome', 17.3], ['JAWS', 'Edge', 17.0],
  ['NVDA', 'Firefox', 9.1], ['NVDA', 'Edge', 5.4], ['JAWS', 'Firefox', 5.0],
  ['VoiceOver', 'Safari', 4.3], ['VoiceOver', 'Chrome', 1.6],
];
// Primary desktop screen reader, all respondents and respondents in Asia (%).
const primary = { all: { JAWS: 55.0, NVDA: 32.9 }, asia: { JAWS: 17, NVDA: 77.4 } };

// Traffic shares (%), from StatCounter: platforms, then mobile operating systems.
const audiences = [
  { name: 'Global audience', desktop: 39.26, mobile: 58.99, android: 69.17, ios: 30.81, region: 'all' },
  { name: 'India-first audience', desktop: 22.1, mobile: 77.3, android: 93.89, ios: 6.05, region: 'asia' },
];

function rank(a) {
  // Re-weight JAWS and NVDA by the audience's region; VoiceOver keeps its survey share.
  const scale = (reader) => (reader in primary.all ? primary[a.region][reader] / primary.all[reader] : 1);
  const scaled = desktopPairs.map(([reader, browser, share]) => [reader, browser, share * scale(reader)]);
  const total = scaled.reduce((sum, p) => sum + p[2], 0);
  const traffic = a.desktop + a.mobile;
  const rows = scaled.map(([reader, browser, share]) => [`${reader} + ${browser}`, 'desktop', (a.desktop / traffic) * (share / total)]);
  rows.push(['TalkBack + Chrome', 'Android', (a.mobile / traffic) * (a.android / (a.android + a.ios))]);
  rows.push(['VoiceOver + Safari', 'iPhone', (a.mobile / traffic) * (a.ios / (a.android + a.ios))]);
  return rows.sort((x, y) => y[2] - x[2]);
}

for (const a of audiences) {
  const rows = rank(a);
  console.log(`${a.name}: ${a.mobile} % mobile, ${a.android} % of it Android`);
  rows.slice(0, 6).forEach(([pair, device, weight], i) => {
    console.log(`  ${i + 1}. ${pair.padEnd(20)}${device.padEnd(9)}${(weight * 100).toFixed(1).padStart(5)} %`);
  });
  const covered = rows.slice(0, 6).reduce((sum, r) => sum + r[2], 0);
  console.log(`  The first six rows carry ${(covered * 100).toFixed(1)} % of the weight.`);
  console.log('');
}

Global audience: 58.99 % mobile, 69.17 % of it Android
  1. TalkBack + Chrome   Android   41.5 %
  2. VoiceOver + Safari  iPhone    18.5 %
  3. JAWS + Chrome       desktop   13.7 %
  4. NVDA + Chrome       desktop    7.6 %
  5. JAWS + Edge         desktop    7.5 %
  6. NVDA + Firefox      desktop    4.0 %
  The first six rows carry 92.8 % of the weight.

India-first audience: 77.3 % mobile, 93.89 % of it Android
  1. TalkBack + Chrome   Android   73.1 %
  2. NVDA + Chrome       desktop    9.3 %
  3. NVDA + Firefox      desktop    4.9 %
  4. VoiceOver + Safari  iPhone     4.7 %
  5. NVDA + Edge         desktop    2.9 %
  6. JAWS + Chrome       desktop    2.2 %
  The first six rows carry 97.1 % of the weight.

For a global audience, the first row is TalkBack with Chrome at 41.5 % of the weight, because most mobile traffic in the world runs on Android, and VoiceOver with Safari on an iPhone comes second at 18.5 %. Keep both mobile pairs near the top even when your traffic leans one way: among survey respondents, 72.2 % used VoiceOver on mobile. JAWS with Chrome is the first desktop row, and the first six rows carry 92.8 % of the weight. Tablets are left out, as a small share of traffic.

The weights are a starting order, not a measurement of anyone’s users. Replace the audience’s shares with your own analytics and run it again.

A test matrix turns that order into rows a tester can follow, and each row records the screen reader, the browser and the operating system, each with its version, and the device. Screen readers and browsers change with every release, so a result recorded without versions cannot be repeated or compared later.

Practise: check a draft test matrix

The exercise gives you a draft matrix to check before testing starts: versions on every row, no pair twice, both desktop and mobile covered, and a mobile row first for a mobile-first audience. Its sample tests run in your browser:

/** True when s is a string with something other than spaces in it. */
function filled(s) {
  return typeof s === 'string' && s.trim() !== '';
}

/** The problems of a draft test matrix: 'versions:i', 'duplicate:i', 'no-desktop', 'no-mobile', 'mobile-first'. */
export function matrixProblems(matrix, audience) {
  const problems = [];
  matrix.forEach((row, i) => {
    if (!filled(row.readerVersion) || !filled(row.browserVersion) || !filled(row.osVersion)) problems.push(`versions:${i}`);
    // Add the duplicate check here.
  });
  // Add the platform checks and the mobile-first check here.
  return problems;
}

import { test, assert } from 'mysmartcopilot:test';
import { matrixProblems } from './matrix.mjs';

// A row with every field filled in; each test changes what it needs.
const row = (reader, browser, os, platform, extra = {}) => ({
  reader, browser, os, platform, readerVersion: '1.0', browserVersion: '2.0', osVersion: '3.0', ...extra,
});

// The lesson's first six rows for an India-first audience.
const indiaFirst = [
  row('TalkBack', 'Chrome', 'Android', 'mobile'),
  row('NVDA', 'Chrome', 'Windows', 'desktop'),
  row('NVDA', 'Firefox', 'Windows', 'desktop'),
  row('VoiceOver', 'Safari', 'iOS', 'mobile'),
  row('NVDA', 'Edge', 'Windows', 'desktop'),
  row('JAWS', 'Chrome', 'Windows', 'desktop'),
];

test('the lesson matrix for a mobile-first audience has no problems', () => {
  assert.deepEqual(matrixProblems(indiaFirst, { mobile: 77.3 }), []);
});

test('a row without one of its versions is reported by its index', () => {
  const m = [row('TalkBack', 'Chrome', 'Android', 'mobile'), row('NVDA', 'Chrome', 'Windows', 'desktop', { browserVersion: '  ' })];
  assert.deepEqual(matrixProblems(m, { mobile: 60 }), ['versions:1']);
});

test('a pair on the same operating system is a duplicate the second time', () => {
  const m = [row('NVDA', 'Chrome', 'Windows', 'desktop'), row('TalkBack', 'Chrome', 'Android', 'mobile'), row('NVDA', 'Chrome', 'Windows', 'desktop')];
  assert.deepEqual(matrixProblems(m, { mobile: 30 }), ['duplicate:2']);
});

test('the same pair on another operating system is not a duplicate', () => {
  const m = [row('VoiceOver', 'Safari', 'macOS', 'desktop'), row('VoiceOver', 'Safari', 'iOS', 'mobile')];
  assert.deepEqual(matrixProblems(m, { mobile: 30 }), []);
});

test('a matrix needs a desktop row and a mobile row', () => {
  assert.deepEqual(matrixProblems([row('JAWS', 'Chrome', 'Windows', 'desktop')], { mobile: 10 }), ['no-mobile']);
  assert.deepEqual(matrixProblems([row('TalkBack', 'Chrome', 'Android', 'mobile')], { mobile: 90 }), ['no-desktop']);
});

test('from 50 % mobile traffic, the first row is a mobile row', () => {
  const desktopFirst = [row('JAWS', 'Chrome', 'Windows', 'desktop'), row('TalkBack', 'Chrome', 'Android', 'mobile')];
  assert.deepEqual(matrixProblems(desktopFirst, { mobile: 50 }), ['mobile-first']);
  assert.deepEqual(matrixProblems(desktopFirst, { mobile: 49.9 }), []);
});

test('problems come in the order of the rules', () => {
  const m = [row('JAWS', 'Chrome', 'Windows', 'desktop', { osVersion: '' }), row('JAWS', 'Chrome', 'Windows', 'desktop', { readerVersion: undefined })];
  assert.deepEqual(matrixProblems(m, { mobile: 80 }), ['versions:0', 'versions:1', 'duplicate:1', 'no-mobile', 'mobile-first']);
});

test('an empty matrix covers neither platform and has no first row', () => {
  assert.deepEqual(matrixProblems([], { mobile: 80 }), ['no-desktop', 'no-mobile']);
});

Then test yourself on the four ideas of this lesson, from who uses which tool to the order of testing:

Interview questions

Fresher · What is assistive technology? Name three kinds and what each needs from a page.

Assistive technology is software or hardware that disabled people use to perceive and operate a computer or phone. A screen reader, such as NVDA, JAWS, VoiceOver or TalkBack, reads the screen aloud or shows it in braille; it needs real structure, such as headings, and a name and a role on every control. Voice control lets a person say “click Send”; it needs each control’s name to contain the text the control shows. Switch access lets a person with one or two switches move a highlight through the page; it needs every action to be reachable as a control, not hidden behind a mouse gesture. None of them can repair a page: they present only what the browser exposes from the markup.

Two harder questions of this module start from this lesson’s figures:

Key takeaways

• Blind, low-vision, Deaf, motor, cognitive and speech-disabled people use different tools, and each group is stopped first by a different decision in the markup, the style, the script or the content.
• Assistive technology works from the accessibility tree that the browser builds from your markup; a missing role or name breaks screen readers, voice control and switches alike.
• WebAIM’s survey puts JAWS and NVDA first on desktop and VoiceOver first on mobile, with large regional differences and a sample that is not controlled.
• Test pairs, not products: your audience’s traffic decides between desktop and mobile, and between Android and iPhone, and the survey orders the desktop pairs.
• A test matrix records the screen reader, browser and operating system with their versions, or its results cannot be repeated.