SCR28Sufficient technique WCAG 2.4.1 Level A Partly scanner-detectable

Collapse repeated blocks so they can be skipped

SCR28 is a sufficient technique for getting past a block of repeated material, qualified for the case where that material has been grouped so it can be skipped. A navigation block starts collapsed behind one toggle. One Tab press clears the whole block. There is one check inside this technique that decides pass or fail, and it is the one nobody runs. Collapsed content must be out of the programmatically determined content, not merely out of sight. Hide a menu with visibility or opacity and the forty-two links are still in the accessibility tree. A screen reader user walks every one of them, and the technique has bought them nothing. Expanded, the content has to come back at a sensible place in reading order. And a plain skip link is simpler than any of this, which is our view rather than W3C's, so start there unless the design rules it out.

How we find it in an audit

The toggle gets worked from the keyboard, and then the accessibility tree gets read while the menu is closed. That second step is the whole audit. If the links are still there, the finding stands whatever the screen shows. We also check that the toggle reports its own state, that expanding puts the content somewhere that follows on, and that the control is reachable early enough to be worth having. A scanner can confirm an aria-expanded attribute exists and flips. It cannot confirm the content it claims to control has actually left.

How affected users experience it

Forty-two navigation links, on every page, in the same order, before the first sentence of the article. A sighted reader's eye skips the block without noticing it. A screen reader user hears it, or tabs through it, and the cost is paid again on the next page and the page after that. Someone using a switch device presses forty-two times. When a collapsed menu is only visually collapsed the experience is worse than honest, because the page now looks considerate and behaves exactly as it did before.

Passes vs. fails

Passes: one jump past the header. Fails: tab through everything, every page.

Passes

<button aria-expanded="false" onclick="toggleMenu()">Site menu</button>
<ul id="site-menu" hidden></ul>
<!-- hidden takes the list out of the tree, so one Tab press clears the whole block. -->

Fails

.site-menu { visibility: hidden; }
<!-- Off screen and still in the accessibility tree. All 42 links remain in the tab order. -->

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Bypass Blocks of Repeated ContentA tool finds candidates, you decide
Document has heading for non-repeated contentNothing implements this yet
Document has a landmark with non-repeated contentA tool can check this
Block of repeated content is collapsibleNothing implements this yet
Document has an instrument to move focus to non-repeated contentNothing implements this yet

Other ways to satisfy this rule

10 guides on this site are filed under 2.4.1 Bypass Blocks. W3C lists this one as sufficient for that rule when used for grouping blocks of repeated material in a way that can be skipped, so the condition is part of the test rather than a footnote to it.

This guide is our interpretation of W3C technique SCR28: Using an expandable and collapsible menu to bypass block of content. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.