What web accessibility is and why it matters

In a scan of the top one million home pages, 95.9 % failed at least one check of the Web Content Accessibility GuidelinesWCAG: The Web Content Accessibility Guidelines: W3C's standard for accessible web content, made of testable success criteria at levels A, AA and AAA. WCAG 2.2 is the current version and is also published as ISO/IEC 40500. More in “WCAG 2.2 structure, levels and conformance” that software can run, with 56.1 errors on an average page. Each error is a place where a person who is blind, Deaf, has a tremor or reads slowly can get stuck: a photo with no description, a field with no label, text too faint to read.

You will be able to say what web accessibility is and how it differs from usability and inclusion, explain why the barrier sits in the design rather than in the person, sort barriers into permanent, temporary and situational, and read the headline numbers on disability and on the web without claiming more than they show. One small product page, used five different ways, carries the ideas.

Accessibility means disabled people can use the whole site

Picture a bus-ticket site. A blind traveller who uses 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. More in “Disabilities, barriers and assistive technology” can search for buses but cannot choose a seat, because the seat map is a grid of unlabelled squares. A Deaf traveller cannot follow the video that explains refunds. A traveller with a tremor keeps hitting the wrong day in a calendar of tiny cells. Each of them can use part of the site, and none of them can buy a ticket.

W3C’s Web Accessibility Initiative describes web accessibility as websites, tools and technologies designed and built so that people with disabilities can use them: they can “perceive, understand, navigate, and interact with the Web”, and they can “contribute to the Web” (Introduction to Web Accessibility). The last verb matters. Accessibility covers posting a review, uploading a document and filling in a form, not only reading. It also covers the whole task: a site where a screen reader user can read every page but cannot pay is not accessible, however many of its pages pass a check.

Two neighbouring ideas are often mixed up with accessibility. W3C keeps them apart, and so should a team, because each asks a different question and is judged against different people (Accessibility, Usability, and Inclusion):

The rows overlap. W3C notes a “significant overlap between accessibility and usability”, and much of what helps disabled people makes a site easier for everyone. The overlap is not complete, though: W3C also warns that usability work “often does not sufficiently address the needs of people with disabilities”. A checkout that ten sighted testers finish in a minute can still be impossible with a keyboard. Inclusion is the widest of the three, and accessibility is the part of it with a testable standard: WCAG 2.2, which is also the international standard ISO/IEC 40500.

The barrier is in the design, not in the person

Two ways of thinking about disability lead to two different to-do lists. The medical modelmedical model of disability: A view of disability as a problem in a person's body or mind, to be diagnosed and treated. It describes the person, so it suggests nothing that a website team could change. treats disability as a problem in a person’s body or mind, to be diagnosed and, where possible, treated; for a website it suggests nothing to fix. The social modelsocial model of disability: A view of disability as the result of barriers in the world around a person, such as a staircase or an unlabelled button, rather than of the impairment alone, so removing the barrier is the fix. puts the disability in the gap between a person and the world built around them: a staircase disables a wheelchair user, and an unlabelled button disables a screen reader user. The World Health Organization’s own description sits close to the social model: disability comes from “the interaction between health conditions” and a person’s surroundings and circumstances (WHO).

Web teams work from the social model because it turns a complaint into a bug. Follow one customer through a payment twice. Watch which item on the stage changes between the attempt that fails and the one that works:

Between the fourth step and the seventh, nothing about the customer changed: the same person, the same skills, the same screen reader. Only the page did. That is the practical meaning of the social model. Every barrier has a place in the code or the design, an owner and a fix, and WCAG is written the same way: its success criteria describe properties of content, such as a button having a name and a role, never properties of people.

The same idea works for a whole page. The program below models one product page as the design decisions that matter, then checks it the way five groups of people use the web: by keyboard alone, with a screen reader, zoomed to 400 %, without telling red from green, and without sound. It is a model, not a browser: each part of the page records only the decision its check reads.

// One product page, five ways of using it. The page is a model: each part records only
// the design decision that a way of using it depends on. The checks list every barrier
// the page puts in a person's way, then run again on the same page after six fixes.

const before = {
  photo: { alt: null }, // an <img> without an alt attribute
  size: { name: null }, // a <select> with no label
  pay: { element: 'div', focusable: false }, // a div with a click handler
  required: { shownBy: ['colour'] }, // required fields marked in red only
  layout: { minWidth: 1280 }, // the narrowest width the layout fits, in CSS px
  video: { captions: false }, // a product video with speech
};

const after = {
  photo: { alt: 'Steel water bottle, 750 ml, matt blue' },
  size: { name: 'Size' },
  pay: { element: 'button', focusable: true },
  required: { shownBy: ['colour', 'text'] },
  layout: { minWidth: 320 },
  video: { captions: true },
};

