This checklist maps practical, testable accessibility checks to WCAG (targeting AA) and Section 508 so developers, designers, and site owners can audit a site and prioritize fixes. It covers structure, images, forms, color, tables, and testing, then shows how to fold the results into a sprint-ready remediation plan. The goal is an audit you can act on this week, not a theory lecture. It uses a mix of automated scans and manual checks like screen reader walkthroughs.

TL;DR:

• Most accessibility issues can be fixed quickly through semantic HTML, clear headings, descriptive link text, and proper page language declaration.
• Screen reader and keyboard testing should be part of every audit, as automated tools alone cannot catch all barriers.
• Fixing structural problems in templates and core components yields benefits across the entire website, rather than tackling issues page-by-page.
• Prioritize fixes on high-traffic pages and common user flows to ensure the most impactful accessibility improvements.
• Ongoing testing, owner assignment, and integrating accessibility into the development workflow are essential for maintaining compliance.

What WCAG AA Actually Requires

WCAG organizes its success criteria around four principles known as POUR: content must be Perceivable, Operable, Understandable, and Robust. Level AA is the practical target most organizations aim for because it covers the checks that matter most for everyday use, such as color contrast, resizable text, and consistent navigation, without demanding every AAA refinement.

WCAG 2.1 Level AA is also the technical standard named in the DOJ’s small entity compliance guide for state and local government web content and mobile apps, and Section 508 policy leans on the same criteria for federal ICT. That overlap means one well-built checklist can satisfy multiple obligations at once.

DOJ guidance also permits “equivalent facilitation”: an organization can use a different technical approach than WCAG AA if it delivers equal or greater access, as long as the rationale is documented. In practice, most teams find it faster to follow WCAG directly rather than build and defend an alternative.

• Perceivable: text alternatives, captions, and sufficient contrast.
• Operable: full keyboard access and enough time to read and use content.
• Understandable: predictable navigation and clear error messages.
• Robust: markup that works across browsers and assistive technologies.

Checklist for Headings, Links, and Page Structure

Semantic HTML is the cheapest accessibility win available, and it pays off across every later fix on this list. Screen readers, browser extensions, and search engines all rely on the same structural cues, so getting this right once benefits several audiences at the same time.

1. Use one H1 per page and nest H2 through H6 in order, without skipping levels just to change text size.
2. Add a skip link at the top of the page so keyboard users can jump past repeated navigation.
3. Write link text that describes the destination, such as “download the 2026 rate sheet,” instead of “click here.”
4. Give every page a unique, descriptive title that reflects its content and position in the site.
5. Declare the page language in the HTML tag (lang="en") so browsers and assistive tools render pronunciation and formatting correctly.
6. Use real list markup (ul, ol, li) for anything that is actually a list, rather than dashes or line breaks.
7. Prefer native HTML controls, buttons, links, checkboxes, over custom-built widgets; a native <button> carries keyboard and screen reader behavior for free, while a styled <div> needs ARIA roles, states, and JavaScript to match it.

Netco Design’s own guidance on making websites accessible walks through several of these structural fixes with marketing-site examples.

Checklist for Alt Text, Captions, and Transcripts

Non-text content needs a text equivalent, but the right equivalent depends on what the image or media is doing. Getting this distinction right avoids both under-describing complex charts and over-describing simple icons.

• Write short alt text (roughly 125 characters or fewer) that states the image’s purpose, not its literal contents.
• Use a long description or an adjacent text block for complex images like infographics or flowcharts that short alt text cannot cover.
• Mark purely decorative images with an empty alt attribute (alt="") so screen readers skip them instead of reading a distracting label.
• Add captions to every video, including labels for who is speaking and notable non-speech sounds like laughter or a doorbell.
• Provide a full transcript alongside video and audio content so it is searchable and usable without playing the media.
• Add audio descriptions for videos where visual information is not covered by the existing dialogue.
• Offer a data table or plain-text summary as an alternative to charts and graphs, since screen readers cannot interpret visual trend lines.

