Why Accessibility Isn’t Just a Lighthouse Score (and How to Get It Right)

You’ve probably heard it before: “Run Lighthouse, check the score, fix a few things, and boom — your site’s accessible!”

If only.

Here’s the truth: tools like Lighthouse, BrowserStack’s toolkit, WAVE, and the rest are great for spotting obvious problems, but they’re like a quick health check at the pharmacy. They’ll tell you your blood pressure is fine, but they’re not running a complete medical exam. Accessibility is about real people using your site in all kinds of ways, and no scanner can understand human frustration.

I’ve seen sites with perfect Lighthouse scores that are a nightmare for screen reader users. Or “compliant” sites where you technically can tab through the page — but the order is so illogical, it feels like trying to read a book with the chapters shuffled. Automated tools miss that. They can’t judge whether the writing makes sense, if the buttons have clear labels, or if your color choices are usable for people with different vision conditions. They only check for patterns they’ve been programmed to find.

If you want your site to pass the test, WCAG 2.1 AA, Section 508, EN 301 549, you name it, you need three layers of work.

First, yes, run those tools. They’ll give you the low-hanging fruit: missing alt text, low color contrast, and missing form labels. Easy wins. Then comes the human side. Get people who use assistive technology to test your site, screen readers, voice commands, and switch devices. Watch them work. Listen to their feedback. You’ll see things no automated tool will ever report, like confusing link text (“Click here!” means nothing out of context) or a pop-up that traps the keyboard focus.

And finally, there’s the mindset shift: accessibility isn’t a one-time fix, it’s part of how you build and update your site. It means designers thinking about color contrast from the first mockup, developers adding semantic HTML as naturally as they write a div, and content writers structuring their copy; hence, it makes sense when read aloud.

The best scores, real scores, not just the automated kind, happen when compliance levels aren’t seen as the finish line, but as the bare minimum. WCAG AA is a foundation, not a trophy.

Start by using assistive tech yourself. Fire up NVDA (free, Windows), VoiceOver (built into Mac and iOS), or TalkBack (Android). Try navigating your site without a mouse. Tab through every interactive element. Listen to how the screen reader announces links, headings, and form fields. You’ll instantly hear if the page feels logical or like a maze. You don’t have to become a power user of these tools; just five minutes with them will give you insights no automated scan will.

Don’t stop there. Try voice control software like Dragon NaturallySpeaking or built-in systems like Apple’s Voice Control. See how easy (or impossible) it is to trigger buttons and menus by voice. If you can’t trigger a key part of your site without using a mouse, someone else can’t either. And here’s something most people forget: document your findings so others can act on them. A good accessibility report isn’t just a dump of issues from a tool. It’s a living document that:

• Describes the problem in plain language.
• Explains why it’s a problem, ideally with a quick example from a user’s perspective.
• References the relevant WCAG success criteria.
• Gives a clear, tested recommendation for fixing it.

When your reports are clear, teams can solve problems rather than play whack-a-mole with vague errors.

The finish line is when you can confidently say: “If someone uses this site with a keyboard, a screen reader, a switch device, voice control, or just one hand on a mobile phone, they can do everything they came here to do without frustration.”

So sure, run Lighthouse. Use WAVE. But don’t kid yourself that a number on a report equals an inclusive experience. Accessibility lives in the details, the testing, and the empathy you bring to the table. That’s what turns “passing the test” into “everyone can use it.”

Quick Accessibility Testing Guide (No Fancy Tools Needed)

1. Unplug the mouse.
   Use only your keyboard to navigate. Make sure you can reach all buttons, links, and form fields with Tab, Shift+Tab, Enter, and arrow keys. Check that the focus indicator (the highlight around active elements) is visible.
2. Try a screen reader.
   • Mac/iOS: Turn on VoiceOver (Cmd + F5 on Mac).
   • Windows: Download NVDA (free) or use Narrator (Ctrl + Win + Enter).
   • Android: Enable TalkBack in accessibility settings.
Listen for missing labels, unclear link text, and illogical reading order.
3. Check your colors.
   Drop a screenshot into a color blindness simulator (Coblis is free). Make sure everything is still readable.
4. Zoom it.
   Increase the browser zoom to 200%. The layout should stay usable, without horizontal scrolling for basic content.
5. Test without styles.
   Turn off CSS (browser dev tools can do this). The page should still make sense in a logical reading order.
6. Try voice control.
   If you have a Mac or iOS device, enable Voice Control in Accessibility settings and try navigating by saying “Click [link text]” or “Scroll down.” See if everything is reachable.
7. Test forms like a stranger.
   Clear your cookies, go to your forms, and fill them out incorrectly on purpose. Check if the error messages tell you precisely what to fix.

At Oshyn, accessibility isn’t a post-production checkbox—it’s baked into our DNA. Whether we are building on Sitecore, Adobe Experience Manager, or Optimizely, our philosophy remains the same: we design for real people, on any device, with any ability. By pairing automated audits with rigorous manual testing—including screen readers and keyboard-only navigation—we ensure our projects aren't just compliant on paper, but truly inclusive for every user.