Accessibility Cheat Sheet

This lesson explains Accessibility Cheat Sheet in web accessibility with clear examples, practical use cases, and implementation best practices.

Web Accessibility Cheat Sheet

This Web Accessibility Cheat Sheet provides a quick reference to the most important accessibility practices every frontend developer, UI designer, QA engineer, and full-stack developer should remember. It summarizes essential WCAG guidelines, semantic HTML, ARIA, keyboard navigation, accessible forms, testing, and responsive design in one place.

Bookmark this page and use it during development, code reviews, testing, and deployment to build accessible, inclusive, and WCAG-compliant web applications.

Semantic HTML

✔ Use semantic elements such as header, nav, main, section, article, and footer.
✔ Use only one H1 per page when appropriate.
✔ Follow a logical heading hierarchy.
✔ Use lists for grouped information.
✔ Reserve tables for tabular data only.

Accessible HTML Tags Reference

Tag	Use	Accessibility Benefit	Example
`<header>`	Page or section header	Improves landmark navigation	`<header>...</header>`
`<nav>`	Navigation links	Identifies navigation region for screen readers	`<nav aria-label="Primary">...</nav>`
`<main>`	Primary content area	Helps skip repeated content quickly	`<main>...</main>`
`<section>`	Thematic grouping of content	Creates meaningful structure with headings	`<section><h2>Title</h2>...</section>`
`<article>`	Self-contained content	Improves content semantics and reuse	`<article>...</article>`
`<footer>`	Page or section footer	Defines footer landmark context	`<footer>...</footer>`
`<h1>...<h6>`	Heading hierarchy	Supports document outline and screen reader navigation	`<h1>Page Title</h1>`
`<button>`	Clickable actions	Keyboard and assistive tech support by default	`<button type="button">Save</button>`
`<a>`	Navigation to URL	Expected link semantics and keyboard behavior	`<a href="/about">About</a>`
`<label>`	Form input labeling	Associates readable name with controls	`<label for="email">Email</label>`
`<input>`	Form data entry	Accessible with proper type and label	`<input id="email" type="email" />`
`<fieldset>` + `<legend>`	Group related inputs	Provides context for grouped form fields	`<fieldset><legend>Address</legend>...</fieldset>`
`<ul>`/`<ol>`/`<li>`	Structured lists	Communicates item count and grouping	`<ul><li>Item</li></ul>`
`<table>` + `<th>` + `<caption>`	Tabular data	Supports row/column relationships for assistive tech	`<th scope="col">Name</th>`
`<img>`	Images and icons	Text alternatives with `alt` attribute	`<img src="chart.png" alt="Sales chart" />`

Accessibility Attributes Reference

Attribute	Where Used	Purpose	Example
`lang`	`<html>`	Defines document language for pronunciation/rules	`<html lang="en">`
`alt`	`<img>`	Provides text alternative for images	`<img alt="Team photo" />`
`for`	`<label>`	Associates label with input id	`<label for="name">Name</label>`
`required`	Form controls	Marks field as mandatory	`<input required />`
`aria-label`	Buttons/inputs/icons	Adds accessible name when visible text is missing	`<button aria-label="Close">...</button>`
`aria-labelledby`	Complex widgets	References existing element as accessible name	`aria-labelledby="dialogTitle"`
`aria-describedby`	Inputs/components	References helper/error description	`aria-describedby="emailHelp"`
`aria-hidden`	Decorative/non-interactive elements	Hides element from accessibility tree	`<i aria-hidden="true"></i>`
`aria-expanded`	Accordions/menus	Announces expanded/collapsed state	`aria-expanded="false"`
`aria-controls`	Toggles/buttons	Connects control with controlled region	`aria-controls="menuPanel"`
`aria-live`	Status/alerts	Announces dynamic updates	`<div aria-live="polite">...</div>`
`aria-current`	Breadcrumbs/nav	Marks current item/page	`aria-current="page"`
`role`	Custom components	Defines semantic role only when native tag is insufficient	`role="dialog"`
`tabindex`	Focusable elements	Controls keyboard tab order	`tabindex="0"`
`scope`	`<th>` in tables	Defines header relationship for rows/columns	`<th scope="col">Price</th>`
`title`	Supplemental help text	Provides extra context (not replacement for labels)	`<abbr title="World Health Organization \| PHPKINGDOM">WHO</abbr>`

Images & Multimedia

✔ Add descriptive alternative text for informative images.
✔ Use alt="" for decorative images.
✔ Add captions to videos.
✔ Provide transcripts for audio.
✔ Avoid placing important information only inside images.

Keyboard Accessibility

✔ Ensure every interactive element is keyboard accessible.
✔ Keep keyboard focus visible.
✔ Maintain a logical tab order.
✔ Add skip navigation links.
✔ Never create keyboard traps.

ARIA

✔ Use semantic HTML before adding ARIA.
✔ Apply ARIA only when native HTML is insufficient.
✔ Keep ARIA states synchronized with UI changes.
✔ Use live regions only for dynamic updates.
✔ Validate all ARIA roles and attributes.

Accessible Forms

✔ Associate every input with a visible label.
✔ Clearly indicate required fields.
✔ Provide input instructions before users begin typing.
✔ Display meaningful validation messages.
✔ Explain how users can correct errors.

Visual Accessibility

✔ Meet WCAG color contrast requirements.
✔ Never rely on color alone.
✔ Support browser zoom to at least 200%.
✔ Allow custom text spacing.
✔ Respect reduced motion preferences.

Interactive Components

✔ Use native buttons instead of clickable div elements.
✔ Use descriptive link text.
✔ Trap focus inside dialogs.
✔ Support keyboard navigation for tabs, menus, and dropdowns.
✔ Restore focus after closing dialogs.

Responsive Accessibility

✔ Test desktop, tablet, and mobile layouts.
✔ Verify touch target sizes.
✔ Test portrait and landscape orientations.
✔ Ensure layouts reflow correctly.
✔ Verify accessibility after browser zoom.

Accessibility Testing

✔ Test with keyboard navigation.
✔ Test using screen readers.
✔ Run Lighthouse and axe accessibility audits.
✔ Use browser accessibility inspectors.
✔ Perform manual accessibility reviews.
✔ Retest after every feature update.

WCAG Principles (POUR)

Perceivable — Provide text alternatives, captions, readable content, and sufficient color contrast.
Operable — Support keyboard navigation, focus management, and predictable interactions.
Understandable — Write clear content, provide instructions, and display meaningful errors.
Robust — Use semantic HTML, valid markup, and compatible ARIA to support assistive technologies.

Developer Quick Reminders

✔ Accessibility starts during design, not after development.
✔ Native HTML is almost always more accessible than custom widgets.
✔ Test with real keyboards and screen readers.
✔ Combine automated and manual accessibility testing.
✔ Accessibility improves SEO, usability, and code quality.
✔ Build for everyone, not just the average user.

Pro Tip

Keep this cheat sheet nearby while coding. If you consistently use semantic HTML, support keyboard navigation, write meaningful labels, maintain proper color contrast, and test with assistive technologies, you'll naturally build websites that are more accessible, maintainable, SEO-friendly, and compliant with WCAG standards.