Module -10: Accessibility Fundamentals — Design & Code Foundations

01

Why Accessibility Matters

15-20% of people have disabilities. But accessible design benefits everyone — it's not just about compliance, it's about inclusion and better UX.

15%

Visual impairments

5%

Hearing impairments

7%

Cognitive disabilities

2%

Motor impairments

~1 billion people worldwide have some form of disability

Who Are We Designing For?

Disability isn't rare — it affects 15-20% of the global population. Visual impairments range from color blindness to total blindness. Motor impairments affect mouse use. Cognitive disabilities affect reading and comprehension.

Reality: 1 in 5 users may need accessibility accommodations

Permanent

🦯

Blind user

Temporary

🤕

Eye surgery recovery

Situational

☀️

Bright sunlight glare

One arm → broken arm → holding a baby
Each benefits from one-handed operation

Disability Is a Spectrum

Disabilities aren't just permanent. A broken arm is temporary. Holding a baby is situational. Designing for accessibility helps everyone: captions help in noisy environments, large touch targets help when hands are full.

Universal benefit: Accessible design creates better UX for everyone

ADA

Americans with Disabilities Act

US law requiring accessible public accommodations — includes websites

WCAG

Web Content Accessibility Guidelines

International standard — Level AA is the common target

EAA

European Accessibility Act

EU directive — stricter enforcement starting 2025

Legal Requirements

Accessibility isn't optional in many jurisdictions. ADA lawsuits against inaccessible websites are common. WCAG 2.1 Level AA is the de facto standard for compliance. Ignoring accessibility is a legal risk.

Requirement: Legal compliance is a minimum — aim higher

Perceivable

Users can perceive content — alt text, captions, sufficient contrast

Operable

Users can interact — keyboard navigation, no time limits, no seizure triggers

Understandable

Users can comprehend — clear language, predictable behavior, error help

Robust

Works with assistive tech — valid HTML, ARIA support, future-compatible

The Four Principles (POUR)

WCAG is organized around four principles: Perceivable (can they sense it?), Operable (can they use it?), Understandable (can they comprehend it?), Robust (does it work with assistive tech?).

Framework: POUR is your accessibility checklist framework

02

Semantic HTML

The foundation of accessibility. Using the right HTML elements gives structure, meaning, and free accessibility features.

Non-semantic (Bad)

<div class="button" onclick="...">
  Click me
</div>

<div class="heading">
  Page Title
</div>

Screen reader sees: "div, div" — meaningless

Semantic (Good)

<button>
  Click me
</button>

<h1>
  Page Title
</h1>

Screen reader sees: "button, heading level 1"

HTML Elements Have Meaning

Screen readers announce element types. A <button> is announced as "button" — users know they can click it. A <div> is announced as nothing. Semantic HTML provides meaning for free.

Rule: Use the right element. div and span are last resorts.

Wrong: Skipped levels

h1: Title

h4: Subsection (?)

h2: Section

Correct: Logical order

h1: Title

h2: Section

h3: Subsection

Screen reader users navigate by headings. Logical hierarchy = logical navigation.

Heading Hierarchy

Headings create document outline. Go in order: h1 → h2 → h3. Don't skip levels. Don't use headings just for styling — use CSS for visual size. Screen reader users jump between headings to navigate.

Common mistake: One h1 per page, never skip levels

<header> / role="banner"

<nav>

<main>

<footer> / role="contentinfo"

Screen reader users can jump directly to any landmark

Landmark Regions

Landmark elements (<header>, <nav>, <main>, <footer>, <aside>) create navigable regions. Screen reader users can list all landmarks and jump directly to any section.

Navigation: Use landmark elements for major page sections

Lists announce item count

"List, 2 items"

Tables need headers

<table>
<th>Name</th>
<td>Alice</td>
</table>

"Name: Alice"

Structured Content

