An accessibility audit is a systematic check of a website or an app against a set of criteria, usually WCAG. Unlike a quick check, it produces a documented picture: which problems exist, where, how serious they are and how to fix them. It is the starting point for any serious improvement plan, and in many cases it is also a regulatory requirement.
Why do it
In Italy the Stanca Law, from 2004, introduced accessibility obligations for public administrations, which must also publish an accessibility statement following the guidelines of AgID, the national digital agency. With the European Accessibility Act, applied from 28 June 2025, similar obligations also cover many private products and services, such as e-commerce, banking services and some transport services, with exceptions for microenterprises providing services. The technical reference standard in Europe is EN 301 549, which for web content refers to the WCAG criteria.
Beyond obligations, an audit reveals problems that drive away real customers and users, and often brings general usability defects to light as well.
The stages of an audit
1. Define the goal and scope
First of all you need to establish what you are checking against and what you are checking. The goal is usually WCAG 2.1 or 2.2 level AA. The scope states which parts of the service are included: public website, private area, mobile apps, downloadable documents.
2. Choose a sample of pages
On a site with thousands of pages you cannot check everything. You choose a representative sample that includes:
- the home page and the main navigation pages;
- one example of each page template, such as article, product page, listing, search;
- the most important complete journeys, such as sign-up, purchase, contact, booking;
- pages with complex components, such as maps, calendars, filters, modal dialogs;
- a few pages chosen at random, so you are not only checking what you already know.
Journeys must be checked end to end: an accessible payment page is no use if the cart before it is not.
3. Automated checks
Automated tools analyse the code and flag problems that can be detected mechanically: images without an alt attribute, insufficient contrast, fields without labels, invalid ARIA attributes, undeclared page language. They are fast and useful for finding errors repeated across many pages.
Their limitation is important: they detect only part of the problems. A tool checks that an image has alt text, but cannot tell whether that text makes sense; it checks that a button has a name, but not whether that name really describes the action.
4. Manual checks
This is the longest and most valuable part. It includes:
- full navigation with the keyboard alone, checking focus order and visibility;
- testing with at least one screen reader on a computer and one on mobile;
- zooming text to 200% and reflowing at narrow widths, to check that nothing is lost or overlaps;
- checking headings, landmarks, link text and table structure;
- checking forms, error messages and status messages;
- checking video, audio, animations and content that moves on its own.
5. Document the problems
Each problem should be recorded so that whoever has to fix it can do so without redoing the analysis:
| Field | Example |
|---|---|
| Page or component | Sign-up form |
| WCAG criterion | 3.3.1 Error Identification |
| Description | The error on the email field is shown only by a red border |
| Impact | People who cannot distinguish red or use a screen reader do not know which field to fix |
| Severity | High: prevents completing sign-up |
| Suggested fix | Add a text message linked to the field and announced |
6. Set priorities
Not all problems carry the same weight. A practical criterion considers together the severity for the user, how much the page is used and how much the fix costs. Problems that block an essential task come first. Often many problems stem from a few shared components, such as the menu, buttons or form fields: fixing the component once repairs dozens of pages.
After the audit
A report left in a drawer improves nothing. The next step is a remediation plan with owners and deadlines, followed by a re-check of the problems fixed. It is also worth building accessibility into everyday work: automated checks during development, accessibility criteria in task definitions, training for designers and content editors.
In my work I always recommend pairing the technical audit with at least one session with disabled users: the audit tells you whether the site meets the criteria, users tell you whether they can actually use it.
In short
- An audit checks a service in a documented way against precise criteria, usually WCAG level AA.
- The Stanca Law and the European Accessibility Act make accessibility an obligation for many organisations.
- The sample must include different page templates and complete journeys, not just isolated pages.
- Automated tools are useful but partial: manual checks are indispensable.
- Every problem should be documented with criterion, impact, severity and fix, and followed by a concrete plan.
