ultimate-guide
Website Accessibility Audit Checklist 2026
Table of Contents
- What a Website Accessibility Audit Checklist Must Cover in 2026
- Accessible Canada Act Digital Requirements: What Applies to Your Site
- Common WCAG 2.2 Failure Points and How to Spot Them
- Automated vs Manual Accessibility Testing: Where Each One Fails
- Accessibility Audit Tools for Developers and QA Teams
- Post-Audit Remediation Workflow: From Findings to Fixes
- Budgeting, Resourcing, and Verifying Compliance
- Frequently Asked Questions
Last Updated: September 11, 2026
What a Website Accessibility Audit Checklist Must Cover in 2026
A website accessibility audit checklist is a structured set of tests that verifies whether a site meets recognized accessibility standards, most commonly WCAG 2.2 at Level AA. This guide from Elevated Digital covers what to test, which rules apply to your organization, how automated and manual testing divide the work, and how to move from findings to fixes.
The scope has widened: accessibility now touches procurement, compliance obligations, and the way AI-generated content enters your CMS. A checklist that stops at alt text and color contrast will pass a spot check and fail a real audit.
Accessible Canada Act Digital Requirements: What Applies to Your Site
The Accessible Canada Act sets out accessibility requirements for organizations under federal jurisdiction, and its supporting regulations phase in obligations over time. If you operate in federally regulated sectors such as banking, telecommunications, or transportation, your digital properties fall inside that scope. Provincial human rights legislation and accessibility standards may apply on top of it.
The practical takeaway: confirm your regulatory position before you scope the audit, because it determines documentation, timelines, and who signs off. Official guidance from the Accessibility Standards Canada outlines how federal organizations approach compliance planning.
Common WCAG 2.2 Failure Points and How to Spot Them
Most audit findings cluster around a small number of issues. WCAG 2.2 added criteria around focus appearance, dragging movements, and consistent help, catching many sites that passed under 2.1.
Keyboard Navigation, Focus Order, and Skip Links
Tab through every interactive element on a page. If focus disappears, lands in an unexpected order, or the focus indicator is invisible against the background, you have a failure. Skip links must be the first focusable element and must actually move focus past repeated navigation.
Alt Text, Color Contrast, and Form Error Identification
Decorative images should carry empty alt attributes; meaningful images need descriptive text that conveys purpose, not file names. Text contrast must meet the applicable ratio for its size and weight. Form errors must be identified in text, tied to the specific input, and announced to assistive technology rather than signaled by color alone.
| Failure Point | How to Test | Typical Fix |
|---|---|---|
| Missing focus indicator | Tab through all controls | Restore visible :focus-visible styles |
| Vague alt text | Review every image attribute | Rewrite to describe purpose |
| Low contrast text | Check ratio against background | Adjust color tokens at source |
| Color-only errors | Submit invalid forms | Add text error + aria-describedby |
| Broken heading order | Inspect heading outline | Rebuild hierarchy to match structure |
Automated vs Manual Accessibility Testing: Where Each One Fails
Automated vs manual accessibility testing is not a choice between two methods; it is a division of labor. Automated tools reliably catch a defined subset of issues, missing alt attributes, insufficient contrast, duplicate IDs, malformed ARIA, missing form labels, and empty links or buttons. Everything that depends on judgment, sequence, or assistive technology behaviour falls to manual testing. Automated scanning typically surfaces roughly a third of the issues a full audit finds; the rest require a human at a keyboard and a screen reader (deque.com).
The reason is structural: automated rules can only evaluate what is machine-checkable against a success criterion. They cannot tell you whether alt text is meaningful, whether focus order follows the visual reading order, whether an error message is announced at the right moment, or whether a custom widget exposes the correct role and state, the findings that decide whether a real user can complete a task.
What Automated Testing Does Well
Run automated checks continuously, not once. The highest-value coverage includes:
- axe-core (the engine behind axe DevTools and many CI integrations), checks a broad set of WCAG 2.2 A and AA rules and returns pass, fail, or 'needs review' per node.
- Lighthouse, a fast page-level score useful as a smoke test, but its accessibility category is a subset of axe-core and should not be treated as an audit.
- Pa11y and Lighthouse CI, pipeline runners that fail a build when a regression appears.
- HTML validators and heading-outline tools, catch malformed markup and broken document structure that break screen reader navigation.
Automated coverage is strongest for WCAG 2.2 criteria 1.1.1 (Non-text Content), 1.4.3 (Contrast Minimum), 1.4.11 (Non-text Contrast), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value). It is weakest for 1.3.1 (Info and Relationships), 2.4.3 (Focus Order), 2.4.7 (Focus Visible), and anything involving timing or live updates.
What Only Manual Testing Catches
Manual testing is where the audit earns its value. Work through these in order:
- Keyboard-only pass. Unplug the mouse. Tab, Shift+Tab, Enter, Space, and arrow keys through every interactive element. Confirm focus is always visible, never trapped, and follows a logical order. Test skip links, modals, menus, and date pickers.
- Screen reader pass. Test with at least two combinations, for example NVDA with Firefox on Windows and VoiceOver with Safari on macOS or iOS. Listen for whether headings, landmarks, form labels, error messages, and dynamic updates are announced correctly.
- Zoom and reflow. Zoom to 200% and 400% and confirm content reflows without loss of information or horizontal scrolling (WCAG 1.4.10 Reflow).
- Motion and timing. Check that auto-playing content can be paused and that animations respect
prefers-reduced-motion. - Cognitive and content review. Confirm plain-language instructions, consistent navigation, and that error recovery is possible without losing entered data.
The Division of Labor That Works
A defensible audit runs automation first, then manual testing, then a second automation pass after fixes ship. Automated tools clear the noise so manual testers spend their time on judgment calls, and the post-fix scan confirms no regressions. Document which method found each issue, that record demonstrates the audit was thorough rather than a single scan.
The Gap Most Checklists Miss: Dynamic and Single-Page Applications
Static-page checklists assume content is present at load. Single-page applications and heavily dynamic sites change content without a page load, which breaks naive auditing. Add these tests to your manual pass:
- Route-change focus management. When the view changes, move focus to the new heading or main region and announce the change. Otherwise keyboard and screen reader users are left on a stale element.
- Live region announcements. Use
aria-liveregions to announce status updates, cart changes, and validation results, and verify they fire once, not repeatedly. - Modal and dialog focus traps. Focus must move into the dialog on open, stay within it while open, and return to the triggering element on close.
- Loading and error states. Test the skeleton, spinner, empty, and error states, not just the success state. Each is a distinct accessibility surface.
- Client-side validation. Confirm errors are announced and tied to inputs when validation happens without a page reload.
Test each state explicitly. A component that passes in its default state can fail the moment it enters a loading or error state, and those states are exactly where dynamic applications hide their defects.
Accessibility Audit Tools for Developers and QA Teams
Accessibility audit tools for developers fall into three groups: browser-based inspectors, CI-integrated scanners, and assistive technology for hands-on testing. Use all three. Browser tools such as axe DevTools and Lighthouse give fast feedback during development. CI scanners catch regressions before merge. Screen readers and keyboard testing remain the ground truth.
- Browser inspectors: axe DevTools, Lighthouse, WAVE
- CI and pipeline scanners: axe-core, Pa11y, Lighthouse CI
- Assistive technology: NVDA, JAWS, VoiceOver, TalkBack
- Design checks: contrast analyzers, focus-state previews
The W3C Web Accessibility Initiative maintains the authoritative guidance on which techniques satisfy each success criterion, and it is the reference your audit report should cite.
Post-Audit Remediation Workflow: From Findings to Fixes
An audit that ends in a PDF changes nothing. Remediation turns findings into shipped fixes, and it needs an owner, a sequence, a verification method, and a record.
Step 1: Triage Findings Into Three Buckets
Not every finding deserves the same urgency. Sort every issue into one of three buckets:
- Blockers, issues that prevent a user from completing a core task. A keyboard trap in checkout, a form that cannot be submitted with a screen reader, or a modal that hides the page. Fix these first, regardless of effort.
- Compliance gaps, issues that fail a WCAG 2.2 A or AA success criterion but do not block a task. Missing landmarks, low-contrast secondary text, or a heading level skipped in a sidebar. These carry legal and procurement risk and belong in the current cycle.
- Polish items, enhancements that improve experience but do not fail a criterion. Batch these and address them as part of routine maintenance.
A useful prioritization rule: rank by user impact first, then by the number of pages or components affected, then by effort. One high-impact blocker outranks a hundred low-impact polish items.
Step 2: Assign Ownership at the Component Level
The most common remediation failure is assigning issues to a person instead of a place in the codebase. Assign each finding to the component or template that produces it: a corrected button component resolves the same finding across every screen that uses it, cutting remediation time dramatically.
Map findings to owners like this:
| Finding Type | Typical Owner | Fix Location |
|---|---|---|
| Missing focus styles | Design system team | Shared CSS tokens |
| Vague alt text | Content team | CMS fields per asset |
| Broken heading order | Front-end team | Page templates |
| Color-only errors | Design + front-end | Form component + tokens |
| Unlabeled form fields | Front-end team | Form component library |
Step 3: Fix at the Source, Not the Instance
Fixing page by page creates debt. Fix in the shared component library, the design tokens, or the CMS field configuration so the correction propagates. When a fix genuinely cannot be made at the source, document why, because that note becomes part of your compliance record.
Step 4: Re-Test With the Original Method
Every fix must be verified with the same method that found the issue: if a screen reader surfaced the problem, a screen reader confirms the fix; if an automated rule flagged it, re-run the rule. This prevents 'fixed but not verified' from entering your record.
Step 5: Document for Your Compliance Record
Keep a living record mapping each finding to its success criterion, fix, owner, and verification date. This is the artifact that answers a procurement review or a complaint; a spreadsheet or issue tracker works, and the format matters less than the completeness.
A Repeatable Remediation Cadence
Remediation is not a one-time sprint. Embed it into how your team already works:
- Definition of done, add an accessibility check to every ticket's acceptance criteria.
- CI gate, run an automated scanner on every pull request and fail the build on new violations.
- Periodic manual audit, schedule a keyboard and screen reader pass each quarter or after any major release.
- Regression watch, track whether previously fixed issues reappear, because new features reintroduce old defects.
Budgeting and Resourcing the Work
Plan for three cost centers: the initial audit, remediation engineering time, and ongoing verification. Most teams underestimate the third, because accessibility is continuous, every new feature is a chance to introduce a regression. Embed checks into your existing definition of done rather than running a separate accessibility sprint. Pricing for professional audit and remediation engagements depends on site complexity, page count, and depth of integration, so request a scoped quote rather than working from a generic figure.
That is where Elevated Digital operates. Our remediation and measurement services are built for organizations that need defensible records, not reassurance. We integrate with the systems your team already runs and hand back documented, verified fixes.
Budgeting, Resourcing, and Verifying Compliance
Verification becomes continuous: automated scans in CI, periodic manual audits, and a documented record of each criterion tested. That is where Elevated Digital operates. Our remediation and measurement services are built for organizations that need defensible records, not reassurance. We integrate with the systems your team already runs and hand back documented, verified fixes.
Most organizations discover their accessibility gaps at the worst possible moment: during a procurement review, a complaint, or a compliance deadline. Closing them takes a structured audit, disciplined remediation, and evidence the work was done. Elevated Digital provides defensible website design, remediation, and measurement services, with rigorous processes and seamless system integration that hold up under scrutiny. Get started with Elevated Digital and turn your accessibility findings into verified, documented fixes.
Frequently Asked Questions
What are the current accessibility standards for websites in 2026?
WCAG 2.2 is the current benchmark, organized around four principles: perceivable, operable, understandable, and robust. Compliance levels run A, AA, and AAA, and most organizations target AA. In Canada, the Accessible Canada Act and its supporting standards inform requirements for federally regulated entities, while provincial rules such as Ontario's AODA apply in specific jurisdictions. A website accessibility audit checklist should map every finding to a specific WCAG 2.2 success criterion so remediation is traceable.
How do I conduct a website accessibility audit?
Start by defining scope and the target compliance level, then run automated scans to catch low-hanging issues like missing alt text and contrast failures. Follow with a manual audit covering keyboard-only navigation, screen reader behavior, focus order, and form error identification. Test on real devices and with assistive technology. Document each issue with the WCAG criterion, severity, and affected URL, then hand the report to developers as a prioritized remediation backlog.
Are automated accessibility tools enough for a full audit?
No. Automated tools reliably catch roughly a third of WCAG issues, mostly structural problems like missing labels or insufficient color contrast. They cannot judge whether alt text is meaningful, whether focus order matches visual flow, or whether dynamic content announces correctly to screen readers. A credible audit pairs automated testing with manual review and user testing with people who rely on assistive technology.
How does the Accessible Canada Act impact website requirements?
The Accessible Canada Act applies to federally regulated organizations and requires them to identify, remove, and prevent barriers in areas including information and communication technologies. It does not name WCAG directly, but WCAG 2.2 AA is the practical benchmark auditors use to demonstrate compliance. Organizations should document their audit process, remediation timeline, and verification steps to show they are meeting their legal duty to remove barriers.
What are the most common WCAG 2.2 failure points?
The failures that surface most often are insufficient color contrast ratios, missing or unhelpful alt text, form inputs without programmatic labels, keyboard traps, and focus indicators that disappear. WCAG 2.2 added criteria around focus appearance, dragging movements, and consistent help placement, which many sites still miss. Dynamic content that updates without announcing changes to screen readers is another frequent gap, especially on single-page applications.
Which accessibility audit tools work best for developers?
Browser-based tools like axe DevTools and Lighthouse integrate into existing developer workflows and catch structural issues during development. WAVE provides visual feedback useful for content editors. For screen reader testing, NVDA and VoiceOver are the standard choices. No single tool covers everything, so most teams run one automated scanner in CI, one browser extension for spot checks, and manual screen reader passes before release.
How long does a website accessibility audit take?
Timelines depend on site size, complexity, and whether dynamic content is involved. A small marketing site with a handful of templates might take one to two weeks. A large site with authenticated areas, forms, and interactive components can take four to eight weeks or more. Remediation typically takes longer than the audit itself, so plan the project in phases with verification passes after each round of fixes.