Web Accessibility Cheat Sheet

Updated 2026-05-25

Next Topic: Web APIs and Browser APIs Cheat Sheet

🧠Study flashcards on this topic112 cards · spaced repetition→

Web accessibility ensures digital content and applications are usable by everyone—including people with visual, auditory, motor, or cognitive disabilities—through standards like WCAG (Web Content Accessibility Guidelines) and ARIA (Accessible Rich Internet Applications). It's not just a legal requirement under laws like the ADA and Section 508, but a fundamental principle of inclusive design: when you build for accessibility, you create better experiences for all users—whether someone is navigating by keyboard, using a screen reader, experiencing low vision, or simply using a mobile device in bright sunlight. The European Accessibility Act (EAA) began enforcement in June 2025, extending accessibility obligations to private-sector digital products across the EU. WCAG 3.0 (still a working draft, not expected before 2028) is introducing a Bronze/Silver/Gold conformance model and the Advanced Perceptual Contrast Algorithm (APCA) to replace the current contrast formula. In the meantime, WCAG 2.2 Level AA is the operative legal benchmark globally—proper semantic HTML and ARIA attributes are not afterthoughts but core architectural decisions that determine whether your site works for 15% of the world's population.

What This Cheat Sheet Covers

This topic spans 22 focused tables and 191 indexed concepts, 112 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: WCAG Principles and Conformance LevelsTable 2: Semantic HTML Elements for AccessibilityTable 3: ARIA Landmark Roles and Page StructureTable 4: ARIA Attributes for Labels and DescriptionsTable 5: ARIA Roles for Interactive WidgetsTable 6: Keyboard Navigation and Focus ManagementTable 7: Color Contrast RequirementsTable 8: Accessible FormsTable 9: Images and Media AccessibilityTable 10: Heading Structure and Document OutlineTable 11: Accessible Data TablesTable 12: WCAG 2.2 Success Criteria (New in 2.2)Table 13: Screen Reader TestingTable 14: Automated Accessibility Testing ToolsTable 15: ARIA Design Patterns and Common ComponentsTable 16: Hiding and Revealing Content AccessiblyTable 17: Mobile and Touch AccessibilityTable 18: Animation and Motion AccessibilityTable 19: Language and InternationalizationTable 20: Text Resizing and Content ReflowTable 21: SPA and Dynamic Content AccessibilityTable 22: Legal and Regulatory Compliance

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: WCAG Principles and Conformance Levels

The four POUR principles form the foundation of every WCAG version. Understanding them before diving into individual success criteria gives you a mental model for diagnosing accessibility issues quickly—if something fails, it always maps back to one of these four principles.

Principle	Example	Description
Perceivable	Alt text for images, captions for video	• Information must be presentable in ways users can perceive—not just visual • includes text alternatives, captions, and color contrast
Operable	Full keyboard navigation support	• Interface components must be operable through keyboard, mouse, touch, or assistive tech • includes keyboard access, sufficient time, and seizure safety
Understandable	Clear error messages, consistent navigation	Content and operation must be understandable—predictable behavior, readable text, clear instructions, and helpful error identification.
Robust	Valid HTML, compatible with assistive tech	Content must be robust enough to be reliably interpreted by current and future user agents, including assistive technologies.
Level A (minimum)	Keyboard access, alt text for images	• Basic accessibility requirements—lowest conformance level • must be met but insufficient alone for most legal compliance.
Level AA (standard)	4.5:1 color contrast, skip links	• Industry-standard mid-range level—most common legal requirement globally (ADA Title II, EAA, Section 508) • includes all Level A criteria plus additional success criteria.
Level AAA (enhanced)	7:1 color contrast, sign language interpretation	• Highest accessibility standard—includes all A and AA criteria plus most stringent requirements • recommended but not typically required by law; not achievable for all content.

Table 2: Semantic HTML Elements for Accessibility

Native HTML elements carry built-in accessibility semantics, keyboard behavior, and ARIA roles that custom elements do not—using the right element is always preferable to adding role attributes to div or span wrappers. A good mental test: if you find yourself adding role, tabindex, and keyboard event handlers to a non-semantic element, ask first whether a native element already does the job.

Element	Example	Description
`<button>`	`<button type="button">Submit</button>`	• Triggers action on current page—inherently keyboard accessible • always prefer over `<div role="button">`—native elements have built-in focus, Enter, and Space activation.

The rest of this section is part of the full cheat sheet

Table 3: ARIA Landmark Roles and Page Structure

Landmarks let screen reader users jump directly to major sections of a page—a critical navigation shortcut. Use native HTML elements wherever possible, as their implicit landmark roles are more reliable across assistive technology combinations than explicit role attributes.

Role	Example	Description
role="banner"	`<header role="banner">`	• Site-wide header—typically contains logo and global navigation • one per page; implicit on `<header>` when direct child of `<body>`.

The rest of this section is part of the full cheat sheet

Table 4: ARIA Attributes for Labels and Descriptions

ARIA attributes only modify the accessibility tree—they do not change visual appearance or behavior. Always prefer native HTML semantics first, add ARIA only where native semantics fall short. The most critical rule: the first rule of ARIA is don't use ARIA.

Attribute	Example	Description
aria-label	`<button aria-label="Close dialog">×</button>`	• Provides accessible name directly in attribute when no visible label exists • overwrites visible text—use only when no visible text alternative exists.

The rest of this section is part of the full cheat sheet

Table 1: WCAG Principles and Conformance Levels

Principle	Example	Description
Perceivable	Alt text for images, captions for video	• Information must be presentable in ways users can perceive—not just visual • includes text alternatives, captions, and color contrast
Operable	Full keyboard navigation support	• Interface components must be operable through keyboard, mouse, touch, or assistive tech • includes keyboard access, sufficient time, and seizure safety
Understandable	Clear error messages, consistent navigation	Content and operation must be understandable—predictable behavior, readable text, clear instructions, and helpful error identification.
Robust	Valid HTML, compatible with assistive tech	Content must be robust enough to be reliably interpreted by current and future user agents, including assistive technologies.
Level A (minimum)	Keyboard access, alt text for images	• Basic accessibility requirements—lowest conformance level • must be met but insufficient alone for most legal compliance.
Level AA (standard)	4.5:1 color contrast, skip links	• Industry-standard mid-range level—most common legal requirement globally (ADA Title II, EAA, Section 508) • includes all Level A criteria plus additional success criteria.
Level AAA (enhanced)	7:1 color contrast, sign language interpretation	• Highest accessibility standard—includes all A and AA criteria plus most stringent requirements • recommended but not typically required by law; not achievable for all content.

Table 2: Semantic HTML Elements for Accessibility

Element	Example	Description
`<button>`	`<button type="button">Submit</button>`	• Triggers action on current page—inherently keyboard accessible • always prefer over `<div role="button">`—native elements have built-in focus, Enter, and Space activation.

Table 3: ARIA Landmark Roles and Page Structure

Role	Example	Description
role="banner"	`<header role="banner">`	• Site-wide header—typically contains logo and global navigation • one per page; implicit on `<header>` when direct child of `<body>`.

Table 4: ARIA Attributes for Labels and Descriptions

Attribute	Example	Description
aria-label	`<button aria-label="Close dialog">×</button>`	• Provides accessible name directly in attribute when no visible label exists • overwrites visible text—use only when no visible text alternative exists.