Checklist for Keyboard Navigation and Accessible Forms

A site that cannot be operated by keyboard fails a large share of assistive technology users before they ever reach your content. Section 508 guidance on keyboard accessibility treats this as a baseline requirement, and it doubles as one of the fastest tests to run because a single pass through the tab key exposes most problems.

• Confirm every interactive element, links, buttons, menus, form fields, can be reached and activated using only the keyboard.
• Check for keyboard traps: a modal, date picker, or embedded widget should never lock focus in a way that prevents tabbing back out.
• Keep a visible focus indicator on the active element at all times, and make sure the tab order follows the visual reading order.
• Label every form field explicitly, with instructions placed before the field, not only inside a placeholder that disappears on input.
• Announce errors clearly, using visible text near the field plus an aria-live region so screen reader users hear the message without hunting for it.
• Run each form with a screen reader to confirm labels, instructions, and error messages are actually announced, not just visually present.

Pro Tip: Test your most important form, checkout, signup, contact, with the mouse unplugged before you test anything else on the page.

Checklist for Color, Contrast, and Zoomed Layouts

Color and layout problems are easy to miss visually but simple to test with the right tools. Running through this list catches issues that affect low-vision users, colorblind users, and anyone viewing your site on a small or reflective screen.

• Check contrast ratios: 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold and above).
• Use a contrast checker browser extension or an online color picker to verify ratios before shipping a new palette.
• Never rely on color alone to convey meaning, add an icon, underline, or text label alongside any color-coded status or link.
• Test the full page at 200% browser zoom and confirm text reflows without overlapping content or triggering horizontal scroll.
• Check every responsive breakpoint, not just desktop and mobile, since tablet-width layouts often get skipped in QA.
• Run a color-blindness simulator across key pages, then confirm manually that critical actions still make sense in grayscale.

Netco Design’s guide to responsive design best practices covers the layout side of this in more depth.

Making Tables and Data Displays Accessible

Tables built for layout rather than data cause some of the most confusing screen reader experiences on the web. A properly marked-up table reads in a logical order; a layout table often reads as a jumble of disconnected cells.

• Use <th> header cells with scope="col" or scope="row" so screen readers can announce which header applies to each data cell.
• Reserve tables for actual tabular data, and use CSS for visual layout instead.
• Add a caption or a brief summary above complex tables so users know what they are about to read.
• Provide a text or list alternative for critical numeric data that would otherwise sit only inside a chart.
• Confirm that sortable or filterable tables announce state changes, so a screen reader user knows when the data has been resorted.

Testing Playbook: Automated Scans and Manual Checks

Automated tools are fast and good at catching missing alt attributes, low contrast, and malformed ARIA, but they typically flag only a portion of real barriers; the rest require a human to actually try using the page.

1. Run an automated scanner (an HTML validator, a contrast checker, an ARIA linter) across every template first to catch structural errors in bulk.
2. Follow with a keyboard-only pass: unplug the mouse and try to complete a full task, like searching, filtering, and submitting a form.
3. Run a screen reader walkthrough with NVDA or VoiceOver on the same task to confirm labels, headings, and error messages are announced correctly.
4. Reproduce common failure patterns directly, a navigation menu that traps focus, a form that submits without announcing an error, a video with no captions.
5. Log every finding in an issue tracker with a severity rating and an estimated fix effort so the list can be triaged into sprints.

A high-yield test: according to Section 508 guidance, keyboard accessibility checks are among the fastest ways to expose basic usability problems, since a site that traps or skips keyboard focus is failing a broad set of users, not a narrow edge case.

Hennepin County’s testing guidance recommends picking three high-traffic flows, such as search, product view, and checkout, and running each end to end with both a keyboard and a screen reader before moving to lower-traffic pages.

Workflow and Roles: Who Owns What

