Accessibility Fundamentals

Accessibility (often abbreviated as a11y) is the practice of making digital products usable by everyone, including people with disabilities. As a tester, your role is to verify that applications work for all users, regardless of how they interact with technology.

Why Accessibility Matters

Over 1 billion people worldwide live with some form of disability. That is roughly 15% of the global population. When software is not accessible, these users are excluded.

The Business Case

Accessibility is not just the right thing to do -- it makes business sense:

• Legal compliance -- ADA, Section 508, European Accessibility Act
• Larger audience -- 15% of potential users have disabilities
• Better SEO -- Accessible sites rank higher in search results
• Improved UX -- Accessible design benefits everyone (curb-cut effect)

The POUR Principles

The Web Content Accessibility Guidelines (WCAG) are built on four principles known as POUR:

Perceivable

Users must be able to perceive the information presented.

Operable

Users must be able to operate the interface.

Understandable

Content and interface behavior must be understandable.

Robust

Content must be compatible with current and future assistive technologies.

Types of Disabilities to Consider

Visual Impairments

Testing considerations:
- Screen reader compatibility (VoiceOver, NVDA, JAWS)
- Sufficient color contrast (4.5:1 for normal text, 3:1 for large text)
- Resizable text up to 200% without loss of functionality
- No information conveyed by color alone

Motor Impairments

Testing considerations:
- Full keyboard navigation (Tab, Enter, Space, Arrow keys, Escape)
- No time-dependent interactions (or adjustable timers)
- Large enough click/touch targets (minimum 44x44 pixels)
- No complex gestures required (pinch, multi-finger swipe)

Auditory Impairments

Testing considerations:
- Captions for all video content
- Transcripts for audio content
- Visual alternatives to audio alerts
- No audio-only information

Cognitive Impairments

Testing considerations:
- Clear, simple language
- Consistent navigation patterns
- Error prevention and recovery
- Minimal distractions (animations, autoplay)

Quick Accessibility Audit

You can start testing accessibility right now with these checks:

5-Minute Accessibility Checklist:

[ ] Navigate the entire page using only the keyboard (Tab key)
    - Can you reach every interactive element?
    - Can you see where the focus is?
    - Can you operate all controls?

[ ] Check color contrast
    - Use Chrome DevTools > Rendering > Emulate vision deficiencies
    - Or use the WebAIM contrast checker

[ ] Check images
    - Do all meaningful images have alt text?
    - Are decorative images hidden from screen readers?

[ ] Check headings
    - Is there a logical heading hierarchy (h1 > h2 > h3)?
    - Does the heading structure make sense when read alone?

[ ] Check forms
    - Does every input have a visible label?
    - Are error messages descriptive and linked to inputs?

The Accessibility Tree

Browsers build an accessibility tree alongside the DOM. This is what assistive technologies read.

Understanding the accessibility tree is essential because screen readers do not read your visual layout -- they read this tree. If your accessibility tree is wrong, screen reader users get a broken experience.

Assistive Technologies Overview

Key Takeaways

• Accessibility means making software usable by everyone
• The POUR principles (Perceivable, Operable, Understandable, Robust) guide all a11y work
• Over 1 billion people have disabilities -- your users are among them
• Use semantic HTML as your foundation -- it is accessible by default
• The accessibility tree is what assistive technologies actually read
• Start with the 5-minute checklist to catch the most common issues

Next, you will dive into the WCAG guidelines that define the specific success criteria your applications must meet.