// A way of using the page, and what fails it: [part, WCAG criterion, what happens].
const ways = [
  ['Keyboard only', (p) => [!p.pay.focusable && ['pay', '2.1.1', 'Tab never reaches "Pay now"']]],
  ['Screen reader', (p) => [
    p.photo.alt === null && ['photo', '1.1.1', 'the photo has no text alternative'],
    p.size.name === null && ['size', '4.1.2', 'the size list has no name'],
    p.pay.element !== 'button' && ['pay', '4.1.2', '"Pay now" is read as text, not a button'],
  ]],
  ['Zoom to 400 %', (p) => [p.layout.minWidth > 320 && ['layout', '1.4.10', `the page needs ${p.layout.minWidth} px, so it scrolls sideways`]]],
  ['Red looks like green', (p) => [!p.required.shownBy.includes('text') && ['required', '1.4.1', 'required fields are marked by colour alone']]],
  ['No sound', (p) => [!p.video.captions && ['video', '1.2.2', 'the video has no captions']]],
];

function tour(label, page) {
  console.log(label);
  let barriers = 0;
  const blocked = new Set();
  for (const [way, check] of ways) {
    for (const found of check(page).filter(Boolean)) {
      const [part, sc, what] = found;
      console.log(`  ${way.padEnd(21)}${part.padEnd(10)}${sc.padEnd(8)}${what}`);
      barriers += 1;
      blocked.add(way);
    }
  }
  console.log(`  ${barriers} barrier${barriers === 1 ? '' : 's'}, in ${blocked.size} of ${ways.length} ways of using the page`);
  console.log('');
}

tour('Before the fixes', before);
tour('After the fixes', after);

Before the fixes
  Keyboard only        pay       2.1.1   Tab never reaches "Pay now"
  Screen reader        photo     1.1.1   the photo has no text alternative
  Screen reader        size      4.1.2   the size list has no name
  Screen reader        pay       4.1.2   "Pay now" is read as text, not a button
  Zoom to 400 %        layout    1.4.10  the page needs 1280 px, so it scrolls sideways
  Red looks like green required  1.4.1   required fields are marked by colour alone
  No sound             video     1.2.2   the video has no captions
  7 barriers, in 5 of 5 ways of using the page

After the fixes
  0 barriers, in 0 of 5 ways of using the page

Seven barriers, and every one of the five ways of using the page meets at least one of them. The fixes are ordinary work: an alt attribute, a label, a button element, the word “required” next to the red marker, a layout that can narrow, and a captions file. After them the same five checks find nothing.

Each barrier belongs to one decision, so each one can be found, assigned and fixed like any other defect.

Barriers can last a lifetime, a few weeks or a few minutes

The tiny “x” that closes a pop-up is hard to hit for a person with a tremor, for someone whose wrist is in a cast, and for anyone tapping it on a moving bus. The barrier is the same in all three cases. How long the person meets it is not:

• Permanent: a long-term impairment, such as blindness, deafness, a limb difference or a learning disability. The person meets the barrier on every visit.
• Temporary: an impairment that passes. W3C gives accidents, surgery and medication as causes of temporary impairments (Diverse Abilities and Barriers): a broken arm, eyes dilated after an eye test, a concussion.
• Situational: a situational limitationsituational limitation: A constraint that comes from a person's surroundings or circumstances rather than from an impairment, such as glare, a noisy place or a moving vehicle. It ends when the situation does. comes from the surroundings or the circumstances, such as noise, glare from the sun or the cost of mobile data.

The table puts one example of each against four kinds of ability. Read a row across: the need stays the same while its cause and its length change.

Two cautions keep this honest. First, a situational limitation is not a disability. The person on the bus can get off; the person with a tremor cannot, and WCAG’s requirements exist for the second. Second, the overlap is a bonus, not the reason. W3C lists people using small screens, older people and people on slow connections among those who also gain from accessible design, but a design is accessible when disabled people can use it, whoever else benefits.

Headline numbers measure different things

Accessibility arguments lean on two kinds of number: how many people have a disability, and how much of the web fails them. Both are easy to quote and easy to stretch, so look at what each one actually counted.

The World Health Organization estimates that 1.3 billion people, 16 % of the world’s population, “experience a significant disability” (WHO). It is an estimate of significant disability across the world, not a count of anyone’s users, and it says nothing about how many of those people visit a particular website. Analytics cannot fill the gap either, because browsers do not tell a website which assistive technology a visitor uses.

For the state of the web, WebAIM runs software checks on the home pages of the top one million websites. The program below lays out its results for the six most common kinds of failure, adds the WCAG criterion each one fails and who it stops first, and works out three numbers that the published summary implies:

// The six most common failure types in the WebAIM Million: the top 1,000,000 home pages,
// scanned by software. Each row: the type, the share of home pages that had it, the
// WCAG criterion that axe-core 4.13.0 tags its matching rule with (its rule for empty
// links carries 4.1.2 as well), and who it stops first.
const types = [
  ['Low contrast text', 83.9, '1.4.3', 'people with low vision'],
  ['Images without alternative text', 53.1, '1.1.1', 'screen reader users'],
  ['Form fields without labels', 51.0, '4.1.2', 'screen reader and voice users'],
  ['Empty links', 46.3, '2.4.4', 'screen reader users'],
  ['Empty buttons', 30.6, '4.1.2', 'screen reader and voice users'],
  ['No document language', 13.5, '3.1.1', 'screen reader users'],
];
const pages = 1000000;
const failingShare = 95.9; // % of home pages with at least one detected failure
const errorsPerPage = 56.1; // detected errors on an average home page
const sixTypesShare = 96; // % of all detected errors that are one of the six types

