A real public website, audited in depth. This is what I find.
A real, anonymised case. I show you how I really audit — all 50 criteria one by one, by hand and with a screen reader — and what the client receives at the end. No names and no finger-pointing: the value is in the method.
I want my website audited
A large tourism website with online booking
The case is a large public website in the tourism sector, with online booking. By its nature, two frameworks apply at once: the public-sector one and, for the booking service sold to consumers, Spain’s Law 11/2023 (the transposition of the European Accessibility Act). The technical bar is the same in both: the EN 301 549 standard, which is equivalent to WCAG 2.1 AA.
It’s the kind of website a scanner can’t cover: lots of pages, repeated templates and a booking process where the money is at stake. Exactly where a serious audit makes the difference.
It isn’t running a tool. It’s this.
An automated test detects around 30% of the real problems. The rest can only be seen by hand. This is how I work on every audit:
A representative sample
You don’t audit the whole website (it isn’t feasible), but a sample that covers the home page, the booking process, forms, login and common templates. If a template fails, it fails on every page that uses it.
All 50 criteria, one by one
I evaluate the 50 level A and AA criteria of WCAG 2.1 on the sample, not just the ones a machine detects. Each with its status: passes, fails or not applicable.
By hand and with a real screen reader
Keyboard navigation, contrast, focus and reading with NVDA, the screen reader real people use. Automated tools can’t tell whether a field is announced properly; the screen reader can.
Deliverables that prove the work
A technical report, a conformance table for the 50 criteria, an accessibility statement ready to publish and, where relevant, a score in the style of Spain’s Web Accessibility Observatory.
Real failures, in plain language
Some of the findings in this case, explained without jargon. None of them is rare: they come up in almost every website I audit.
A booking form without labels
Fields that are obvious to the eye, but that a screen reader announces as just a text box. Someone who can’t see doesn’t know what is being asked. In a booking, that’s a purchase that never gets completed.
The invisible focus
Navigating with the keyboard, you couldn’t see where you were: like moving around your house in the dark. It’s fixed with one line of CSS, but it affects the whole website.
The calendar the keyboard can’t reach
The date picker only responded to the mouse. Without a mouse, there was no way to book.
What the machine passed and the screen reader didn’t
A field the tool considered fine — it had a label — but that the real screen reader announced without a name, because that label was hidden with CSS. In theory, yes; for the user, no.
A report people can understand, that proves what was done
Neither a 200-page PDF nor a tool dump. Clear, branded documents, written so management can understand them and your technical team can act on them.
-
Technical report
A verdict, findings by severity, the impact on people and a concrete fix, with code where it applies.
-
Conformance table for the 50 criteria
The status of every level A and AA criterion. Proof that everything has been reviewed, not just what jumps out.
-
Accessibility statement
Written for the regime that applies to you, ready to publish and meet the documentation requirement.
-
Results meeting
An hour to go through it with you and your team and set priorities. I don’t send you a PDF and disappear.
Want to know what state your website is in today?
That’s exactly what I do: an in-depth audit, with a report and a compliance document tailored to your case. No smoke and no surprises.
Ask me for an auditA real, anonymised case. The audited organisation is neither named nor identifiable: the aim is to show the method, not to point at anyone.