Accessibility work stalls when no one owns it. A simple RACI matrix, who is Responsible, Accountable, Consulted, and Informed, keeps design, development, QA, and content teams from assuming someone else caught the issue.

• Assign a Responsible owner for each phase: designers for color and layout, developers for markup and ARIA, QA for testing, content authors for alt text and plain language.
• Build an accessibility test plan and a feature inventory that lists every interactive component and its current status.
• Keep a remediation log that tracks each finding, its severity, its owner, and its target sprint.
• Publish an accessibility statement or an Accessibility Conformance Report where relevant, especially for public-facing government or enterprise sites.
• Bake accessibility requirements into your component library and design tokens so a fixed button or form field stays fixed everywhere it is reused.

Pro Tip: Fix shared templates, header, footer, and core form components, before chasing individual page issues; template fixes propagate everywhere at once.

The Section 508 product lifecycle overview frames this as integrating accessibility across planning, design, development, testing, and maintenance, rather than treating it as a one-time audit.

Netco Design’s own site audit checklist offers a comparable structure for organizing findings and assigning follow-up work.

Prioritizing Fixes and Understanding Compliance Deadlines

Not every finding deserves equal urgency. Start with the pages and flows your visitors actually use, then work outward.

• Fix core user journeys first: homepage, navigation, search, and checkout or lead-generation forms carry the most traffic and the most risk.
• Treat quick wins, missing alt text, low contrast, missing form labels, as immediate fixes since they are usually low effort and high impact.
• Schedule medium-effort items, like reworking focus order or rebuilding error messaging, into the next sprint or two.
• Plan long-term work, such as refactoring templates or rebuilding a component library for accessibility, as its own project with dedicated time.
• If your organization is a state or local government entity, note that the DOJ’s 2024 web rule sets WCAG 2.1 AA compliance deadlines that vary depending on the entity’s population size, allowing more time for smaller entities and special district governments.
• Budget for ongoing testing time, not just a one-time fix, since new pages and features can reintroduce old problems.

Accessible PDF and Other Non-HTML Content

PDFs, slide decks, and downloadable documents follow the same WCAG principles as web pages, but they are frequently skipped during an audit because they live outside the CMS. A PDF built from a Word or InDesign file without tagging is often unreadable by a screen reader, even when the visual layout looks clean.

To make a PDF accessible, start with a tagged structure: headings, lists, and reading order need to exist in the document’s underlying tags, not just in its visual formatting. Most desktop publishing tools, including Adobe Acrobat and Microsoft Word, include a built-in accessibility checker that flags missing tags, untagged images, and reading-order problems before export.

Every image inside a PDF needs alt text the same way a web image does, and any table needs header cells rather than visually aligned columns. Forms embedded in PDFs need labeled fields, just like an HTML form, so a screen reader user can identify each field before filling it in.

Where possible, convert static PDFs into HTML pages instead, since HTML is easier to keep accessible over time and easier to update. When a PDF must remain a PDF, such as a signed contract or a regulatory filing, run it through an accessibility checker and fix flagged issues before publishing, and keep a note in your remediation log tracking which documents have been checked.

Letting Users Adjust Text Size, Motion, and Display

Accessibility is not only about fixing what is broken. It is also about giving people control over how content is presented, because a fixed design that works for one visitor can be unusable for another.

Confirm that your site respects browser-level text resizing rather than locking font sizes with fixed pixel units that ignore zoom. Support the prefers-reduced-motion media query so users sensitive to animation, including some with vestibular disorders, get a version of the page with reduced or removed motion effects. Avoid auto-playing video or audio, and when motion or autoplay is unavoidable, provide a visible pause or stop control near the content.

Some sites also offer a visible display toggle for high-contrast mode or a simplified layout, though these features work best as a supplement to solid default styling rather than a replacement for it.

Language Attributes and International Accessibility

A site’s lang attribute does more than help pronunciation. It tells assistive technology, translation tools, and search engines what language the content is written in, which affects everything from voice inflection in a screen reader to spell-check behavior in a browser.

