– Guided Study Workspace

1. What Is Web Accessibility (a11y)?

Web Accessibility (often abbreviated as a11y, where '11' represents the 11 letters between 'a' and 'y') means ensuring there are no barriers that prevent people with physical, sensory, cognitive, or situational disabilities from using the web.

🌐 "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." — Tim Berners-Lee, Inventor of the World Wide Web.

2. Why Accessibility Matters: The 3 Spectrums

1. Permanent

Permanent Disabilities

Over 1.3 billion people globally live with significant permanent disabilities (blindness, motor impairments, deafness, dyslexia).

2. Temporary

Temporary Impairments

A broken arm, dilated eyes after an optometrist appointment, or a lost pair of prescription glasses.

3. Situational

Situational Limitations

Browsing on a smartphone in harsh direct sunlight, holding a crying baby with one hand, or viewing in a noisy subway train.

3. Understanding Assistive Technologies

Technology	How It Works	What It Requires From HTML
Screen Readers (NVDA, JAWS, VoiceOver)	Converts visual text and DOM structure into synthesized speech or refreshable braille displays.	Semantic landmarks, descriptive `alt` text, proper heading outline, and form labels.
Keyboard Only (Tab, Shift+Tab, Enter)	Navigates through focusable interactive controls without a mouse or touchscreen.	Visible focus rings, logical tab order, and native `<button>` / `<a>` tags.
Screen Magnifiers (ZoomText, OS Zoom)	Enlarges parts of the screen up to 1600%.	Responsive fluid layouts that don't break when zoomed to 400% without horizontal scroll.
Voice Control (Dragon, Siri)	Allows users to navigate and click elements by speaking on-screen button names aloud.	Visible button text matching the underlying accessible name.

4. Semantic HTML: The Accessibility Foundation

Native HTML elements come with built-in accessibility features for free:

Landmarks: <header>, <nav>, <main>, and <footer> allow blind users to jump across page sections with a single keypress.
Headings: Strict hierarchy (h1 ➔ h2 ➔ h3) generates an instant mental table of contents.
Buttons vs Divs: <button> automatically supports Tab focus, Enter, and Spacebar triggers. A <div onclick> is completely invisible to keyboards.

5. Keyboard Accessibility & Visible Focus Rings

❌ Dangerous CSS: Removing Focus

/* Never remove focus without a replacement! */
*:focus {
outline: none; 
}

✅ Modern Accessible Focus Styling

/* Only shows focus for keyboard users */
:focus-visible {
outline: 3px solid #06b6d4;
outline-offset: 3px;
}

6. Accessible Forms: Explicit Labels & Error States

Every input must have an accessible name and clear error communication:

<label for="user-email">Work Email (Required):</label>
<input
  type="email"
  id="user-email"
  name="email"
  required
  aria-describedby="email-hint email-error"
/>
<p id="email-hint">We will never share your email.</p>
<p id="email-error" role="alert" style="color: #ef4444;">⚠️ Please enter a valid email address.</p>

7. Crafting Meaningful Alternative Text (alt)

Informative Image (Conveys Meaning)

Describe the content and purpose concisely:

Decorative Image (Visual Only)

Use empty alt="" so screen readers ignore it:

8. Color Contrast & Dual Indicators

WCAG 4.5:1 Ratio: Body text must have at least a 4.5:1 contrast ratio against the background (3:1 for text larger than 18pt/24px).
Never Rely on Color Alone: If an input is invalid, don't just turn the border red. Add an error icon (⚠️) and an explicit textual message.

9. Accessible Buttons and Link Text

❌ Vague Link Text

<p>To see our roadmaps, <a href="/roadmap">click here</a>.</p>

✅ Descriptive Link Text

<p>Explore our <a href="/roadmap">interactive career roadmaps</a>.</p>

10. ARIA Basics & The 1st Rule of ARIA

📜 The First Rule of ARIA: No ARIA is better than Bad ARIA. Only use ARIA when native HTML5 cannot express the needed role or state.

`aria-label`

Provides an invisible accessible name for icon-only buttons (e.g. aria-label="Close menu").

`aria-expanded`

Tells screen readers whether an accordion or dropdown menu is currently open ("true") or closed ("false").

`aria-live`

Announces dynamic toast notifications or live search updates automatically to blind users.

11. Accessible Modals & Dynamic Popups

When a modal dialog opens:

Move focus into the modal immediately (element.focus()).
Trap keyboard focus so Tab cannot cycle to hidden background elements.
Allow closing the modal with the Escape key.
Restore focus back to the button that originally opened the dialog when closed.

12. The 3-Step Accessibility Testing Routine

Step 1

Keyboard-Only Test

Unplug your mouse and navigate your entire site using only Tab, Shift+Tab, Enter, and Space.

Step 2

Automated Scanner

Run Google Chrome Lighthouse or axe DevTools extension to catch contrast and missing alt tags.

Step 3

Screen Reader Run

Turn on VoiceOver (Mac: Cmd + F5) or NVDA (Windows) and listen to your page with eyes closed.

13. Common Accessibility Mistakes

Removing Focus Rings: outline: none leaves keyboard users lost.
Unlabelled Icon Buttons: <button><svg></svg></button> without aria-label reads as "Unlabelled button".
Skipping Heading Levels: Jumping from h1 straight to h4 breaks the screen reader page map.

14. Summary: The Frontend a11y Checklist

Requirement	Standard	Rule of Thumb
Images	WCAG 1.1.1	Always provide descriptive `alt` or empty `alt=""`
Keyboard Focus	WCAG 2.4.7	Clear, high-contrast `:focus-visible` ring on all interactive controls
Color Contrast	WCAG 1.4.3	Minimum 4.5:1 ratio for normal body text
Form Labels	WCAG 3.3.2	Every `<input>` must have an explicit `<label for="id">`

Web Accessibility Basics: Building Websites Everyone Can Use