accessibility score
The accessibility score is Google's automated check of whether a site can actually be used by people with disabilities, like screen reader users or people who can't use a mouse.
The accessibility score is part of the same Google PageSpeed report that measures load time, and it checks something different: whether the page can actually be used by someone with a disability. Can a screen reader make sense of the page’s structure? Is the text readable against its background for someone with low vision? Can every button and link be reached without a mouse? The automated check runs through dozens of these questions and returns a single number out of 100.
This is not a cosmetic detail bolted onto a site afterward. It’s mostly a consequence of how the site was actually built. Clean, semantic code that clearly marks what’s a heading, what’s a button, and what’s an image tends to score well automatically. A site cobbled together from mismatched plugins and generic styled boxes tends to fail the check in ways that are genuinely hard to retrofit after the fact.
I’ve measured this directly, before and after a rebuild, same test, same day. The old site scored below what a real screen reader user could comfortably navigate. The rebuilt site hit 100, on both mobile and desktop, without that being a separate project. It came from building the page correctly the first time.
Why it matters to you
A visitor using a screen reader, or navigating by keyboard because a mouse isn’t an option for them, either can use your site or they can’t. There’s no partial credit from their side of the screen. If your booking form can’t be reached without a mouse, that’s not a missed nice-to-have, it’s a customer who leaves and books somewhere else instead.
There’s also a growing overlap with agentic browsing: the same clear, well-structured markup that helps a screen reader also helps an AI assistant navigate and act on a site on someone’s behalf. Accessibility work and AI-readiness work are, increasingly, the same work.
How I set it up
Building on Astro with clean, semantic code gets most of this right by default, correct heading structure, real buttons instead of styled divs pretending to be buttons, readable colour contrast built into the design system from the start rather than checked after the fact. I don’t treat accessibility as a separate audit tacked onto the end of a project. It’s part of how the page gets built the first time.
What it looks like in practice
The Google PageSpeed report shows a 100 on accessibility, same as the PageSpeed load-time score sitting right next to it, both measured the same day as the old site’s numbers for direct comparison. Beyond the number, the site genuinely works for someone using a screen reader or navigating by keyboard alone, which was very likely not true before.
Questions I get about this
- Does a perfect accessibility score mean my site is fully accessible?
- It means the automated checks Google can run all passed, which is a real and meaningful baseline. It doesn't catch everything a human accessibility review would, but a site failing the automated checks is definitely failing real users too, so a perfect score is a genuine floor, not just a vanity number.
- Who actually needs an accessible site?
- More people than most business owners assume: screen reader users, people with low vision who rely on strong colour contrast, people navigating by keyboard alone because a mouse isn't usable for them, and increasingly, the AI assistants now trying to browse and act on a site on someone's behalf.
- Can accessibility issues get a business into legal trouble?
- In some jurisdictions, yes, inaccessible websites have been the subject of real legal complaints. That's a secondary reason to care. The primary one is simpler: an inaccessible site turns away real customers who would otherwise have booked with you.
Want this set up properly for your business?
This is the kind of thing I build every week. Grab a time and we will talk through what fits.