console.log('Failure type                      Pages   WCAG   Stops first');
for (const [type, share, sc, who] of types) {
  console.log(`${type.padEnd(34)}${share.toFixed(1).padStart(5)} %  ${sc.padEnd(7)}${who}`);
}

// 41000 -> "41,000" (written out, so the program prints the same everywhere).
const grouped = (n) => String(n).replace(/\B(?=(\d{3})+(?!\d))/g, ',');

const shares = types.reduce((sum, t) => sum + t[1], 0);
const clean = 100 - failingShare;
console.log('');
console.log(`The six shares add up to ${shares.toFixed(1)} % of home pages, more than the ${failingShare} % that fail:`);
console.log(`a failing home page has ${(shares / failingShare).toFixed(1)} of the six types on average.`);
console.log(`Errors per page: ${errorsPerPage}, of which ${(errorsPerPage * sixTypesShare / 100).toFixed(1)} are one of the six types.`);
console.log(`Home pages with no detected failure: ${clean.toFixed(1)} %, about ${grouped(Math.round(pages * clean / 100))} of ${grouped(pages)}.`);
console.log('A scan finds only some kinds of failure, so fewer pages than that conform.');

Failure type                      Pages   WCAG   Stops first
Low contrast text                  83.9 %  1.4.3  people with low vision
Images without alternative text    53.1 %  1.1.1  screen reader users
Form fields without labels         51.0 %  4.1.2  screen reader and voice users
Empty links                        46.3 %  2.4.4  screen reader users
Empty buttons                      30.6 %  4.1.2  screen reader and voice users
No document language               13.5 %  3.1.1  screen reader users

The six shares add up to 278.4 % of home pages, more than the 95.9 % that fail:
a failing home page has 2.9 of the six types on average.
Errors per page: 56.1, of which 53.9 are one of the six types.
Home pages with no detected failure: 4.1 %, about 41,000 of 1,000,000.
A scan finds only some kinds of failure, so fewer pages than that conform.

Read the last two lines first. 4.1 % of home pages had no failure the software could find, and WebAIM itself says that full conformance is “certainly lower than 4.1%”, because “not all conformance failures can be automatically detected” (WebAIM). The scan covers home pages only, and it cannot say how many people each failure stopped. What it does show is that most failures are the same few, that a failing page has nearly three of them at once, and that five of the six are fixed by adding a missing attribute or a missing word.

Three habits keep claims honest:

• Quote what was measured: “detected failures on home pages”, not “inaccessible websites”.
• Never present a clean automated scan as proof that a page is accessible.
• Claim a benefit only where there is evidence for it. Accessible design helps many people, but it is no promise of better search rankings.

Practise: the four ideas

Ten questions cover the lesson, from the definition to the WebAIM figures. Each one picks the idea where your record is thinnest, and a right answer brings a harder question on that idea next time:

Interview questions

Fresher · What is web accessibility, and how is it different from usability?

Web accessibility means that people with disabilities can use a website or app as fully as anyone else: perceive its content, understand it, navigate it, operate its controls and contribute, by posting, uploading or filling in forms. Usability asks whether a product is effective, efficient and satisfying for the users it was designed for, and those users are often assumed to have no disability. The two overlap a lot, but a usable site can still be inaccessible: a checkout that most testers finish quickly may have a pay button that no keyboard can reach. Accessibility is judged against the needs of disabled people, and it has a testable standard, WCAG 2.2, also published as ISO/IEC 40500.

Fresher · What is the social model of disability, and why does it matter to a web team?

The medical model sees disability as a problem in a person’s body, to be treated. The social model sees it in the gap between a person and the world built around them: an unlabelled button disables a screen reader user the way a staircase disables a wheelchair user. For a web team, the social model turns a complaint into a defect with a place in the code, an owner and a fix. WCAG is written the same way: every success criterion describes something about the content, such as a button having a name and a role, never something about the user. So the question is never what is wrong with the user, but what in the page stops them.

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

Key takeaways

• Web accessibility means disabled people can perceive, understand, navigate, interact with and contribute to a site, across whole tasks; it overlaps with usability and inclusion but is judged against disabled people’s needs.
• The social model places the barrier in the design: change the page, and the same person with the same assistive technology gets through.
• Barriers can be permanent, temporary or situational, but WCAG’s requirements exist for disabled people, who cannot step out of the situation.
• WHO’s 16 % is a global estimate of significant disability; a national census measures something else, and neither tells you how many of your users are disabled.
• WebAIM found detected failures on 95.9 % of the top million home pages; a clean scan shows only that software found nothing, never that a page is accessible.