Accessibility Checklist

All images have meaningful alt text

Every informative <img> element must have an alt attribute that describes the image's content or function. Decorative images should use an empty alt="" so screen readers skip them. Avoid generic text like "image" or "photo."

Complex images have long descriptions

Charts, graphs, infographics, and diagrams need detailed text descriptions that convey all the information presented visually. Use aria-describedby linking to a visible description, or provide the description in surrounding text.

Video has synchronized captions

All pre-recorded video with audio must have accurate, synchronized captions. Captions should include speaker identification, sound effects, and music cues. Auto-generated captions must be reviewed and corrected for accuracy.

Video has audio descriptions

Pre-recorded video must include audio descriptions of important visual information that isn't conveyed through the existing audio track. This includes on-screen text, actions, scene changes, and visual cues critical to understanding the content.

Pre-recorded audio has a transcript

All pre-recorded audio-only content (podcasts, voice messages, audio clips) must have a text transcript that includes all spoken content and identifies different speakers. Provide the transcript inline or as a linked document.

SVGs have accessible names

Informative SVGs should have a <title> element as the first child and role="img". Decorative SVGs should use aria-hidden="true". Inline SVGs used as icons inside buttons need the button itself to have an accessible name via aria-label.

Image text alternatives convey the same information

Alt text should describe the purpose the image serves in context, not just what the image looks like. A photo of a graph should describe the data trend, not "a bar chart." A logo linking to the homepage should say "Company name - home" rather than "logo."

Animated content can be paused, stopped, or hidden

Any auto-playing animation, carousel, or moving content that lasts more than 5 seconds must have a mechanism for the user to pause, stop, or hide it. This includes GIFs, CSS animations, and video backgrounds. Provide a visible pause button or respect prefers-reduced-motion.

Heading hierarchy is logical (h1–h6)

Headings must follow a logical, nested order without skipping levels. An <h3> should only appear after an <h2>, never directly after an <h1>. Screen reader users rely on heading structure to navigate and understand page organization.

Page has exactly one h1

Each page should have a single <h1> that describes the page's primary content. Multiple <h1> elements confuse the document outline and make navigation harder for screen reader users who use heading shortcuts to orient themselves.

Lists use proper list elements

Groups of related items must use <ul>, <ol>, or <dl> elements rather than styled <div> or <span> elements. This allows screen readers to announce the number of items and provide list navigation shortcuts.

Tables use <th> and scope attributes

Data tables must use <th> elements for header cells with appropriate scope="col" or scope="row" attributes. Complex tables with multi-level headers should use id and headers attributes. Layout tables should not use <th>.

Landmarks are used (main, nav, aside, footer)

Use HTML5 landmark elements like <header>, <nav>, <main>, <aside>, and <footer> to define page regions. There should be exactly one <main>. When multiple <nav> elements exist, give each an aria-label to distinguish them.

Content reading order is meaningful

The DOM order of content must match the visual reading order. CSS layout (flexbox order, grid positioning, absolute positioning) can create a visual order that differs from the source order, confusing screen reader and keyboard users. Test by disabling CSS and verifying the order still makes sense.

ARIA landmarks supplement HTML5 elements

Prefer native HTML5 landmark elements over ARIA roles. Use ARIA roles (role="banner", role="navigation", etc.) only when native elements are not available. Never use ARIA to override the semantics of a native element. Remember: the first rule of ARIA is "don't use ARIA" if a native element will do.

Language is set on the html element

The <html> element must have a valid lang attribute (e.g., lang="en"). Sections in a different language should use their own lang attribute. This allows screen readers to switch pronunciation rules and helps translation tools identify the content language.

All form fields have visible labels

Every input, select, and textarea must have a visible label that remains visible when the field has focus and contains a value. Placeholder text is not a substitute for a label. It disappears on input and often has insufficient contrast.

Labels are programmatically associated

Use <label for="id"> to explicitly associate labels with their form controls. Alternatively, wrap the input inside the <label> element. For groups of related controls (radio buttons, checkboxes), use <fieldset> and <legend>.

Required fields are indicated (not by color alone)