Set the page-level language in the HTML tag, and mark any section written in a different language with its own lang attribute, such as a French pull quote inside an English article. This matters most for multilingual sites, where a language switcher needs to update the lang attribute along with the visible text, not just swap the copy.

Right-to-left languages like Arabic and Hebrew need the dir="rtl" attribute set on the relevant elements so text direction and layout mirror correctly. Date formats, currency symbols, and number formatting should also match the audience’s locale conventions, since a misread date or price is its own kind of accessibility failure. None of this replaces WCAG compliance in each language version. A translated page still needs the same alt text, contrast, and keyboard support as the original.

Where Accessibility Audits Usually Go Wrong

The most common mistake is treating an audit as a one-time event instead of a recurring check built into every release. Teams also tend to over-invest in automated tooling and skip manual keyboard and screen reader testing entirely, which misses the failures that matter most to real users.

After an audit, triage findings by severity and effort, assign an owner to each item, and schedule the quick wins into the very next sprint rather than a future backlog. Netco Design’s accessibility guidance and Lori Piencykoski’s work on standards-based audits are built around this same triage-first approach: fix what is broken for the most users first, then schedule the rest.

— Lori Piencykoski

Turning This Checklist Into a Fixed Site

Running through this checklist tells you what is broken. Fixing it, especially across templates, forms, and a component library, is where most in-house teams run out of time before they run out of findings. Some web design and development firms build mobile-first, conversion-focused sites and can fold accessibility remediation into broader engagements, so fixes land inside templates rather than as one-off patches. This is different from hiring a pure compliance auditor: you get a rebuilt, faster site alongside the accessibility fixes, with transparent communication and measurable checkpoints used on every project.

If your audit turned up structural issues across your navigation, forms, or page templates, a web design or web development engagement can address them as part of a rebuild rather than a patchwork of fixes. Reach out to discuss your audit results and get a plan for prioritizing the work.

Primary Standards to Reference

• The DOJ’s 2024 web rule sets WCAG 2.1 AA deadlines for state and local government entities.
• The Small Entity Compliance Guide explains prioritization and exceptions for public entities.
• Section508 covers federal ICT lifecycle requirements and testing artifacts.
• Guidance on Web Accessibility and the ADA outlines common barriers and remediation starting points.
• Research on accessibility and SEO overlap covers how semantic structure benefits both audiences.

Sources

• Department of Justice: Web Rule resources (2024)
• Section508
• Section508
• Accessibility of Web Content and Mobile Apps Provided by State and Local Government Entities: A Small Entity Compliance Guide

FAQ

What Are the 4 Principles of Web Accessibility?

WCAG organizes its requirements around four principles known as POUR: content must be Perceivable, Operable, Understandable, and Robust. Each principle groups related success criteria, so perceivable covers things like alt text and contrast, while operable covers keyboard access and timing.

How Do You Check if a Website Is Accessible?

Combine automated scanning tools with manual testing: a keyboard-only pass through key tasks and a screen reader walkthrough using NVDA or VoiceOver. Testing guidance from Hennepin County recommends running both automated and manual checks together, since automated tools alone miss many real barriers.

How Can I Make Sure My Website Is Accessible?

Work through a standards-based checklist covering semantic HTML, alt text, keyboard operability, form labels, color contrast, and accessible tables, then test with real assistive technology. Assigning clear ownership across design, development, and QA, along with a remediation log, keeps fixes from slipping between roles.

What Are the 4 Guidelines of WCAG?

WCAG’s guidelines sit under the four POUR principles: perceivable, operable, understandable, and robust content. Under each guideline, specific success criteria define testable requirements, and Level AA is the target most organizations, including many under DOJ web accessibility rules, aim to meet.

Recommended

• The Ultimate 10-Point Site Audit Checklist for 2026
• How to Do a Website Audit: A Practical Guide