Somewhere in your site's HTML, there is a good chance a skip link is sitting quietly, doing absolutely nothing.
It is not missing. Someone added it, probably during an accessibility push a couple of years ago, checked the box on an audit checklist, and moved on with their life. The code is still there if you look at the page source. It just does not work anymore.
Then a redesign happened. The id the link pointed to got renamed from #main to #main-content and nobody updated the anchor. Or a developer added overflow: hidden to a wrapper div, and the link that was supposed to slide into view on focus now stays invisible forever, clipped out of existence. The skip link still technically exists. It just quietly stopped doing its job, and nobody noticed, because nobody has actually pressed Tab on that page since the day it was built.
The Stat: WCAG 2.4.1 (Bypass Blocks) is a Level A success criterion requiring a mechanism, commonly a skip link, to bypass repeated navigation content on every page. (Source: W3C WCAG 2.2)
The Test Itself Takes Less Time Than Reading This Sentence
Here is the whole thing. Load your homepage in a fresh browser tab (not one where you have already clicked into a form field or a search box). Click once on the empty gray background of the page, away from any input, just to make sure focus starts at the very top of the document. Then press Tab one time.
That is it. That is the entire test.
If your skip link works, a small piece of text (something like "Skip to main content") should appear, usually in the top left corner, clearly visible and clearly focused, often with an outline or a highlighted background around it. Press Enter, and your focus should jump straight past the header and navigation menu into the main content of the page.
If nothing visibly happens when you press Tab, or a link appears but pressing Enter does nothing, or the page scrolls somewhere strange, or focus lands back at the very top like the link was never pressed at all, your skip link is broken. It might be present in the code. It is not present for the humans who need it.
What "Working" Actually Looks Like
A properly functioning skip link has three qualities, and it is worth checking each one separately because a link can pass one and fail the other two.
It appears on focus. The link should be visually hidden by default (that part is fine and expected) but become fully visible the instant it receives keyboard focus. If it stays invisible even while focused, screen readers may still announce it, but sighted keyboard users, including people with motor impairments who navigate by keyboard rather than mouse, get nothing to look at.
It points to a real target. The href (usually something like #main-content) has to match an actual id that exists somewhere further down the page. If a redesign renamed that container, the link now points at nothing, and activating it does absolutely nothing.
It actually moves focus. This is the one people forget. Just jumping the page's scroll position is not enough. The target element needs tabindex="-1" (if it is not naturally focusable) so that focus itself, not just the visual scroll position, lands inside the main content. Otherwise a screen reader user gets scrolled to the right spot but keeps reading from wherever their focus actually is, which might still be back in the navigation.
The Four Ways Skip Links Quietly Break
In our own day to day testing at WCAG.World, these are the failure patterns we run into over and over. None of these require an "audit." They require someone pressing Tab.
The renamed target. A developer restructures a page template, renames
#mainto#page-content, and the skip link'shref="#main"now points at nothing. This is by far the most common break, because it happens silently during totally unrelated redesign work.The clipped container. A parent element gets
overflow: hidden,height: 0, or a fixedmax-heightadded for some other layout reason, and the skip link, which relies on becoming visible through absolute positioning or a transform on focus, gets trapped inside that clipped box and can never actually appear on screen.The z-index casualty. The link technically appears, but a newer sticky header or cookie banner sits on top of it with a higher
z-index, so it is rendered but not visible or clickable.The focus that scrolls but does not land. The href resolves correctly and the page does scroll, but because the target lacks
tabindex="-1", keyboard and screen reader focus never actually transfers there. This one is sneaky because it looks like it works if all you do is watch the scrollbar.
Why WCAG Made This a Level A Requirement
Bypass Blocks did not become a baseline requirement by accident. Every additional press of the Tab key someone has to make just to get through the same header and navigation on every single page is friction that piles up across an entire visit. On a ten page journey, a broken skip link means tabbing through the same twenty links, ten separate times, before ever reaching the content someone came for. The W3C's own explanation of Bypass Blocks and WebAIM's technique guide for skip navigation links both go deeper into implementation patterns if you want the full technical picture beyond this quick check.
It is worth pairing this test with a broader look at how your focus behaves when navigating by keyboard, since a broken skip link is often just the most visible symptom of focus management getting overlooked in general. If you want to go further than a 5 second spot check, running through a full screen reader pass in about 20 minutes will surface how the same page actually sounds to someone who cannot see that link appear at all.
One More Thing to Check: Mobile and Touch Screen Readers
The Tab key test above covers desktop keyboard users, but do not stop there. On a phone, someone using a screen reader like VoiceOver or TalkBack swipes through elements one at a time rather than pressing Tab, and a skip link needs to show up early in that swipe order too, right after the page title, not buried behind a dozen header icons and a hamburger menu. Open your site on a phone, turn on your screen reader, and swipe forward a few times. If the skip option never comes up, or it comes up so late that a user has already swiped through the entire header, it is functionally broken for that audience even if it passed the desktop Tab test with flying colors. The fix is usually the same underlying markup, just confirm the skip link is placed early enough in the document order that both input methods reach it quickly.
Make This Part of Your Regular Habit, Not a One-Time Fix
The uncomfortable truth about skip links is that they almost always work on launch day and quietly rot afterward. Nobody breaks them on purpose. A redesign here, a new sticky banner there, and a link that passed every audit two years ago is now dead weight sitting in your HTML.
The fix, once you find the break, is usually small. A renamed id, a tabindex attribute, an overflow rule. The hard part was never the code. It was simply remembering to press Tab and check.
Run the test today, right now, on your own homepage, and see what happens. If you want a faster way to catch this and other keyboard issues across your whole site without manually tabbing through every page, our team built a set of free accessibility tools to help you check.
If you run the test and something looks off, or you just want a second pair of eyes on it, reach out to a real person on our team at experts@wcag.world, or start with our free tools to see exactly where your skip link, and the rest of your keyboard experience, currently stand.