Insights
How we audit web accessibility for public sector organizations (step by step)
Web accessibility in the public sector is not optional. Legislation across Europe and beyond requires government websites and apps to meet WCAG 2.1 Level AA. Yet the majority of public sector sites still fall short. In this article we walk through how we approach an accessibility audit, what we actually test, and how we document findings so your team can fix them.
At The Interactive Studio we have spent over a decade working with public sector bodies and private companies on web design and development. Over the past few years accessibility has become central to what we do. We audit websites, design accessible component libraries, and work alongside technical teams to implement the fixes that matter.
This article describes how we actually work. It is not a theoretical overview but a breakdown of what happens on every real project.
What is a web accessibility audit
A web accessibility audit is a technical evaluation that measures how well a website meets the WCAG 2.1 Level AA success criteria. The goal is to identify barriers that prevent or hinder access for people with disabilities, document them with evidence, and provide actionable recommendations.
It is worth distinguishing a professional audit from a quick automated scan. Tools like Lighthouse, WAVE, or axe are useful starting points, but they only catch between 25% and 40% of accessibility issues. Many WCAG criteria require manual testing. Deciding whether alt text is genuinely descriptive, whether reading order makes sense, or whether error messages are clear enough cannot be automated.
Our audits follow the WCAG-EM methodology published by the W3C. This is the international standard for web accessibility evaluation and ensures our results are reproducible, comparable, and defensible under external scrutiny.
The regulatory landscape
Public sector organizations are subject to specific legal requirements around web accessibility. Understanding this landscape is essential to scope any audit correctly.
Unlike the private sector, where accessibility has often been treated as a nice-to-have, government bodies face hard obligations with real consequences. European and national legislation sets out concrete requirements, deadlines, and enforcement mechanisms.
Below we cover the key regulations affecting public sector websites.
EU Web Accessibility Directive
The EU Directive 2016/2102 requires all public sector websites and mobile apps across the European Union to meet accessibility standards based on EN 301 549, which in turn references WCAG 2.1 Level AA.
The main obligations are straightforward.
- Meet the 50 success criteria of WCAG 2.1 Levels A and AA
- Publish and maintain an up-to-date Accessibility Statement
- Provide a feedback mechanism so users can report accessibility problems
- Conduct regular reviews of conformance status
Non-compliance can lead to enforcement action, reputational damage, and complaints from the public.
European Accessibility Act
From June 2025, Directive 2019/882 extends accessibility obligations to private companies offering essential services. Banking, transport, e-commerce, and telecommunications are now in scope. Each EU member state has transposed this into national law.
WCAG 2.1 or WCAG 2.2
Current legislation references WCAG 2.1, but the W3C published version 2.2 in October 2023. The newer version adds new success criteria without changing existing ones. At The Interactive Studio we evaluate against WCAG 2.2 to provide a more thorough analysis, although legal compliance is still measured against version 2.1.
You can review the full list of WCAG criteria we assess during our audits.
How we define audit scope
Auditing an entire website is not always practical or necessary. The scope needs to match the size of the site, the available resources, and the organization’s specific goals.
Selecting a representative sample
Following the WCAG-EM methodology, we select a sample of pages that covers these elements.
- Homepage and main navigation pages
- Pages with critical functionality such as forms, search, online services, and payments
- Diverse content types including text, tables, video, and downloadable documents
- Dynamically generated pages such as search results, error messages, and confirmations
For a mid-sized site a typical sample includes between 15 and 30 representative pages.
Documenting the test environment
Accessibility does not depend on code alone. Behaviour can vary depending on the browser, operating system, and assistive technology in use. We always document the test environment.
- Browsers including Chrome, Firefox, and Safari
- Screen readers such as NVDA on Windows and VoiceOver on macOS and iOS
- Devices including desktop, tablet, and mobile
Our audit process
Our methodology combines automated analysis with expert manual review. No single tool can evaluate every WCAG criterion on its own. That is why we structure the work in complementary phases that ensure full coverage.
The process we describe here is what we apply on every project, regardless of site size or organization type.
Initial automated analysis
We use automated testing tools like WAVE, axe, and Lighthouse to get a quick first diagnosis. These tools pick up obvious errors such as images without alt text, insufficient contrast, and malformed heading structures.
As we mentioned, automated analysis is just the starting point. It does not replace manual evaluation.
Manual testing against WCAG criteria
We review each page in the sample against the 50 WCAG 2.1 AA criteria. This phase includes the following.
- Full keyboard navigation. We verify that all interactive elements are reachable and that focus order is logical
- Screen reader testing. We check that content is announced correctly and makes sense outside of visual context
- Form verification. We review associated labels, clear error messages, and understandable instructions
- Responsive behaviour. We evaluate adaptation to different screen sizes and zoom levels up to 200%
Documenting findings
Documentation is a fundamental part of the process. A useful report does not just list problems but provides enough context for the technical team to address each issue independently.
For each failure we document the following fields.
| Field | Description |
|---|---|
| WCAG Criterion | Identifier and title of the failed criterion |
| Location | URL and affected element |
| Evidence | Screenshot or recording |
| Impact | Who is affected and how |
| Severity | Critical, major, or minor |
| Suggested fix | Recommended code or content change |
| Estimated effort | Low, medium, or high |
This structure lets you filter and prioritize fixes based on your team’s needs and resources.
Report and action plan
The final deliverable includes the following.
- Executive summary with overall conformance level
- Detailed issue list classified by severity
- Prioritized action plan based on impact and effort
- Accessibility Statement ready to publish if the conformance level allows
Common issues we find on public sector sites
After auditing many government and public sector websites, these are the problems we encounter most often.
- Images without alt text or with generic text like “image” or “photo”
- Form fields without labels properly associated
- Insufficient contrast between text and background
- Broken keyboard navigation with unfocusable elements or focus traps
- Malformed heading structures with skipped levels or decorative-only use
- Ambiguous links such as “click here” or “read more” without context
- Inaccessible PDFs scanned as images without OCR or structure
- Videos without captions or audio description
Many of these issues are relatively straightforward to fix once identified. The problem usually lies in lack of awareness or processes that do not integrate accessibility into the regular workflow.
What happens after the audit
An audit is not the end of the road. Accessibility is an ongoing process that requires several actions.
- Implement the fixes following the action plan
- Train your content and development teams to prevent new issues
- Establish review processes before each publication
- Schedule periodic re-audits as most legislation requires annual review
At The Interactive Studio we offer end-to-end support. From the initial audit through team training and ongoing maintenance.
Frequently asked questions
How long does an accessibility audit take?
It depends on the size and complexity of the site. A typical audit of 20 to 30 pages takes between 2 and 4 weeks. Larger sites or those with complex functionality may require 6 to 8 weeks.
Does the audit guarantee legal compliance?
The audit identifies non-conformances and provides a remediation plan. Compliance is achieved once the necessary fixes are implemented. We can support you through the entire process.
What is the difference between your audit and running Lighthouse?
Lighthouse catches roughly 30% of issues. Our audit evaluates all 50 WCAG 2.1 AA criteria using the official WCAG-EM methodology, combining automated tools with expert manual review.
Do you only work with public sector organizations?
No. We work with government bodies required to meet accessibility legislation as well as private companies that want to ensure their digital products are accessible or need to comply with the European Accessibility Act.
Web accessibility is both a legal and social responsibility. But it is also an opportunity to improve the technical quality of digital services and ensure everyone can access them on equal terms.
If you need to assess your site’s accessibility or want to plan an improvement process, we can help.
