Developer WCAG Checklist: Scan, Keyboard, and Screen Reader Tests

This is a developer-ready checklist built on WCAG A and AA success criteria, and your next action should be a two-step verification: run an automated scan across your site, then perform a keyboard and screen reader smoke test on your main templates. The sections below map each checklist item to its WCAG reference and explain how to confirm compliance.

TL;DR:

• Most public sites should meet WCAG Level AA standards, with a focus on contrast, form labeling, keyboard access, and semantic HTML.
• Automated scans can identify contrast issues, missing alt text, and markup errors, but manual keyboard and screen reader testing catches interaction and focus problems.
• Every meaningful image needs descriptive alt text, decorative images require empty alt attributes, and color should never be the sole conveyance of information.
• Keyboard navigation must be verified by tabbing through all elements, checking focus visibility, and ensuring no traps or inaccessible controls exist.
• Accessibility should be integrated into the development process through component libraries and regular audits to prevent regressions.

Table of Contents

• How WCAG levels shape your accessibility priorities
• Checklist for perceivable content: images, contrast, and language
• Checklist for operable interfaces: keyboard access and focus
• Checklist for understandable content: headings, links, and instructions
• Checklist for robust code: native HTML before ARIA
• Checklist for accessible forms and input handling
• Checklist for tables and lists: real semantics matter
• Checklist for accessible video and audio content
• How to test and verify accessibility before launch
• How our in-house team builds accessibility into every project
• Get an accessible-first website built the right way
• Sources
• FAQ

How WCAG levels shape your accessibility priorities

WCAG organizes requirements into three conformance levels: A, AA, and AAA. Level A covers the most basic barriers, AA adds requirements that most public-facing sites need to meet, and AAA covers enhanced criteria that are often impractical for full-site compliance. Many organizations and regulations target AA, and the Department of Justice’s rule for state and local government sites specifically adopts WCAG 2.1 Level AA as its technical standard.

Reading a success criterion is straightforward once you know the pattern: each one has a plain-language description, a conformance level, and testable conditions. The WCAG quick reference lets you filter by level and topic, which makes it useful as a working checklist rather than just documentation.

A few mappings worth knowing before you start testing:

• Contrast requirements trace back to success criteria 1.4.3 and 1.4.11, covering text and non-text elements.
• Form labeling falls under 4.1.2, which governs name, role, and value for interactive components.
• Keyboard access is covered broadly under the 2.1 criteria group.

The ADA’s web guidance also lists common barriers businesses should address, including poor contrast, missing alt text, and inaccessible forms, and points to WCAG and Section 508 as the relevant technical resources.

Checklist for perceivable content: images, contrast, and language

Perceivable content means users can identify what’s on the page regardless of how they access it. Start with images: every meaningful image needs alt text that describes its function or content, while purely decorative images should carry an empty alt="" so screen readers skip them instead of reading a filename aloud.

Color contrast is one of the most common failures the ADA guidance flags, and it has a specific numeric target.

Minimum contrast ratios: 4.5:1 for normal text and 3:1 for large text, per WCAG success criterion 1.4.3. Tools like WebAIM’s Contrast Checker or the Chrome DevTools accessibility panel can confirm ratios before you ship.

Run through this list on every template:

• Write alt text that describes purpose, not appearance (“submit order” rather than “blue button”).
• Mark purely decorative images with empty alt attributes so they’re skipped by assistive tech.
• Never rely on color alone to convey meaning: add an icon, label, or pattern alongside color-coded states.
• Set the lang attribute on the html tag and update it for any content in a different language.

Checklist for operable interfaces: keyboard access and focus

If a user can’t operate a feature with a keyboard alone, it fails accessibility regardless of how it looks. This section catches the interaction barriers that automated scanners often miss.