Required fields must be indicated with text (e.g., "required"), an asterisk with a legend explaining its meaning, or the aria-required="true" attribute. Never rely solely on a red border or color change to indicate that a field is required.

Error messages identify the field and describe the error

When a form validation error occurs, the error message must identify which field has the error and describe what's wrong in plain language. Use aria-describedby to associate error messages with their fields. Move focus to the first error or provide an error summary at the top of the form.

Form validation doesn't rely solely on color

Error states must be communicated through multiple channels: text messages, icons, and border changes, not just a red border. Include an error icon alongside the color change, and ensure the error text is visible and proximate to the affected field.

Autocomplete attributes are used for personal data

Input fields that collect personal information (name, email, phone, address, credit card) must use the appropriate autocomplete attribute values (e.g., autocomplete="email", autocomplete="given-name"). This helps users with cognitive disabilities and motor impairments fill in forms more easily.

Redundant entry is minimized (WCAG 2.2)

Users should not be required to re-enter information they have already provided in the same process. Auto-populate fields where possible, or provide a mechanism to select previously entered data. Exceptions include security-sensitive re-entry (e.g., confirming a password) and expired data.

Authentication doesn't require cognitive function tests (WCAG 2.2)

Login flows must not require users to solve puzzles, remember passwords without paste support, or transcribe CAPTCHAs. Support password managers (don't block paste), offer passkey/WebAuthn options, and if CAPTCHAs are necessary, provide an accessible alternative.

All functionality is keyboard accessible

Every interactive element (links, buttons, form controls, menus, modals, drag-and-drop) must be operable with the keyboard alone using Tab, Shift+Tab, Enter, Space, Escape, and arrow keys. Test by unplugging your mouse and navigating the entire interface.

Focus order is logical

The tab order must follow a logical reading sequence (typically left-to-right, top-to-bottom in LTR languages). Avoid positive tabindex values. When content is dynamically inserted (modals, dropdowns), manage focus so it moves to the new content and returns when dismissed.

Skip navigation link is provided

Provide a "Skip to main content" link as the first focusable element on the page. It should be visible on focus and jump past repetitive navigation to the <main> content. This prevents keyboard users from having to tab through the entire navigation on every page.

Link text is descriptive (no "click here")

Every link's text must make sense out of context. Avoid "click here," "read more," or "learn more" as standalone link text. If the surrounding sentence provides context, use aria-label or aria-describedby to provide the full context programmatically.

Focus indicator is visible (3:1 contrast, 2px outline)

All focusable elements must have a visible focus indicator with at least 3:1 contrast against the adjacent background. The focus indicator area must be at least as large as a 2px solid outline around the component. Never use outline: none without providing a custom focus style.

Focus is not obscured by sticky headers (WCAG 2.2)

When an element receives keyboard focus, it must not be entirely hidden behind sticky headers, footers, or chat widgets. Use scroll-padding-top to account for fixed headers, and ensure modals or overlapping content don't trap or obscure focus.

Consistent navigation across pages

Navigation menus and repeated components must appear in the same relative order on every page. Users build spatial memory of where things are; changing navigation order between pages disrupts this and increases cognitive load. Additions are fine as long as the existing order is preserved.

Text has 4.5:1 contrast ratio (normal text)

All text smaller than 18pt (or 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Test with a contrast checker tool . Don't rely on visual estimation. Check all states: default, hover, focus, disabled (disabled text is exempt but should still be readable).

Large text has 3:1 contrast ratio

Text at or above 18pt (24px) or 14pt bold (roughly 19px bold) must have a contrast ratio of at least 3:1. This applies to headings, large buttons, and other prominent text. Measure the rendered font size, not just the CSS value, as zoom and browser settings affect it.

UI components have 3:1 contrast

Visual boundaries of interactive components (buttons, input borders, checkboxes, toggles) and meaningful graphical objects (icons conveying information) must have at least 3:1 contrast against adjacent colors. This includes the component's border or fill against the page background.

Color is not the only way to convey information

Never use color as the sole means of conveying meaning. Error states need text and icons in addition to red. Chart data needs patterns or labels in addition to colors. Status indicators need text labels alongside colored dots. Test by viewing your UI in grayscale.

Links are distinguishable from surrounding text

Links within body text must be visually distinguishable from non-link text by more than just color. Use underlines (preferred), bold weight, or a combination. If relying on color alone, the link color must have 3:1 contrast against the surrounding text and an additional visual cue (like underline) on hover and focus.

Focus indicators meet contrast requirements

The keyboard focus indicator must have at least 3:1 contrast against both the focused component and the adjacent background. Test focus styles on every interactive element, on both light and dark backgrounds. A 2px solid outline with an offset of 2px is a reliable approach.

Content reflows at 320px width (no horizontal scroll)

At 320 CSS pixels wide (equivalent to 1280px at 400% zoom), all content and functionality must be available without horizontal scrolling. Exceptions include data tables, maps, and diagrams that inherently require two-dimensional layout. Test by setting your browser to 320px wide or zooming to 400%.

Text can be resized to 200% without loss

When text is resized to 200% using browser zoom, all content must remain readable and functional. No text clipping, overlapping, or hidden content. Use relative units (rem, em, %) rather than fixed px for font sizes and container heights.

Touch targets are at least 24x24px (WCAG 2.2)

Interactive targets must be at least 24x24 CSS pixels in size, or have sufficient spacing from adjacent targets. This helps users with motor impairments and benefits all users on touch devices. Inline links within text and elements whose size is determined by the user agent are exempt.

Dragging actions have single-pointer alternatives (WCAG 2.2)

Any functionality that uses dragging (drag-and-drop, slider handles, map panning) must have a single-pointer alternative that doesn't require dragging. For example, a sortable list should also have move-up/move-down buttons. A slider should allow direct value input.

Content doesn't flash more than 3 times/second

No content should flash more than three times per second, as this can trigger seizures in users with photosensitive epilepsy. This applies to videos, animations, GIFs, and rapid CSS transitions. If flashing content is unavoidable, ensure it falls below the general flash and red flash thresholds.

Motion can be disabled (prefers-reduced-motion)

Respect the prefers-reduced-motion media query by reducing or removing animations, parallax effects, and auto-playing video when the user has requested reduced motion. Use @media (prefers-reduced-motion: reduce) to provide alternative styles. Non-essential animations should be eliminated; essential transitions should be minimized.

Orientation is not locked

Content must not be restricted to a single display orientation (portrait or landscape) unless a specific orientation is essential for the functionality (e.g., a piano app). Users who mount devices in a fixed orientation must still be able to use your content.

PDFs are tagged and accessible

All PDF documents must be properly tagged with a logical reading order, heading structure, alternative text for images, and table markup. Use the PDF/UA standard as a reference. Test with a screen reader and the PDF Accessibility Checker (PAC). Scanned image-only PDFs must be OCR-processed and tagged.

Downloadable documents have accessible alternatives

When providing downloadable documents (PDFs, Word docs, spreadsheets), either ensure the document itself is accessible or provide an equivalent accessible alternative (e.g., an HTML version). Indicate the file format and size in the link text so users can make informed decisions.

Consistent help mechanism across pages (WCAG 2.2)

If a help mechanism is provided (contact information, chat widget, FAQ link, support form), it must appear in the same relative location on every page. Users with cognitive disabilities rely on consistent placement to find help. Don't move the help button or support link to different positions across pages.

Status messages use ARIA live regions

Dynamic status messages (success confirmations, error alerts, loading indicators, search result counts) must be announced to screen readers without moving focus. Use role="status" for polite announcements, role="alert" for urgent messages, and aria-live="polite" or aria-live="assertive" as appropriate.

Timeouts are warned in advance

If a session timeout or data loss could occur due to user inactivity, warn the user at the start of the process about the time limit. Allow users to extend the timeout, or ensure that data is preserved for at least 20 hours so users can return and complete the task without data loss.

Content doesn't require specific timing to interact

Users must be able to interact with content at their own pace. If a time limit is set, provide a way to turn off, adjust, or extend it (with at least 10x the default). Exceptions include real-time events and situations where the time limit is essential to the activity.