25 Sprint Ready Tests: Website Accessibility Checklist for Developers

This is a WCAG 2.2-aligned accessibility checklist built for developers, designers, and site owners who need practical answers, not theory. Every item maps to a testable success criterion under the four WCAG principles: Perceivable, Operable, Understandable, and Robust (POUR). Your first move, before anything else: run a quick smoke test. Tab through your homepage with no mouse, run a contrast checker on your body text, and spot-check three images for real alt text.

---

TL;DR:

• Most sites fail contrast requirements, with normal text needing at least a 4.5:1 ratio and large text requiring 3:1 to meet WCAG AA standards.
• Keyboard navigation testing can reveal focus and trap issues, especially if focus indicators are hidden or focusable elements are not reachable in a logical order.
• Alt text must accurately describe the function or content of images, while decorative images should have empty alt attributes to be ignored by screen readers.
• Use semantic HTML elements like <button> and <nav> instead of ARIA roles, and verify custom widgets expose the correct name, role, and value for assistive technology.
• Automated scans identify about a third of issues, but manual testing with screen readers and keyboard navigation is essential to ensure full accessibility compliance.

---

Table of Contents

• What Is the Website Accessibility Checklist Standard? WCAG and POUR Explained
• Perceivable Checklist: Images, Contrast, and Text Alternatives
• Operable Checklist: Keyboard Navigation and Focus
• Understandable Checklist: Language, Predictability, and Clear Errors
• Robust Checklist: Semantics, ARIA, and Assistive Tech
• Forms and Controls: Labels, Validation, and Accessible Login
• Media and Time-Based Content: Captions, Transcripts, and Flashing Limits
• Content Structure: Headings, Tables, and Skip Links
• Testing Workflow: Automated Scans to Assistive-Tech Checks
• The 25-Point Sprint-Ready Accessibility Checklist
• Prioritizing and Scheduling Accessibility Fixes
• Tools and References Worth Bookmarking
• What Client Work Actually Teaches You About Accessibility
• A Faster Route to Building Accessible Sites From the Start
• Sources

What Is the Website Accessibility Checklist Standard? WCAG and POUR Explained

WCAG groups every requirement under four principles known as POUR: content must be Perceivable (available to the senses), Operable (usable by keyboard and other inputs), Understandable (clear and predictable), and Robust (compatible with assistive technology).

Conformance comes in three levels: A, AA, and AAA. AA is the practical target most legal standards and organizations reference, and it’s what this checklist builds toward. AAA covers edge cases most sites don’t need.

The current version, WCAG 2.2, adds criteria that affect everyday checklist items: Focus Not Obscured (sticky headers can’t hide the focused element) and Target Size (tap targets need enough room to hit reliably on mobile). Build your checklist around 2.2, not the older 2.1, since it’s what current accessibility guidelines and audits increasingly assume.

Perceivable Checklist: Images, Contrast, and Text Alternatives

Perceivable content means nothing important is locked behind a single sense, usually sight. Alt text is the most misunderstood piece of this. Every meaningful image needs a concise description of its function or content; purely decorative images (a background swirl, a divider graphic) should carry an empty alt="" so screen readers skip them instead of announcing “image1247.jpg.”

Contrast is where most sites fail silently. WCAG AA requires a 4.5:1 ratio for normal text and 3:1 for large text (18pt+ or 14pt bold). Run every text/background combination through a contrast checker like WebAIM’s tool before shipping a redesign.

• Confirm alt text describes function, not just appearance (“Submit order” beats “red button”)
• Verify body text meets 4.5:1 contrast; headlines meet 3:1
• Check that zooming to 200% doesn’t break layout or clip content
• Make sure no instruction relies on color alone (“click the green button” fails if someone can’t see green)

Pro Tip: Don’t trust your eyes on contrast. A color that looks fine on your calibrated monitor can fail badly on a cheap laptop screen or in bright sunlight on mobile.

Operable Checklist: Keyboard Navigation and Focus

Keyboard accessibility website testing is the single fastest way to expose real problems. Unplug your mouse and tab through your entire page. Every interactive element, links, buttons, form fields, custom widgets, needs to be reachable in a logical order, and the tab order should follow the visual flow, not the raw DOM order if they diverge.

Focus indicators matter as much as the tabbing itself. A common mistake is stripping the default outline with outline: none and never replacing it, which leaves keyboard users with no idea where they are on the page. Build a custom focus style with enough contrast to be visible against every background, then test it.

• Tab through the entire page; confirm every interactive element is reachable
• Replace any removed focus outline with a visible custom style, never delete it outright
• Check modals and dropdowns for keyboard traps (can you Tab or Escape out?)
• Confirm touch targets are at least 24x24 pixels per WCAG 2.2’s Target Size criterion