Lists (<ul>, <ol>) announce item count. Tables need <th> headers so cells are announced with their column/row header. Don't use tables for layout — only for tabular data.

Structure: Semantic structure helps users understand content organization

03

Keyboard Navigation

Many users can't use a mouse. Everything must be operable via keyboard alone.

1 ●

2

3

4

TabMove to next focusable elementShift+TabMove to previous elementEnterActivate buttons and linksSpaceToggle checkboxes, activate buttons

Focus and Tab Order

Users navigate with Tab (forward) and Shift+Tab (backward). Native elements (<button>, <a>, <input>) are focusable by default. The blue outline shows which element is focused.

Test it: Tab through your page — can you reach everything?

Bad: Focus hidden

:focus {
  outline: none;
}

Keyboard users can't see where they are!

Good: Custom focus style

:focus-visible {
  outline: 3px solid blue;
  outline-offset: 2px;
}

Replace, don't remove. -visible = keyboard only.

Never Hide Focus Indicators

Never use outline: none without a replacement. The focus indicator is essential for keyboard users. Use :focus-visible to show focus only for keyboard navigation, not mouse clicks.

Critical: If you remove outline, you MUST add a visible replacement

Modal Dialog

Focus should be trapped inside this modal.

Confirm

Cancel

Tab cycles within modal: Close → Content → Confirm → Cancel → Close...
Escape closes. Focus returns to trigger element.

Modal Focus Management

When a modal opens: move focus inside, trap focus so Tab cycles within the modal, close on Escape, return focus to the trigger when closed. This prevents users from getting lost behind the modal.

Pattern: Modals must trap focus and handle Escape

Skip to main content

Main content

<a href="#main" class="skip-link">Skip to main content</a>
...
<main id="main">...</main>

Skip to Main Content

Skip links let keyboard users bypass repetitive navigation. The first Tab press should reveal a "Skip to main content" link. It's visually hidden until focused, then jumps focus past the nav to main content.

UX win: Skip links save time on every single page visit

04

Color & Contrast

Sufficient contrast ensures text is readable. Never rely on color alone to convey meaning.

Text on white

4.5:1 ✓

Text on white

2.8:1 ✗

Large text

3:1 ✓

AA Requirements: Normal text = 4.5:1, Large text (18px+) = 3:1
AAA Requirements: Normal text = 7:1, Large text = 4.5:1

WCAG Contrast Requirements

WCAG Level AA requires 4.5:1 contrast for normal text, 3:1 for large text (18px+ or 14px bold). Level AAA is stricter. Use tools like WebAIM Contrast Checker or browser DevTools.

Numbers: 4.5:1 for text. 3:1 for UI components and large text.

Bad: Color only

Status shown only by color

Good: Color + icon/text

✕Error

✓Success

Don't Rely on Color Alone

8% of men are color blind. Red/green is most common. Always provide a secondary indicator: icons, text labels, patterns, or underlines. Links should be underlined, not just colored differently.

Rule: Color can enhance, but can't be the only indicator

Input needs visible boundary

Email address

Button needs visible boundary

Submit

WCAG 2.1: UI components need 3:1 contrast against adjacent colors. This includes input borders, button boundaries, and focus indicators.

Component Boundaries

WCAG 2.1 added requirements for UI components: interactive elements must have 3:1 contrast against their background. This means input borders, button edges, and focus indicators must be clearly visible.

WCAG 2.1: Inputs and buttons need visible boundaries, not just fills

05

Images & Media

Images need alt text. Videos need captions. Audio needs transcripts. Make media accessible to everyone.

🐕

Bad: "dog.jpg" or "image"

Good: "Golden retriever playing fetch in a park"

📊

Bad: "chart" or "data visualization"

Good: "Sales increased 40% from Q1 to Q4 2024"

🎨

Decorative image? Use alt=""

Empty alt tells screen readers to skip it

Writing Good Alt Text

