Accessibility Mental Model and WCAG

Accessibility Is Not a Feature

Here's a stat that should reframe how you think about the web: over 1.3 billion people worldwide live with some form of disability. That's roughly 16% of the global population, according to the World Health Organization. If you're building a website that isn't accessible, you're telling one in six humans they aren't welcome.

But accessibility isn't just about permanent disabilities. It's about the developer with a broken arm who can't use a mouse for six weeks. The parent holding a baby while trying to read on their phone. The commuter in bright sunlight who can't see low-contrast text. The person in a noisy coffee shop relying on captions.

Accessibility is a spectrum, not a binary. And here's the thing most people miss: making products accessible makes them better for everyone.

The Business Case You Can't Ignore

Let's be honest — sometimes "it's the right thing to do" isn't enough to get accessibility prioritized on a roadmap. So let's talk business:

• Legal compliance — The European Accessibility Act (effective June 2025), ADA in the US, EN 301 549 in the EU, and similar laws worldwide are making accessibility a legal requirement. Lawsuits against inaccessible websites have skyrocketed: over 4,000 federal ADA-related digital lawsuits were filed in the US in 2023 alone.
• SEO benefits — Search engines are essentially blind users. Semantic HTML, proper heading hierarchies, descriptive alt text, clear link text, and structured content all improve your search rankings because they help bots understand your content the same way they help screen readers.
• Market reach — The spending power of people with disabilities (and their families) is estimated at $13 trillion globally. An inaccessible checkout is a broken checkout — for a massive market.
• Better engineering — Accessible code is well-structured code. Semantic HTML, logical tab order, clear component boundaries, and explicit state management are all things that make your codebase more maintainable and testable.

The Disability Spectrum

Most developers picture accessibility as "making things work for blind people." That's a fraction of the picture. Disabilities span four broad categories, and each one is a spectrum from permanent to temporary to situational:

Visual

• Permanent: Blindness, low vision, color blindness (8% of men, 0.5% of women)
• Temporary: Eye surgery recovery, dilated pupils, eye infection
• Situational: Bright sunlight on screen, using a projector in a lit room

Assistive technologies: Screen readers (VoiceOver, NVDA, JAWS), screen magnifiers (ZoomText), high-contrast modes, custom stylesheets

Motor / Physical

• Permanent: Paralysis, cerebral palsy, repetitive strain injury, missing limbs
• Temporary: Broken arm, wrist surgery, holding a baby
• Situational: Using a device on a bumpy train, wearing thick gloves

Assistive technologies: Switch devices, eye tracking, voice control (Dragon NaturallySpeaking), sip-and-puff devices, head pointers, keyboard-only navigation

Auditory

• Permanent: Deafness, hard of hearing
• Temporary: Ear infection, noise-induced hearing loss
• Situational: Noisy environment, quiet library, no headphones available

Assistive technologies: Captions, transcripts, visual alerts, hearing loop compatibility

Cognitive / Neurological

• Permanent: Dyslexia, ADHD, autism, intellectual disabilities, memory impairments
• Temporary: Concussion, medication side effects, sleep deprivation
• Situational: Distraction, multitasking, unfamiliar language, stress

Assistive technologies: Reading tools, simplified interfaces, text-to-speech, predictable navigation, plain language

WCAG: The Framework That Organizes Everything

The Web Content Accessibility Guidelines (WCAG) is the international standard for web accessibility, published by the W3C's Web Accessibility Initiative (WAI). The current versions are WCAG 2.1 (2018) and WCAG 2.2 (2023), with WCAG 3.0 in early draft.

WCAG is built on four principles, remembered by the acronym POUR. Every single guideline and success criterion traces back to one of these four.

Perceivable — Can You Sense It?

Content must be presented in ways users can perceive. This principle covers:

• Text alternatives — Every non-text element (images, icons, charts) needs a text equivalent. A screen reader can't describe an image it doesn't have alt text for.
• Time-based media — Videos need captions. Audio content needs transcripts. Live events need real-time captions.
• Adaptable content — Structure must be conveyed through semantics (headings, lists, tables), not just visual styling. A bold paragraph that looks like a heading but is just a styled div is invisible to screen readers.
• Distinguishable — Sufficient color contrast (4.5:1 for normal text, 3:1 for large text), text resizable to 200% without breaking layout, no information conveyed by color alone.

Operable — Can You Use It?

Every piece of functionality must be available to all input methods:

• Keyboard accessible — All functionality reachable and operable via keyboard. No keyboard traps (where you can get into a component but can't tab out). This is the single most impactful thing you can test.
• Enough time — If there's a time limit, users must be able to extend or turn it off. Not everyone reads, processes, or types at the same speed.
• Seizures and physical reactions — Nothing should flash more than 3 times per second. No auto-playing animations without a way to pause them.
• Navigable — Clear page titles, logical focus order, visible focus indicators, skip navigation links, multiple ways to find content (search, sitemap, navigation).
• Input modalities — Touch targets of at least 24x24 CSS pixels (WCAG 2.2), dragging operations must have non-drag alternatives.

Understandable — Can You Make Sense of It?

Content and interface behavior must be comprehensible:

• Readable — Language is specified in HTML (lang attribute), unusual words are defined, reading level is appropriate for the audience.
• Predictable — Navigation is consistent across pages. Components that look the same behave the same. No unexpected context changes (like auto-submitting a form when a dropdown changes).
• Input assistance — Errors are described in text (not just red borders). Labels are associated with inputs. Required fields are marked. Suggestions help users fix errors.

Robust — Can Technology Parse It?

Content must be interpretable by assistive technologies:

• Compatible — Valid HTML (proper nesting, unique IDs, correct attribute usage). ARIA roles, states, and properties used correctly. Custom components expose their name, role, and state to the accessibility tree.
• Status messages — Dynamic content changes (like "Item added to cart" or form validation messages) are communicated to screen readers via ARIA live regions.

Conformance Levels: A, AA, AAA

Every WCAG success criterion is assigned a conformance level:

The industry standard is AA. This is what laws like the European Accessibility Act reference. It's what VPAT (Voluntary Product Accessibility Template) evaluations target. When someone says "our product is WCAG compliant," they almost always mean AA.

AAA conformance across an entire site is extremely difficult and often impractical (some criteria conflict with certain types of content). But individual AAA criteria — like enhanced contrast or extended audio descriptions — are absolutely worth pursuing where they make sense.

The Accessibility Tree — How Assistive Tech Sees Your Page

Browsers build a visual render tree for sighted users. In parallel, they also build an accessibility tree — a simplified version of the DOM that assistive technologies interact with. Every node in the accessibility tree has:

• Name — What is this element called? (button label, heading text, alt text)
• Role — What type of element is this? (button, heading, navigation, link)
• State — What's its current condition? (checked, expanded, disabled, selected)
• Value — What's its current value? (text input content, slider position)

When you use semantic HTML, the browser populates the accessibility tree automatically. A <button> gets the role "button" for free. An <h2> is announced as "heading level 2." A <nav> becomes a navigation landmark.

When you use <div onclick="..."> instead of <button>, the accessibility tree sees a generic element with no role, no keyboard support, and no name. To a screen reader user, it doesn't exist as an interactive element.

<!-- Good: Accessibility tree gets role, name, and keyboard support for free -->
<button>Save changes</button>

<!-- Bad: Accessibility tree sees a generic text container -->
<div onclick="save()">Save changes</div>

<!-- Attempting to fix the div (don't do this — just use button) -->
<div role="button" tabindex="0" onclick="save()"
     onkeydown="if(event.key==='Enter'||event.key===' ')save()">
  Save changes
</div>

The third example requires you to manually add the role, keyboard focus, and keyboard event handling that <button> gives you for free. It's more code, more fragile, and more likely to have bugs. Semantic HTML is the first and most powerful accessibility tool.

The Curb-Cut Effect in Practice

The curb-cut metaphor isn't just nice — it's a proven pattern throughout web development. Every major accessibility feature has ended up benefiting the broader user base:

• Captions were designed for deaf users. Today, 80%+ of caption users are hearing people watching in noisy or quiet environments.
• Voice control was designed for motor-impaired users. Now everyone uses Siri, Alexa, and Google Assistant daily.
• Keyboard navigation was designed for users who can't use a mouse. Power users, developers, and anyone with RSI rely on it for speed and comfort.
• High contrast was designed for low-vision users. It helps everyone in bright sunlight, on cheap monitors, or when projecting in a lit room.
• Clear link text was designed for screen reader users who navigate by links. It also improves SEO and helps sighted users scan pages faster.
• Simple language was designed for cognitive disabilities. It helps non-native speakers, tired users, and anyone under cognitive load (which is all of us, sometimes).

This is why framing accessibility as "extra work for edge cases" is fundamentally wrong. It's design work that lifts the floor for everyone.

Accessibility Is a Spectrum, Not a Checklist

Here's the mental model shift that separates good developers from great ones: accessibility is not a box you check. It's a continuous spectrum of how many people can use your product and how well.

Running an automated accessibility checker (like axe or Lighthouse) and getting a score of 100 does not mean your site is accessible. Automated tools catch roughly 30-40% of accessibility issues. They can detect missing alt text, insufficient contrast ratios, and missing form labels. They cannot detect:

• Whether alt text is actually descriptive (they just check it exists)
• Whether keyboard focus order is logical (they just check elements are focusable)
• Whether custom components are usable with assistive tech (they check ARIA syntax, not semantics)
• Whether the user experience makes sense when you can't see the screen
• Whether animations cause motion sickness for vestibular disorder users
• Whether cognitive load is appropriate for the audience

Manual testing — actually using your site with a keyboard, a screen reader, and at 200% zoom — is irreplaceable. Automated tools are a starting point, not a finish line.

What's Next

You now have the mental model: accessibility is a spectrum that benefits everyone, WCAG organizes it through POUR, and conformance levels set the bar. The rest of this module puts these principles into practice — semantic HTML patterns, keyboard interaction, ARIA usage, focus management, and testing with real assistive technologies.

The best time to think about accessibility is before you write the first line of code. The second best time is now.