Accessibility mistakes we found on our own site (and fixed)

We ran a full manual WCAG 2.2 AA audit on Accessimo's own website, the same process we run for clients. No automated scan gets a full pass here; you have to actually use a screen reader and a keyboard, the way a disabled visitor would.

We found two real issues. Neither showed up as an obvious visual bug. Both would have quietly locked out screen reader users. Here's what they were, why they mattered, and how we fixed them.

Issue 1: the skip link didn't actually skip anywhere

What a skip link is: a hidden link at the very top of a page, only visible when you press Tab, that says something like "Skip to main content." It exists so a screen reader or keyboard user doesn't have to sit through the entire navigation menu, header, and logo every single time they load a new page. It lets them jump straight to the content.

What was wrong: our skip link was on the page and clickable, but it wasn't moving screen reader focus anywhere. Visually, clicking it looked fine: the page scrolled down. But a screen reader user's focus stayed stuck at the top of the page. They'd hear the whole navigation read out to them anyway, every time, with no way to jump past it.

Why it matters: this is exactly the kind of fix that looks correct on screen and fails in practice. Someone testing by eye, even a careful person, would tick this off as done. It only breaks for the people it exists to help, which is why manual testing with real assistive technology isn't optional.

The fix: the skip link now moves keyboard focus to the main content landmark, not just the scroll position. A screen reader user pressing it lands directly in the content, the same way a sighted user's eye does.

Issue 2: a working link, hidden from screen readers by accident

What aria-hidden does: it's an attribute developers add to tell screen readers "ignore this, it's decorative, don't read it out." Used correctly, it's genuinely useful: it stops screen readers wasting someone's time reading out background icons or purely visual flourishes.

What was wrong: aria-hidden="true" was set on a decorative wrapper element. But a real, working link had been nested inside it. To a sighted visitor, the link looked completely normal: visible, clickable, styled like every other link. To a screen reader, it didn't exist at all. It was invisible and unreachable, as if it had been deleted.

Why it matters: this is a good example of how one small, well-intentioned line of code can silently break access to something important, with zero visual sign that anything is wrong. Nobody looking at the page would ever spot it. You only find it by testing the way a screen reader user actually navigates: link by link, heading by heading, not just scrolling and looking.

The fix: we moved the aria-hidden attribute to only wrap the genuinely decorative parts, so the link sits outside it and is reachable and announced normally again.

The takeaway

Both issues had the same root cause: something that looked fine on screen and was broken for anyone using a screen reader. That's the case for the majority of real accessibility failures we find. They're invisible unless you specifically test for them, which is exactly why automated scanners alone catch a fraction of real issues, and why we test manually, on every audit, including our own site.

If it can happen on a site built by people whose whole job is accessibility, it's worth checking for it on yours.