Alt text describes the purpose, not just appearance. For informational images, describe what's happening. For charts, describe the data story. For decorative images, use alt="" to skip them.

Guideline: Describe purpose and meaning, not just appearance

Informative (needs alt)

• Product photos
• Infographics & charts
• Images in articles
• Screenshots
• Logos with text

Decorative (alt="")

• Background patterns
• Spacer images
• Purely aesthetic elements
• Icons next to text labels
• Redundant images

When to Use Empty Alt

Not every image needs alt text. Decorative images that add no information should use alt="". This tells screen readers to skip them entirely, reducing noise for users.

Decision: Decorative = alt="". Informative = descriptive alt.

Video Requirements

• Captions — synchronized text of spoken content
• Audio descriptions — narration of visual information
• Transcript — full text alternative

Audio Requirements

• Transcript — full text of audio content
• Speaker identification for podcasts/interviews

Captions and Transcripts

Videos need captions for deaf users. Pre-recorded videos also need audio descriptions for blind users (describing visual action). Podcasts need transcripts. Auto-captions are a start but need human review.

Universal: Captions benefit everyone — noisy places, quiet spaces, non-native speakers

06

ARIA Basics

ARIA adds accessibility information when HTML alone isn't enough. But the first rule: don't use ARIA if native HTML works.

Unnecessary ARIA

<div role="button"
  tabindex="0"
  onclick="..."
  onkeydown="...">
  Click me
</div>

Just use HTML

<button>
  Click me
</button>

// Keyboard handling is free!

Don't Use ARIA When HTML Works

Native HTML elements come with built-in accessibility: focus handling, keyboard events, screen reader announcements. ARIA can't add these — it only adds labels. Use HTML first, ARIA only when necessary.

Rule #1: No ARIA is better than bad ARIA

aria-label: inline label

<button aria-label="Close dialog">✕</button>

Screen reader: "Close dialog, button"

aria-labelledby: reference visible text

<h2 id="cart-title">Shopping Cart</h2>
<nav aria-labelledby="cart-title">...</nav>

Screen reader: "Shopping Cart, navigation"

aria-label and aria-labelledby

aria-label provides an accessible name directly. aria-labelledby points to visible text elsewhere. Use these when there's no visible label, or when the visible text is insufficient.

Essential: Labels make elements identifiable

aria-expandedDropdown open/closed state

aria-hiddenHide from screen readers (decorative icons)

aria-disabledVisually disabled but still focusable

aria-liveAnnounce dynamic changes ("polite" or "assertive")

aria-expanded, aria-hidden, aria-disabled

ARIA states communicate dynamic information. aria-expanded tells screen readers if a menu is open. aria-live announces changes without focus (like "Item added to cart").

Dynamic: Update ARIA states when UI changes

<div aria-live="polite">
  {dynamic content here}
</div>

polite

Waits until user is idle. Use for most updates.

assertive

Interrupts immediately. Use for errors only.

Announcing Dynamic Content

aria-live regions announce content changes to screen readers. "polite" waits for a pause — use for most things. "assertive" interrupts immediately — use sparingly for critical errors.

Announcements: Live regions announce without moving focus

15

Self-Assessment

Test your understanding of Accessibility Fundamentals. Click each question to reveal the answer.

Q1

What contrast ratio does WCAG AA require for normal text?

Click to reveal

Q2

What should you use for a decorative image that adds no information?

Click to reveal

Q3

Why is semantic HTML important for accessibility?

Click to reveal

Q4

What's the first rule of ARIA?

Click to reveal

Q5

How can keyboard users skip repetitive navigation?

Click to reveal

Q6

When should you use aria-live="assertive"?

Click to reveal

Accessibility Fundamentals

Core Concepts

Why Accessibility Matters

Semantic HTML

Keyboard Navigation

Color & Contrast

Images & Media

ARIA Basics

Self-Assessment

Self-Assessment

Key Takeaways