1. Tab through every interactive element on the page and confirm you can reach and activate all of it without a mouse.
2. Watch for a visible focus indicator at each stop. If focus disappears or jumps unpredictably, fix the tab order in the markup rather than patching it with JavaScript.
3. Check for keyboard traps, meaning any widget you can tab into but not out of (modal dialogs and custom date pickers are frequent offenders).
4. Replace hover-only menus and tooltips with equivalents that also respond to focus, and provide button-based alternatives to drag-and-drop or gesture controls.
5. For any time-limited content, such as session timeouts or auto-advancing carousels, give users a way to extend, pause, or turn off the timer.

Pro Tip: Unplug your mouse for ten minutes and navigate your homepage, a form, and a modal using only Tab, Shift+Tab, and Enter. Most keyboard traps surface within the first few minutes.

Checklist for understandable content: headings, links, and instructions

Content should behave predictably so users can build a mental map of the page and know what will happen before they click. That starts with structure: headings should run in logical order, from h1 through h6, without skipping levels just to get a certain font size. Screen reader users often navigate by jumping between headings, so a broken hierarchy makes the page harder to scan than a sighted user would ever notice.

Link text needs to make sense on its own, since screen readers can list all links on a page out of context. “Read more” tells a user nothing; “read more about accessible form design” does.

A few more checks worth running:

• Confirm visible labels match the accessible name read by assistive technology, especially on custom form controls.
• Add inline instructions for unusual input formats (a date field expecting MM/DD/YYYY, for example) before the user submits and gets an error.
• Write error messages that state what went wrong and how to fix it, not just “invalid entry.”

Checklist for robust code: native HTML before ARIA

Native HTML elements come with accessibility built in, which is why developer guidance consistently recommends starting there. A <button> already announces its role, responds to Enter and Space, and receives focus automatically. A <div> styled to look like a button gets none of that unless you rebuild it manually with ARIA, which is more work and more prone to error.

MDN’s accessibility guidance recommends native elements first and reserves ARIA for cases where no native equivalent exists, such as a custom tab panel or a live region for dynamic alerts.

When ARIA is necessary, these checks matter:

• Use the correct role for the widget you’re building, and verify it against the ARIA Authoring Practices patterns rather than guessing.
• Confirm required properties and states (aria-expanded, aria-checked, and similar) update as the component’s state changes.
• Validate your HTML and test the final markup with a screen reader, since ARIA attributes that look correct in code can still announce incorrectly.

Checklist for accessible forms and input handling

Forms generate more accessibility complaints than almost any other page element, largely because labels and error states get overlooked under deadline pressure.

1. Give every input a <label> connected through the for attribute, or use aria-labelledby when a visible label isn’t practical.
2. Choose the correct input type (email, tel, number) and add autocomplete attributes on contact and payment fields so browsers can assist users who rely on autofill or voice input.
3. Show inline error messages next to the field that caused the problem, not just in a summary at the top of the form.
4. Use aria-live regions for dynamic alerts, like a “your session is about to expire” message, so screen reader users are notified without needing to refocus the page.
5. Offer a specific suggestion for fixing the error (for example, “enter a 10-digit phone number”) instead of a generic “field required.”

Checklist for tables and lists: real semantics matter

Tables and lists communicate structure, and that structure disappears for screen reader users when the underlying markup doesn’t match the visual layout.

• Use <th> elements with the scope attribute (or headers/id pairs for complex tables) so assistive tech can announce which header applies to each cell.
• Add a <caption> when a table’s purpose isn’t obvious from surrounding text.
• Avoid using tables purely for visual layout; if you inherit one you can’t rebuild immediately, mark it as presentational and don’t add header markup that implies false structure.
• Use real <ul> and <ol> elements for lists so screen readers announce item counts and list boundaries correctly, rather than styling plain paragraphs to look like a list.

Checklist for accessible video and audio content

Media accessibility gets overlooked because it works fine for sighted, hearing users, but it fails completely for anyone who can’t see the screen or hear the audio.