Pro Tip: Adding tabindex="0" makes a <div> focusable, but it doesn’t give it button behavior. You still have to script the Enter and Space key handlers yourself, or the “button” will do nothing when a keyboard user presses it. Keyboard accessibility isn’t a niche concern, either. It benefits power users, people with temporary injuries, and anyone relying on focus indicators just as much as it does people with permanent motor disabilities.

Understandable Checklist: Language, Predictability, and Clear Errors

Understandable content behaves the way users expect. Set the page’s lang attribute correctly (lang="en"), and tag any foreign-language phrases within the content so screen readers switch pronunciation instead of mangling them.

Navigation should stay consistent across pages. If the main menu is in the header on your homepage, it shouldn’t jump to a sidebar on your blog. Predictability extends to form errors too: when someone fumbles an email field, the message should say exactly what’s wrong and how to fix it, not just flash red.

• Set the correct lang attribute site-wide and tag embedded foreign phrases
• Keep navigation, menu order, and button placement consistent across templates
• Write error messages that state the problem and the fix (“Enter a valid email, like name@example.com”)
• Label every interactive control with text, not just an icon or placeholder

Robust Checklist: Semantics, ARIA, and Assistive Tech

Robust means your code works reliably across browsers, devices, and assistive technology, now and as those tools evolve. The rule that saves the most trouble: prefer semantic HTML over ARIA whenever a native element exists. A <button> already has keyboard support and screen reader semantics built in; a <div role="button"> has neither unless you add them yourself.

When you do need ARIA for a custom widget, expose name, role, and value programmatically, and test the result with an actual screen reader.

• Use <button>, <nav>, <table>, and other native elements before reaching for ARIA
• For custom widgets, confirm name, role, and value are announced correctly
• Test dynamic content updates (live regions, modals) with NVDA, JAWS, or VoiceOver
• Avoid redundant or conflicting ARIA roles on elements that already have native semantics

Forms and Controls: Labels, Validation, and Accessible Login

Forms are where accessibility failures cost real conversions, not just compliance points. Every input needs a persistent, programmatically associated <label>. Placeholder text that disappears on focus is not a label; once someone starts typing, the field’s purpose vanishes with it.

Validation should be inline, specific, and never color-only. WCAG 2.2 also pushes accessible authentication: give users an alternative to memory-based tests like puzzle CAPTCHAs, and support password managers and copy-paste in login fields rather than blocking them.

• Pair every input with a visible, persistent <label>, not a placeholder
• Flag errors inline with text and an icon, never color alone
• Allow paste and autofill in password and login fields
• Offer an alternative to cognitive-function tests (CAPTCHA) per WCAG 2.2’s authentication guidance

Media and Time-Based Content: Captions, Transcripts, and Flashing Limits

Video and audio content need multiple ways in. Captions cover dialogue for video; transcripts serve audio-only content like podcasts and let search engines index the words too. Media controls (play, pause, volume, captions toggle) must be reachable by keyboard, same as everything else on the page.

If a video conveys information visually that isn’t spoken, an audio description track needs to fill that gap. And anything that flashes should stay under three flashes per second, full stop, since faster rates can trigger seizures in people with photosensitive epilepsy.

• Add captions to every video and transcripts to standalone audio
• Confirm media player controls are keyboard-operable
• Add audio description tracks when visual info isn’t spoken aloud
• Keep flashing content under three flashes per second and provide a pause/stop control

Content Structure: Headings, Tables, and Skip Links

Structure is what lets a screen reader user “skim” a page the way a sighted user’s eyes jump around it. One <h1> per page, followed by a logical heading hierarchy (h2 then h3, never skipping levels for visual styling), turns your headings into a navigable outline instead of decoration.

Tables should hold tabular data only, with <th> elements and scope attributes so a screen reader can announce which header a cell belongs to. A skip link at the top of the page lets keyboard users jump past the navigation, but it only works if it targets an element that can actually receive focus, like the main content container with tabindex="-1".

• Use exactly one <h1> and keep heading levels sequential
• Reserve <table> markup for real tabular data, with proper <th scope> attributes
• Add a skip-to-content link pointed at a genuinely focusable target
• Keep navigation landmarks (<nav>, <main>, <footer>) consistent site-wide

Testing Workflow: Automated Scans to Assistive-Tech Checks

A dependable testing sequence starts fast and gets more thorough: automated scans first, manual keyboard and screen reader passes second, real user testing where possible third. Automated tools flag maybe a third of real issues; the rest need a human.

