6/8

Lesson 6 12 min

Accessibility (a11y)

Implement web accessibility — WCAG guidelines, ARIA roles, keyboard navigation, color contrast, focus management, and AI-powered accessibility auditing.

Premium Course Content

This lesson is part of a premium course. Upgrade to Pro to unlock all premium courses and content.

Access all premium courses
1000+ AI skill templates included
New content added weekly

← Back to course overview

🔄 Recall Bridge: In the previous lesson, you mastered responsive design — fluid typography, responsive images, and mobile-first layouts. Now let’s ensure your pages are usable by everyone, including people who navigate with keyboards, screen readers, or other assistive technology.

Accessibility isn’t a feature — it’s a quality attribute of all good frontend code. An estimated 15-20% of the global population has some form of disability. Beyond ethics, accessibility is legally required in many jurisdictions and improves usability for everyone.

WCAG Quick Reference

WCAG (Web Content Accessibility Guidelines) has four principles:

Principle	Meaning	Key Requirements
Perceivable	Users can perceive content	Alt text, contrast, captions
Operable	Users can interact	Keyboard nav, no seizure-inducing content
Understandable	Content is clear	Readable text, predictable navigation
Robust	Works with assistive tech	Valid HTML, ARIA when needed

Conformance levels:

A: Minimum (essential barriers removed)
AA: Standard (most organizations target this)
AAA: Enhanced (strictest, not always achievable)

Every interactive element must be keyboard-accessible:

Action	Keyboard	Requirement
Navigate between elements	Tab / Shift+Tab	Logical tab order
Activate button/link	Enter (links), Enter/Space (buttons)	All clickable elements
Navigate within component	Arrow keys	Dropdowns, tabs, menus
Dismiss/close	Escape	Modals, dropdowns, tooltips
Submit form	Enter	From any form field

Focus management rules:

Rule	Implementation
Visible focus indicator	`outline` or `box-shadow` on `:focus-visible`
Never remove focus outline	Don’t use `outline: none` without replacement
Logical tab order	Match visual order, use `tabindex="0"` sparingly
Focus trapping in modals	Tab stays inside the dialog until closed
Focus restoration	After closing modal, return focus to trigger

AI prompt for keyboard audit:

Audit this HTML for keyboard accessibility: [PASTE]. Check: (1) Can all interactive elements receive focus? (2) Is the tab order logical (matches visual order)? (3) Do custom components (dropdowns, modals) support expected keyboard patterns? (4) Are there visible focus indicators? (5) Is focus managed correctly for dynamic content (modals trap focus, closing restores focus)?

ARIA: When HTML Isn’t Enough

ARIA rule: Use semantic HTML first. ARIA is for when native HTML doesn’t express the interaction pattern.

Pattern	Native HTML	ARIA (if needed)
Navigation	`<nav>`	`role="navigation"`
Button	`<button>`	`role="button"` + `tabindex="0"`
Modal	`<dialog>`	`role="dialog"` + `aria-modal="true"`
Tab interface	None native	`role="tablist"`, `role="tab"`, `role="tabpanel"`
Live updates	None native	`aria-live="polite"` or `role="alert"`

Common ARIA attributes:

Attribute	Purpose	Example
`aria-label`	Accessible name	`<nav aria-label="Main">`
`aria-labelledby`	Name from another element	`<dialog aria-labelledby="title">`
`aria-describedby`	Additional description	`<input aria-describedby="help-text">`
`aria-expanded`	Open/closed state	`<button aria-expanded="false">`
`aria-hidden`	Hide from screen readers	`<span aria-hidden="true">★</span>`
`aria-live`	Announce dynamic changes	`<div aria-live="polite">`
`aria-current`	Current item indicator	`<a aria-current="page">Home</a>`

Color & Contrast

Requirement	WCAG Level	Ratio
Normal text	AA	4.5:1
Large text (18px+ bold or 24px+)	AA	3:1
Non-text elements (icons, borders)	AA	3:1
Normal text	AAA	7:1

AI prompt for contrast checking:

Check all color combinations on my page for WCAG AA compliance. My colors: text #1f2937 on background #ffffff, link #3b82f6 on background #ffffff, button text #ffffff on button background #3b82f6. For any failing combinations, suggest the closest compliant color.

Reduced Motion

Respect users who prefer less animation:

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

