Accessibility Auditing for Government Websites: A Practical Guide

Accessibility auditing government websites checks whether a public-facing service meets WCAG standards and legal requirements. This guide shows a step-by-step practical audit workflow, the checks to run, how to prioritise fixes, and how to produce a usable audit report.

Why audit government websites

Audits do three things. They reduce legal risk under public-sector accessibility rules. They improve access for people who use assistive technology. They cut support costs by preventing avoidable user failures. For UK public bodies the Web Accessibility Regulations require an accessibility statement and remedial action for known failures.

Standards and laws to use

• WCAG 2.1 and WCAG 2.2 — use success criteria for conformance testing
• WAI-ARIA for dynamic content and widget semantics
• UK: Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018
• US: Section 508 and ADA guidance where relevant
• EU: EN 301 549 and the European Accessibility Act for procurement and products

Audit approach: automated plus manual plus user testing

An effective audit mixes three pillars.

• Automated scans to catch technical issues at scale.
• Manual inspection to test semantics, keyboard behaviour and reading order.
• User testing with people who use screen readers, switch devices or keyboard-only input.

Practical step-by-step audit workflow

1 Scope and objectives

Define what you will test. Choices include a representative sample of pages, whole site crawl, or key user journeys such as sign-in, form submission and payments. Record target conformance level: AA or A.

2 Discover and crawl

Use a crawler to map pages. Flag content types: HTML pages, PDFs, images, client-side applications. Identify third-party components like payment widgets and maps that need special attention.

3 Sample pages and journeys

Pick a mix of page templates and high-traffic journeys. A standard sample set includes: home, search, content page, form page, dashboard, and error pages.

4 Automated scan

Run an automated tool across the sample. Export results for triage. Automated tools find contrast, missing alt, empty buttons and some ARIA issues. They do not find logical errors or reading order problems.

5 Manual checks

Manual checks target things automation misses. Test keyboard navigation, focus order, semantic headings, form labels, table headers, skip-links, and accessible names for interactive controls.

6 Assistive-technology verification

Test with at least one screen reader and one keyboard-only session. On Windows use NVDA or JAWS. On Mac use VoiceOver. Verify:

• Forms announce errors and set focus to the first error.
• Screen reader reads widget names and states correctly.
• Dynamic content uses aria-live or role=alert appropriately.

7 User testing

Run short sessions with people who regularly use assistive tech. Tasks should mirror real journeys: find information, complete a form, authenticate. Observe barriers and record exact steps where users get stuck.

8 Report findings

Structure the report so it is actionable for developers and visible for managers. Include severity, WCAG reference, reproduction steps, suggested fix and example code when useful.

9 Remediation and regression testing

Work with product and engineering to implement fixes. After changes run a targeted regression test on modified pages and a follow-up assistive-technology check.

10 Ongoing monitoring

Set up automated scans in CI for new commits. Schedule periodic manual checks and repeat user-testing when major features change.

Checklist: what to test (mapped to WCAG principles)

Perceivable

• Text alternatives for non-text content: images must have alt or role=presentation
• Colour contrast: foreground/background ratios meet 4.5:1 for normal text, 3:1 for large text
• Audio and video: captions and transcripts or text alternatives

Operable

• All functions work with keyboard only. No keyboard traps.
• Focus order is logical and visible focus styles exist.
• Timing controls and pause options for moving content when needed.

Understandable

• Clear labels for form fields, including appropriate aria-describedby for instructions.
• Error identification and text suggestions are announced to assistive tech.
• Consistent navigation and predictable behaviour.

Robust

• Valid HTML semantics: headings, lists and landmarks used correctly.
• WAI-ARIA used only when native semantics are insufficient.
• Accessible name computation verified for custom controls.

Tools to use (examples)

• Automated: Axe, Lighthouse, WAVE
• Screen readers: NVDA, VoiceOver, JAWS
• Keyboard testing: manual tab and shift-tab checks
• Contrast checkers and colour simulators
• Document checkers for PDFs and Office files

How to prioritise remediation

Prioritise by impact on real users and by how often the page or component is used. Use a two-axis matrix with impact and effort.

Priority	Typical issues	Action
High	Missing form labels, keyboard traps, inaccessible authentication	Fix within sprints. Verify with assistive tech.
Medium	Colour contrast failures, non-descriptive link text	Plan in next releases. Apply style fixes and content edits.
Low	Minor semantic improvements, documentation updates	Include in backlog grooming.

How to write an actionable audit finding

Use simple, reproducible steps. Include the WCAG reference, a clear severity, and a code or content suggestion.

• Title: Missing label for “Date of birth” field
• WCAG: 2.5.3 and 1.3.1 (name, role, value and adaptable content)
• Steps to reproduce: open form, tab to the date field, screen reader announces “edit” without label
• Impact: Screen reader users cannot identify the field
• Suggested fix: Add a visible <label for="dob">Date of birth</label> and aria-describedby for format guidance

Real-world scenario: auditing a government form

Common findings for forms and practical fixes.

• Missing label on a date field. Fix by adding a label element and ensure the ID matches the input.
• Errors shown only in colour. Fix by adding text descriptions and aria-describedby to the input.
• Focus not moved to error summary after submit. Fix by scripting focus to the error container with role=alert or setting focus programmatically.
• Custom select widgets not exposing value to screen reader. Fix by using native select or implementing correct WAI-ARIA roles and keyboard support.

Reporting template (short)

Include these sections.

• Executive summary: scope, conformance target, headline risk
• Methodology: tools, sample pages, assistive tech used
• Findings table: page, issue, WCAG, severity, reproduction steps, remediation
• Prioritised remediation plan and quick wins
• Follow-up plan: regression testing and monitoring

Governance and ongoing checks

Embed accessibility into the delivery lifecycle.

• Run automated accessibility checks in CI for pull requests.
• Include accessibility acceptance criteria in user stories.
• Keep an accessibility statement and publish progress on known issues.
• Maintain a small panel for regular user testing with people with disabilities.

Common misconceptions

• Automated tools do not prove conformance; they highlight detectable issues.
• Adding aria attributes is not a substitute for semantic HTML.
• High contrast alone does not make content accessible if forms lack labels or keyboard support.

How long and how much

Duration depends on scope. A sample audit of 20 representative pages with automated and manual checks plus one round of user testing typically takes several weeks of part-time effort. Whole-site audits take longer. Costs vary by supplier and user-testing needs.

Next steps checklist

1. Define conformance level and scope.
2. Run a site crawl and select sample pages.
3. Run automated scans and triage results.
4. Perform manual and assistive-technology checks.
5. Run brief user tests with assistive-tech users.
6. Produce a prioritised remediation plan and start fixes.
7. Set up automated monitoring and periodic re-testing.

Use this guide as the working audit playbook. Adapt sample sizes and tools to project constraints. If you need a template report or a sample checklist file, say which format you prefer.