1. Run an automated scanner (axe DevTools, WAVE, or Lighthouse) across key templates
2. Tab through every page with no mouse, checking focus order and traps
3. Test with at least one screen reader (NVDA on Windows, VoiceOver on Mac/iOS)
4. Check color contrast on every unique text/background pairing
5. Re-test each fixed item against its specific WCAG success criterion before closing the ticket

Test type	Tool or method	Catches
Automated scan	axe DevTools, WAVE, Lighthouse	Missing alt text, contrast failures, missing labels
Keyboard pass	Tab, Shift+Tab, Enter, Escape	Focus order, traps, missing focus styles
Screen reader	NVDA, JAWS, VoiceOver	Announcement errors, broken ARIA, reading order
Zoom/resize	Browser zoom to 200%	Layout breaks, clipped or overlapping content

Document every finding against its WCAG success criterion number, not just a vague “accessibility issue,” so re-testing after a fix is a one-line comparison instead of a guessing game.

The 25-Point Sprint-Ready Accessibility Checklist

Paste this into your ticketing system as-is. Each line is a pass/fail test, which is what makes a checklist stick with a team instead of getting ignored after the first sprint.

1. All body text meets 4.5:1 contrast, headlines meet 3:1
2. Every meaningful image has descriptive alt text
3. Decorative images use alt=""
4. Full page is navigable by keyboard alone
5. Tab order matches visual/logical order
6. Focus indicator is visible on every interactive element
7. No keyboard traps in modals, menus, or widgets
8. Touch targets are at least 24x24 pixels
9. Every form input has a persistent, associated label
10. Error messages state the problem and a fix
11. No information conveyed by color alone
12. Page lang attribute is set correctly
13. One <h1> per page, sequential heading levels below it
14. Navigation is consistent across templates
15. Tables use <th scope> for headers
16. Skip link targets a focusable element
17. ARIA used only where semantic HTML can’t do the job
18. Custom widgets expose name, role, and value
19. All videos have captions
20. Standalone audio has a transcript
21. Media controls are keyboard-operable
22. No content flashes more than three times per second
23. Page layout holds at 200% zoom
24. Login fields allow paste and autofill
25. Every fixed item is re-tested against its WCAG criterion

Prioritizing and Scheduling Accessibility Fixes

Triage by real-world impact, not by how easy a fix looks. Critical: blocks task completion (keyboard traps, missing form labels, unreachable navigation). High: contrast failures, missing alt text on key content. Medium: heading structure issues, inconsistent focus styles. Low: minor semantic cleanup with no user-facing effect.

• Fix critical and high items within the current sprint; they’re usually small, isolated changes
• Batch medium items into the next sprint once you’ve confirmed a fix pattern
• Close a ticket only after re-testing against the specific success criterion it violated

Pro Tip: Most “quick wins” (adding alt text, fixing a label, restoring a focus outline) take under an hour each but clear a disproportionate share of your audit findings. Knock those out before tackling anything architectural.

Tools and References Worth Bookmarking

Automated scanners (axe DevTools, WAVE, Lighthouse) catch the mechanical failures fast; manual keyboard and screen reader testing catches everything else. Keep the WCAG 2.2 quick reference open while triaging, since it links every success criterion to plain-language guidance.

• axe DevTools or WAVE for automated scanning
• A contrast checker (WebAIM’s is free and fast)
• NVDA or VoiceOver for screen reader testing
• The accessibility angle also pays off in search visibility, since many of the same fixes that help assistive tech also help crawlers parse your content

What Client Work Actually Teaches You About Accessibility

The gap between “we ran a scanner” and “this actually works” is where most projects fail. Automated tools miss keyboard traps, confusing focus order, and ARIA that’s technically valid but practically useless to a screen reader. Teams that treat accessibility as a one-time audit before launch, rather than a recurring check baked into every sprint, watch their score quietly decay as new features ship.

The fix isn’t more documentation. It’s smaller, more frequent checks: a keyboard pass on every pull request that touches interactive UI, not a once-a-year fire drill.

A Faster Route to Building Accessible Sites From the Start

Retrofitting accessibility into a site built with inconsistent, one-off components is slow work. Some AI website builders take an approach where you describe the site you want in plain language, and reusable components carry consistent semantics, labeling, and focus behavior across every page generated, instead of rebuilding the same form pattern multiple ways across different pages.

That consistency doesn’t replace this checklist. You still need to run contrast checks, tab through your pages, and test with a screen reader, since no builder guarantees WCAG conformance automatically. What it does is cut the amount of one-off custom code you have to individually audit and fix. With many built-in integrations for things like payments and lead capture, you can focus your testing time on content and layout choices rather than re-checking hand-rolled widgets. If you’re weighing a rebuild anyway, try the AI website builder and see how far a consistent component library gets you before your first accessibility audit, then check the pricing plans to find the tier that fits your project.