✅ Quick Check: Your page uses a decorative icon (a star rating display using star emoji). Should the stars have alt text? (Answer: Decorative content that conveys information needs alt text. If the stars represent a 4/5 rating, add aria-label="Rating: 4 out of 5" to the container and aria-hidden="true" to each individual star character. Purely decorative images that convey no information should have empty alt: alt="". The distinction is whether the visual conveys meaningful information.)

Accessibility Testing Workflow

Step	Tool	Catches
1. Automated scan	axe DevTools, Lighthouse	Missing alt, contrast, labels (~30-40%)
2. Keyboard test	Your keyboard (no mouse)	Tab order, focus traps, missing interactions
3. Screen reader	VoiceOver (Mac), NVDA (Windows)	Announcement order, missing labels, live regions
4. Zoom test	Browser zoom to 200%	Content overflow, truncation
5. Color test	Disable CSS colors	Information not conveyed by color alone

Key Takeaways

Automated testing catches only 30-40% of accessibility issues: after running axe/Lighthouse, manually tab through the page (keyboard test), use a screen reader (announcement test), and zoom to 200% (visual test) to find the problems tools miss
Dynamic content (notifications, form errors, loading states) is invisible to screen readers unless announced: use aria-live="polite" for informational updates and role="alert" for urgent messages — this is the most commonly missed accessibility requirement in AI-generated code
Color contrast is measurable and non-negotiable: 4.5:1 for normal text, 3:1 for large text (WCAG AA) — when a design fails contrast, suggest the closest compliant color rather than a completely different color to maintain design intent while meeting the standard

Up Next

In the next lesson, you’ll optimize frontend performance for Core Web Vitals — LCP, CLS, and INP — making your pages fast on any connection and device.

Knowledge Check

1. Your page passes automated accessibility testing (axe DevTools shows 0 issues). Does this mean your page is accessible?

Yes — 0 issues from automated testing means the page meets WCAG standards No — automated tools catch only about 30-40% of accessibility issues. They can verify: (1) Images have alt attributes, (2) Color contrast ratios meet minimums, (3) Form inputs have labels, (4) ARIA attributes are valid. They CANNOT verify: (1) Whether alt text is meaningful ('image' passes the tool but fails users), (2) Whether keyboard navigation is logical (tab order makes sense), (3) Whether screen reader experience is coherent (content reads in a logical order), (4) Whether dynamic content (modals, dropdowns, notifications) announces changes, (5) Whether animations respect prefers-reduced-motion. After automated testing, manually test: tab through the page, use a screen reader, try with keyboard only, check with zoom at 200% Mostly — automated tools catch 90% of issues, the remaining 10% are edge cases

2. A designer gives you a button with white text (#ffffff) on a light blue background (#60a5fa). It looks great visually. You check the contrast ratio and it's 2.8:1. WCAG AA requires 4.5:1 for normal text. What do you do?

Use the lighter color — the designer approved it and visual design matters Darken the blue background until the contrast ratio meets 4.5:1. The specific fix: change #60a5fa to #2563eb (contrast ratio: 4.6:1 with white text — meets AA). Present both options to the designer: 'The original blue (#60a5fa) has 2.8:1 contrast, which fails WCAG AA. Here's a darker blue (#2563eb) at 4.6:1 that meets the standard. For large text (18px+ bold or 24px+), the requirement is only 3:1, so we could use the lighter blue for headings if preferred.' AI helps: 'My button has white (#ffffff) text on #60a5fa background. The contrast is 2.8:1. Suggest the closest color to #60a5fa that meets WCAG AA (4.5:1) contrast with white text' Add a text shadow to make the text more readable without changing the color

3. Your page has a notification that appears after a form submission: 'Your message was sent successfully!' Sighted users see it appear. Screen reader users hear nothing. How do you fix this?

Add `role="alert"` to the notification element — screen readers will announce dynamic content with this role. But use it correctly: (1) The element with `role="alert"` should exist in the DOM before the notification text is added (or use `aria-live="polite"` on a container). (2) Use `aria-live="polite"` for informational messages (waits for screen reader to finish current speech). (3) Use `aria-live="assertive"` or `role="alert"` for urgent messages (interrupts current speech). (4) Never make the ENTIRE page an aria-live region — only the notification container. (5) For error messages, also link them to the form field: `<input aria-describedby="error-msg"><p id="error-msg">This field is required</p>` Screen reader users will check the page for updates — you don't need to announce changes Redirect to a new page with the success message — screen readers announce new pages automatically

Answer all questions to check

Complete the quiz above first