Why Accessibility Matters & The Legal/Ethical Landscape

Web Accessibility — Why Accessibility Matters & The Legal/Ethical Landscape
Web Accessibility (a11y)
Chapter 1 · Why Accessibility Matters & The Legal/Ethical Landscape

♿ Why Accessibility Matters & The Legal/Ethical Landscape

Accessibility isn't a "nice to have" layered on afterward — roughly 1 in 6 people worldwide has some form of disability. Excluding them from a product's usability is both an ethical failure and, increasingly, a real legal liability. This chapter sets the foundation everything else in the course builds on.

WCAG: The Web Content Accessibility Guidelines

WCAG is the standard everything in this course maps back to — currently at version 2.1/2.2, organized into three conformance levels:

LevelWhat It Means
AMinimum — a baseline, rarely sufficient on its own
AAThe common legal/practical target — most laws and standards reference this level
AAAHighest — often impractical to apply site-wide, used selectively

The POUR Principles

WCAG organizes around four pillars — every technique in this course maps to one of these:

Perceivable

Content must be presentable in ways every user can perceive — alt text for images, captions for video, sufficient color contrast.

Operable

Interface components must be usable by everyone — full keyboard support, no interactions that require precise timing or fine motor control.

Understandable

Content and operation must be comprehensible — clear labels, predictable navigation, helpful error messages.

Robust

Content must work reliably across current and future tools — valid, semantic markup that assistive technology can correctly interpret.

⚖️ The Legal Landscape

StandardScope
ADA (Americans with Disabilities Act)Applied to websites via US court precedent — the source of most inaccessible-website lawsuits
Section 508Required for US federal agencies and their contractors
EN 301 549The EU's accessibility standard, referencing WCAG directly

Lawsuits over inaccessible websites are a real, growing legal risk — not a hypothetical concern reserved for large enterprises.

Who These Techniques Actually Serve

Grounding the "why" behind specific techniques covered later: visual disabilities (blind, low-vision, color-blind) motivate screen reader support and contrast requirements; motor/mobility disabilities motivate full keyboard support; auditory disabilities motivate captions; cognitive disabilities motivate clear, predictable, jargon-free interfaces.

What Inaccessibility Actually Feels Like

Inaccessible

A screen reader user hits an unlabeled button and hears only "button" — no idea what it does. A keyboard user tabs into a dropdown and can't tab back out.

Accessible

Every control has a clear, spoken label. Every interactive element can be reached, operated, and exited using only a keyboard.

🛠️ Tooling Overview

Automated Scanners

axe DevTools (browser extension) and Lighthouse's accessibility audit both flag common, mechanically-detectable issues quickly.

Manual Testing

Keyboard-only navigation and real screen reader spot-checks (Chapter 7) — irreplaceable for the issues automated tools structurally can't catch.

💻 Coding Challenges

Challenge 1: Map Techniques to POUR

For each of (a) adding alt text to images, (b) ensuring a modal can be closed with the Escape key, and (c) writing clear, jargon-free error messages, identify which POUR principle it primarily addresses.

Goal: Practice connecting concrete techniques back to the four pillars they serve.

→ Solution

Challenge 2: Identify the Affected User Group

A site relies entirely on color (red vs green) to indicate form field errors, with no icon or text label. Identify which disability category this most directly excludes, and explain why.

Goal: Practice reasoning from a specific design choice back to who it actually harms.

→ Solution

Challenge 3: Choose a Conformance Target

A company is setting an internal accessibility standard for its public-facing website. Recommend WCAG level A, AA, or AAA as the target, and justify the choice using this chapter's conformance-level table.

Goal: Practice choosing a realistic, defensible standard rather than defaulting to the "best" one.

→ Solution

⚠️ Gotcha: Trusting Automated Scans Alone

Automated tools like axe and Lighthouse typically catch only around 30–40% of real accessibility issues — problems like confusing focus order, unclear link text ("click here"), or an illogical reading order require actual human judgment to catch, since a scanner has no way to evaluate whether something genuinely makes sense to a real user. Passing an automated scan with zero flagged issues is not the same as a page actually being accessible — treating a clean automated report as "done" is one of the most common, and most damaging, false senses of completion in this field.

🎯 What's Next

With the landscape and principles established, the next chapter goes hands-on: Semantic HTML as the Foundation — why div-soup breaks accessibility, and the semantic elements that fix it.