Use this WCAG-based checklist to quickly evaluate the most common A and AA accessibility gaps and start remediation today. WCAG 2.2 is our baseline, organized into perceivable, operable, understandable, robust, and testing and process checks. Start now: run an automated scan, then do a five-minute keyboard and screen-reader pass on your login, checkout, or search flow.
TL;DR:
- Meet WCAG AA contrast targets of 4.5:1 for normal text and 3:1 for large text, and verify content survives 200% zoom.
- Run automated scans on every build, but manually test critical flows with a keyboard and screen reader at least once per release.
- Give every form field a visible, associated label, and ensure specific validation errors move focus to the affected field for screen reader users.
- Use native HTML before ARIA, and test custom controls with assistive technology because redundant roles and visual state cues can confuse announcements.
- Make mobile touch targets at least 44 by 44 pixels, and provide visible alternatives for actions that otherwise require swipes or multi finger gestures.
Perceivable checklist: text, color, images, and media
Perceivable content means people can get the information regardless of how they experience your site: by sight, by ear, or through a screen reader. This is where most quick wins live.
Text alternatives for images fall under WCAG's text alternatives guidance. Every meaningful image needs alt text that describes its purpose, not just its contents. Decorative images get an empty alt="" so screen readers skip them instead of reading a filename out loud.
Contrast is the single highest-impact check for low-vision readers. WCAG's AA target is a 4.5:1 ratio for normal text and 3:1 for large text (18pt or 14pt bold and above).
Captions and transcripts matter for any video or audio content. Captions cover dialogue and key sounds; transcripts help people who process text faster than audio, and they also help search engines index your content.
Quick checklist for this section:
- Run an automated scanner for missing alt attributes and low contrast across every template.
- Manually zoom to 200% and confirm text reflows without loss of content or function.
- Check every video has synchronized captions and a text transcript available nearby.
- Scan for color-only distinctions (like red text meaning "error") and add an icon or label.
- Verify form fields and buttons have visible, descriptive labels, not just placeholder text.
Pro Tip: Write alt text the way you'd describe the image over the phone: "Red sedan parked in front of a brick building," not "image123.jpg" or "photo of car."
A practical authoring pattern: write alt text at the same time you upload an image, inside your CMS, rather than leaving it for a later accessibility pass. It almost never gets done later.
Operable checklist: keyboard and navigation checks
Operable means a person can use every interactive part of your site without a mouse. Keyboard testing is the fastest way to catch major gaps, and it takes minutes once you know the pattern.
- Tab through your homepage, then your primary conversion flow (login, checkout, or contact form), confirming every link, button, and form field is reachable in a logical order.
- Confirm a visible focus indicator appears on every focused element: a browser's default outline is fine, a custom one just needs to be clearly visible against the background.
- Test for keyboard traps: open a modal or dropdown, then try to tab or press Escape out of it. If focus gets stuck, that is a hard blocker.
- Add a "skip to main content" link at the top of the page so keyboard users do not have to tab through full navigation on every page load.
- For modals and dialogs, confirm focus moves into the dialog when it opens and returns to the triggering element when it closes, a pattern tied to
role="dialog"and managed focus.
Tool-assisted checks (automated scanners flagging missing focus styles or tab order issues) catch the obvious cases. Manual testing catches the rest: try completing a full purchase or sign-up using only Tab, Shift+Tab, Enter, and Escape.
Pro Tip: When focus order feels wrong, inspect the DOM order first; focus generally follows source order, not visual layout, so a CSS-only reorder is often the actual bug. Test the fix in a real screen reader like NVDA or VoiceOver, not just visually.
Understandable checklist: headings, link text, and form clarity
Understandable content behaves the way people expect it to. That starts with structure: headings should form a logical outline (one H1, then H2s and H3s in order) so screen reader users can jump between sections instead of reading linearly.
Link text needs to make sense without surrounding context. "Click here" or "read more" tells a screen reader user nothing when they pull up a list of links on the page; "Download the 2026 pricing guide" does.
Checklist items:
- Avoid instructions that rely on sensory position alone, like "click the button on the right," since layout can shift with zoom or screen reader navigation.
- Keep sentences and paragraphs reasonably short; dense legal or technical language should link out to a plain-language summary where possible.
- Confirm content reflows cleanly for assistive tech, meaning no information is conveyed only through visual layout or hover states.
Forms deserve their own pass. Every input needs a visible, programmatically associated label, not just a placeholder that disappears on focus. Complex instructions (password requirements, format examples) work well with aria-describedby pointing to a visible instruction block. Error messages should say specifically what is wrong ("Phone number must include area code") and move focus to the first error field so screen reader users do not have to hunt for it.
A simple author workflow: before publishing, read your heading outline alone, read every link text out of context, and read each form error message as if you just saw it for the first time.
Robust checklist: semantic HTML, ARIA, and assistive technology compatibility
Robust content works reliably across browsers, devices, and assistive technology, including tools that do not exist yet. The surest way to get there is boring, native HTML.
- Use real
button,nav,header,main, andtableelements instead of styleddivs; native elements come with built-in keyboard support and semantics for free. - Reach for ARIA only when HTML cannot express the pattern, like a custom tab panel or a live region for dynamic status updates.
- Avoid the common pitfall of adding ARIA roles to elements that already have the right native role, which can create conflicting or redundant announcements.
- Verify accessible names using your browser's accessibility tree inspector (Chrome DevTools' Accessibility pane or Firefox's Accessibility Inspector) rather than assuming the visual label is what gets announced.
- Cross-check your primary flows in at least two screen reader and browser combinations, since rendering and announcement behavior can differ.
The W3C's techniques documentation is informative guidance, not the only path to meeting a success criterion: content can satisfy WCAG in more than one way, and passing a specific technique test does not by itself prove conformance. Real-world browser and assistive-technology support is what ultimately matters, so test with current versions rather than relying on technique checklists alone.
Pro Tip: Log accessibility bugs the same way you log functional bugs: specific element, specific assistive technology, specific expected versus actual behavior, so your dev team can reproduce and fix them without guesswork.
Forms, tables, and controls: focused checks
These three areas cause a disproportionate share of real-world accessibility failures, so they deserve dedicated review during code review and QA, not just a general pass.
- Forms: confirm every field has a visible label tied to it with a
for/idpair, required fields are marked both visually and programmatically, complex instructions usearia-describedby, and validation errors are announced and move focus to the relevant field. - Tables: use
<th>withscope="col"orscope="row"for data tables, never use a table purely for visual layout, and add a<caption>or summary for complex tables so the relationship between data and headers is clear. - Custom widgets: any custom dropdown, slider, or tab panel needs full keyboard operability, a correct accessible name and role, and state changes (expanded, selected, checked) that are exposed to assistive tech, not shown through color or icon alone.
Build these three into a shared code review checklist. A form field without a label, a layout table mistaken for data, or a custom widget missing a role are the three most common findings in real accessibility audits, and all three are caught in minutes with a keyboard and a screen reader.
Testing and validation workflow: combine automated scans and manual QA
No single tool catches everything, and no single method does either. A hybrid test strategy pairs broad automated scans with targeted manual QA and scheduled sessions with people who use assistive technology.
Automated scanners (linters, WCAG spiders, contrast checkers) are fast and catch a wide net of structural issues: missing alt text, poor contrast, missing form labels, invalid ARIA attributes. They cannot judge whether alt text is meaningful, whether tab order makes sense, or whether an error message is actually helpful. That is where manual testing and real user testing come in.
Recent Section 508 assessment findings show organizations increasingly rely on hybrid testing, combining automated and manual methods, because manual and user testing catch issues automated tools consistently miss. That finding supports building both into your standard release process, not treating either as optional.
A practical cadence:
- Run automated scans on every build or pull request, gating merges on new critical failures.
- Schedule full manual keyboard and screen reader walkthroughs of top-traffic and conversion-critical flows each release.
- Recruit at least one person who regularly uses assistive technology into acceptance testing for high-risk or newly built features.
- Keep a remediation backlog ranked by user impact, not just by how easy a fix is.
In CI/CD, add accessibility linters and a baseline automated scan as a gating check, similar to how you'd gate on failing unit tests. Schedule a periodic full-site scan (monthly or quarterly) to catch drift that per-pull-request scans miss, since new third-party scripts or content changes can introduce regressions outside your code review path.
Integrating accessibility into the project lifecycle and governance
Accessibility holds up best when it is a requirement from the start, not a pass applied before launch. Section 508 playbooks recommend folding accessibility testing into the full ICT lifecycle rather than treating it as a one-time audit.
- Add accessibility criteria to your "definition of done" for every user story, not just a separate backlog item.
- Assign a clear owner for accessibility decisions on each project, even if it is a shared responsibility across the team.
- Train designers and developers on the basics (semantic structure, keyboard operability, color contrast) so issues get caught before code review.
- Set a remediation SLA for newly found issues based on severity, and track a small set of KPIs like percentage of pages passing automated baseline scans.
For teams starting from zero, a simple 30/60/90 plan works well: in the first 30 days, run a full automated scan and fix the highest-volume issues (alt text, contrast, labels). In 60 days, complete manual keyboard and screen reader testing on your top three flows. By 90 days, have accessibility checks gating your CI/CD pipeline and a recurring testing cadence in place.
Mobile accessibility considerations specific to touch interfaces and mobile screen readers
Mobile introduces checks that do not exist on desktop. Touch targets need enough space to tap accurately, generally at least 44 by 44 pixels, since a cramped target is a usability problem for anyone with limited fine motor control, not just screen reader users.
Gestures need a non-gesture alternative. If a feature only works by swiping, pinching, or a multi-finger gesture, some users with motor impairments or certain assistive tech configurations cannot trigger it at all, so pair every gesture-based action with a visible button or menu option.
Mobile screen readers (VoiceOver on iOS, TalkBack on Android) navigate by swiping between elements rather than tabbing, so test your reading order the same way: swipe through your page start to finish and confirm the order matches the visual flow and that nothing gets skipped or announced twice.
Orientation and zoom matter more on mobile. Avoid locking content to a single orientation unless the content genuinely requires it (like a game), and confirm pinch-to-zoom is not disabled through a restrictive viewport meta tag, since disabling zoom removes a core accommodation for low-vision users.
Finally, check that your mobile menu and modal patterns trap focus correctly within an open panel and release it cleanly when closed, the same focus management test from desktop, just on a smaller screen where mistakes are easier to miss during a quick visual check.
Color blindness and other specific visual impairment accommodations beyond general contrast
Contrast ratios solve part of the problem, but color blindness affects how people distinguish hues, not just how light or dark something looks. Red/green color blindness is the most common pattern, which makes red "error" and green "success" indicators risky if color is the only signal.
Pair every color-coded meaning with a second cue: an icon, a text label, or a pattern. A status dot that is red or green should also say "Failed" or "Passed" next to it, or use distinct shapes.
For charts and graphs, avoid relying on a red-to-green gradient alone; use distinguishable patterns or direct labels on data points instead. Run your key screens through a color blindness simulator to check that critical information still reads clearly when red-green or blue-yellow distinctions are removed.
Beyond color blindness, consider low-vision users more broadly: support browser-level text resizing up to 200% without breaking layout, avoid justified text that creates uneven word spacing, and give users control over auto-advancing carousels or flashing content, since fast flashing can also trigger photosensitive seizures for some users and should generally be avoided outright.
Cursor and focus visibility matters here too. A thin, low-contrast focus outline that is technically "there" may be invisible to someone with reduced visual acuity, so test focus indicators at actual size, not just in a code review.
Internationalization and multilingual accessibility considerations
Accessibility and internationalization overlap more than most checklists admit. Set the lang attribute on your HTML element, and update it on any page section written in a different language, so screen readers switch pronunciation rules correctly instead of reading French text with English phonetics.
Text expansion is a real layout risk. Test your layouts with your longest target language, not just English, before calling a translated page done.
Right-to-left languages like Arabic and Hebrew need mirrored layouts, not just translated text, including navigation order, icon direction, and form field alignment. If you support RTL at all, test it with an actual keyboard and screen reader pass, not just a visual flip.
Date formats, number formats, and currency symbols should match local conventions, since a misread date or amount is a comprehension failure as much as an accessibility one. Finally, make sure any language switcher is itself keyboard accessible and clearly labeled, since it is often one of the first elements a multilingual user looks for.
What practical accessibility audits teach you
Checklists are a starting point, not a guarantee. The gap between a site that passes an automated scan and a site that actually works for a person using a screen reader or a switch device is usually found in the details a scanner cannot judge: whether alt text is actually useful, whether an error message actually helps, whether a custom dropdown actually behaves like a dropdown.
The most common mistake we see is treating accessibility as a one-time project instead of an ongoing practice baked into code review and QA. A site can pass an automated scan completely and still fail basic keyboard navigation on its checkout flow. The second most common mistake is skipping real assistive technology testing entirely and trusting automated results as the full picture.
We apply this checklist approach directly in projects and encourage a simple starting point: run the scan, test the top three flows by keyboard and screen reader this week, then build from there.
— Loic
How we help you put this checklist into practice
Running through this checklist takes time most teams do not have alongside a full product roadmap. We offer web design and development work that builds accessibility checks into the process from day one, rather than treating it as a separate audit bolted on at the end.
Our app development projects apply the same keyboard, screen reader, and semantic HTML checks covered here to mobile and web platforms, and our AI and automation work looks at how automated workflows interact with accessible interfaces rather than working around them. If you are weighing a published accessibility statement for your own site, Blistr's accessibility statement is a useful model to reference for structure and tone.
If you want a second set of eyes on where your site currently stands against this checklist, reach out through our services page to scope an audit or remediation engagement.
FAQ
What are the 4 principles of web accessibility?
The four principles are perceivable, operable, understandable, and robust, often shortened to POUR, and they form the structure of WCAG 2.2. Every success criterion in WCAG falls under one of these four principles.
What are the essentials of web accessibility?
The essentials include text alternatives for images, sufficient color contrast, full keyboard operability, clear headings and link text, accessible forms with visible labels, and semantic HTML that works with assistive technology. Testing with an automated scan plus manual keyboard and screen reader checks covers most critical gaps.
What are the 4 guidelines of WCAG?
WCAG organizes its success criteria under the four POUR principles rather than exactly four guidelines; each principle (perceivable, operable, understandable, robust) contains multiple guidelines and success criteria at levels A, AA, and AAA. Most legal and government standards reference level AA as the practical target.
How often should I run accessibility testing?
Run automated scans on every build, and schedule manual keyboard and screen reader testing on critical flows at least once per release cycle. Section 508 assessment findings show hybrid testing, combining automated and manual methods, produces better coverage than either approach alone.
Does WCAG conformance guarantee ADA compliance?
WCAG is a technical standard, while the ADA is a law, and Ada references WCAG 2.1 Level AA as the current baseline for many government websites. Meeting WCAG AA is the most widely accepted way to demonstrate a good-faith effort toward accessibility, but legal compliance ultimately depends on your specific jurisdiction and context.
Sources
Bookmark these for ongoing work:
- Web Content Accessibility Guidelines (WCAG) 2.2 — Overview
- Ada
- Section 508 Assessment (FY 2024) — Testing lifecycle findings
Turn this checklist into a one-page printable version for QA handoffs so testers do not need to reread the full article each release.
