DEV Community: A11Y Practice

A Skip Link That Doesn't Land Is Not a Bypass: WCAG 2.4.1 in Practice

A11Y Practice — Wed, 14 Oct 2026 11:29:55 +0000

You press Tab on a page and VoiceOver says link, Home, Primary, navigation. Not the content. On a real site that header can hold dozens of links, and keyboard and screen reader users have to tab through it on every page load. Add a skip link and the problem looks solved. But if its href points at an id that doesn't exist, activation goes nowhere.

WCAG 2.4.1 Bypass Blocks (Level A) requires a way to skip blocks of content that repeat across pages. A skip link only counts if it actually moves the user past the repeated block.

Two ways it breaks

No skip link. The first focusable node is link "Home" inside navigation "Primary". You only reach main after every nav link. There's no mechanism at all.
Skip link with a mismatched target. This one looks fixed. The link is first in Tab order and visible on focus, and VoiceOver announces it correctly: visited, link, Skip to main content. But the code looks like this:

<a href="#main">Skip to main content</a>
<header>Study Lab</header>
<nav aria-label="Primary">…</nav>
<main id="skip-to-content-broken-case2-main">…</main>

There's no element with id="main". After activation, focus is still inside the navigation. The problem isn't what the link says. It's where it goes, and you only see that in the accessibility tree, not in the announcement.

Auditors test activation, not presence: press Enter and check where focus goes. Landmarks like nav and main help screen reader users, but sighted keyboard users have no landmark shortcut, so a broken skip link is still a defect.

The fix

Make the skip link the first focusable element, make its href fragment match a real id, and give the target tabindex="-1" so it can take programmatic focus:

<a class="skip-link" href="#main-content">Skip to main content</a>
<header>…</header>
<nav aria-label="Primary">…</nav>
<main id="main-content" tabindex="-1">…</main>

In React/JSX that's tabIndex={-1}. -1 lets main take focus from script or fragment navigation without adding it to the Tab order.

Hide it until it's focused:

.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 1rem;
  top: 1rem;
  z-index: 1000;
}

Behaviors to verify

The first Tab on the page reaches the skip link, and it's visible when focused.
Pressing Enter moves focus into the main content, so the next thing read is content, not navigation.
The href fragment matches an id that exists exactly once, and the target has tabindex="-1". Check it in the accessibility tree and with a screen reader before shipping.

Practice it

Video: https://youtu.be/uuevKPHlgDk
Short: https://youtube.com/shorts/gnGrnoXHhCI
Companion write-up: https://www.wasexamprep.com/blog/skip-link-is-not-a-bypass

Takeaway: a skip link that doesn't land is not a bypass. Test activation, not presence.

If this was useful, subscribe to A11Y in Practice on YouTube (@a11yinpractice) for more hands-on accessibility episodes, and visit wasexamprep.com for WAS study notes and labs.

A11Y in Practice and wasexamprep.com are independent educational resources. They are not affiliated with or endorsed by IAAP (International Association of Accessibility Professionals).

A Custom Div Is Not a Checkbox: WCAG 4.1.2 Name, Role, Value

A11Y Practice — Wed, 07 Oct 2026 08:05:22 +0000

You build a toggle that looks like a checkbox. You style two shipping options as buttons. Sighted users get it. Then you open VoiceOver.

On the custom toggle, from a real capture: Email notifications (custom) - and the hint: you are currently on a button, group. No checkbox role. No checked state. Beside it, the native control announces as a checkbox. Same job. Completely different exposure.

WCAG 4.1.2 Name, Role, Value says the role and value must be programmatically determinable. Native checkbox, radio, and fieldset give you that for free. A click-only div or plain buttons that fake selection fail 4.1.2 - missing roles, missing value.

Why this trips people up

Two failure patterns show up a lot:

Custom "checkbox" with no widget role - a clickable div that looks finished. In the accessibility tree you may only get StaticText. Tab can skip it entirely.
Buttons faking a radio group - sibling buttons with no radiogroup parent and no "1 of 2" / "2 of 2". They look like a choice group. VoiceOver hears two independent buttons.

What to do instead

Prefer native checkbox / radio / fieldset when you can
When you must build custom: role="checkbox" + focusability + aria-checked, or role="radiogroup" with role="radio" on each option
Extra ARIA is not the goal - the correct widget roles are. Then verify with a screen reader

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

Takeaway: a custom div that looks like a checkbox is not a checkbox until assistive tech gets the role and value - prefer native HTML when you can.

Static Text Is Not a Status Message: WCAG 4.1.3 Live Regions

A11Y Practice — Wed, 30 Sep 2026 17:03:24 +0000

You click Add item. The cart count ticks from zero to one. You click Save. The status flips to Saved. Sighted users see it instantly. On that button with VoiceOver, what do you hear?

Often: still the button hint - and nothing about the cart or Saved. Static text on the page is not a status message.

WCAG 4.1.3 Status Messages is about announcing that kind of update without moving focus.

Why this trips people up

Two failure patterns show up a lot:

No live region at all - the DOM updates, the screen updates, assistive tech stays quiet.
The trap - aria-live (or role="status") is on a wrapper, but the changing text sits outside that node. The live region never sees a relevant update.

What to put on the changing node

aria-live="polite" and/or role="status" on the element whose text content actually changes
Prefer polite for non-urgent cart/status UI; keep assertive for rare urgent cases
Do not assume "I added aria-live somewhere nearby" is enough - verify with a screen reader

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

Takeaway: put the live region on the changing text node, not on a silent wrapper.

Focusable Is Not Keyboard-Operable: WCAG 2.1.1 on Custom Controls

A11Y Practice — Thu, 24 Sep 2026 05:20:33 +0000

You Tab to a custom checkbox. The focus ring shows up. You press Space - nothing. Click with the mouse and it toggles.

So is it accessible?

WCAG 2.1.1 Keyboard says the functionality must be available from a keyboard. Landing focus on the control is not enough.

Why tools miss it

In the broken lab case, the accessibility tree still exposes a checkbox with the right name and checked state. VoiceOver can announce it like a normal checkbox. The gap is the missing key handler (onClick only).

Same story for a custom radiogroup where every option has tabIndex={0} and arrow keys do nothing: the tree looks mostly fine; keyboard testing does not.

What to verify manually

Checkbox / switch: Space toggles
Radiogroup: arrows move selection; preferably one tab stop (roving tabindex)
Do not trust "focusable + role" alone

Practice it

I published a walkthrough on A11Y in Practice with broken vs fixed paths on the same free lab:

Part of WAS Exam Prep / WAS Lab study notes (independent; not affiliated with IAAP or W3C).

If this helped, the takeaway I keep repeating: roles name the widget. Keys make it usable.