• Provide synchronized captions for every prerecorded video and an accurate transcript for standalone audio content.
• Add audio descriptions when the visual track conveys information that the audio alone doesn’t cover, such as on-screen text or a silent demonstration.
• Make sure the media player’s controls (play, pause, volume, captions toggle) are reachable and operable by keyboard, and that each control has a clear accessible label rather than an unlabeled icon.

How to test and verify accessibility before launch

Automated tools are fast and repeatable, but they only catch a portion of real issues. According to W3C guidance on evaluating accessibility, automated scans reliably flag things like missing alt text or contrast failures, but they miss interaction problems and content-in-context issues that only a human tester notices, which is why a hybrid approach matters.

A workflow that catches most gaps looks like this:

• Run an automated scanner (Axe, WAVE, or Lighthouse) across your key templates for broad, fast coverage.
• Walk through the same pages using only a keyboard, checking tab order, focus visibility, and trap-free navigation.
• Complete at least one full screen reader pass, using VoiceOver on macOS or NVDA on Windows, on your most-used pages.
• Sample actual CMS-generated output, such as live product pages or search results, not just your design templates, since generated content often introduces its own accessibility failures.
• Add an accessibility check to your release or deployment checklist so new features don’t reintroduce old problems.

Pro Tip: Schedule a recurring re-scan every quarter. Content teams add new pages faster than most QA processes catch accessibility drift.

How our in-house team builds accessibility into every project

Accessibility works best when it’s part of the build process rather than a fix applied afterward. Our team bakes accessibility checks into component libraries so buttons, forms, and navigation patterns are compliant by default before a single page goes live. We pair automated scanning with manual keyboard and screen reader passes, and we train the people who add content afterward so a new blog post or product listing doesn’t undo the work already done on the template.

— Online Marketing Experts

Get an accessible-first website built the right way

Running through a checklist tells you where the gaps are; closing them across an entire site, especially one with a CMS, forms, and years of legacy content, takes more hands than most in-house teams have free. A single in-house team can handle accessibility audits, remediation, and accessible-first design, addressing scan flags without handoffs between agencies.

An audit starts with an automated scan paired with manual keyboard and screen reader testing across your key templates and a sample of your actual content, the same process outlined above. From there, remediation addresses the specific WCAG success criteria your site is missing, whether that’s contrast, form labeling, or ARIA misuse, and new builds are designed accessible from the first wireframe rather than patched later. If you’re planning a new site or need your current one reviewed, visit our website design page to request an accessibility audit and see how remediation fits into your project timeline.

Sources

• Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities
• Evaluating web accessibility — considerations for automated and manual testing

FAQ

What are the four principles of web accessibility?

WCAG is built around four principles known by the acronym POUR: perceivable, operable, understandable, and robust. Each principle groups related success criteria, such as color contrast under perceivable or keyboard access under operable, and together they form the structure the WCAG quick reference uses to organize every testable requirement.

How do you check if a website is accessible?

Start with an automated scanner like Axe, WAVE, or Lighthouse to catch common issues such as missing alt text or contrast failures. Follow that with manual testing, including a full keyboard-only walkthrough and at least one screen reader pass, since automated tools miss interaction and context problems that only manual testing reveals.

How can I make sure my website is accessible?

Work through a checklist mapped to WCAG success criteria, covering alt text, contrast, keyboard navigation, form labels, and semantic HTML, then verify each item with both automated scans and manual testing. Testing actual CMS-generated pages, not just design templates, catches issues that only appear in live content.

What are the four guidelines of WCAG?

WCAG’s four guidelines correspond to its core principles: perceivable, operable, understandable, and robust, each containing specific success criteria at levels A, AA, and AAA. Most public-facing sites target Level AA, which is also the standard the DOJ adopted for state and local government websites.

Is web accessibility legally required?

Requirements depend on the type of organization and jurisdiction, so check primary guidance for your specific situation rather than assuming one rule applies universally. The ADA’s web guidance is a useful starting point for understanding common expectations and recommended standards like WCAG.