SCR27Sufficient technique WCAG 2.4.3 Level A Human testing required

Reorder sections in the DOM, not just on screen

SCR27 is a sufficient technique for focus order, and most summaries of it describe half of it. The half everyone knows is the DOM work. When a user reorders something, move the actual nodes with removeChild and insertBefore rather than shuffling CSS boxes, so reading order and tab order both follow what the user now sees. The half everyone drops is the reason the technique exists. W3C's method reorders through device-independent menus built from lists of links, held inside the items they reorder, triggered from the onclick event of those links. Four of the five test steps are about that menu. So the technique is not really a note about the DOM. It is a keyboard alternative to drag and drop, and a dashboard whose only reorder mechanism is a pointer drag has excluded keyboard users before the DOM question comes up at all. Dragging with no alternative is its own separate obligation under the dragging movements rule.

How we find it in an audit

Reviewers reorder something from the keyboard first, before touching a mouse. That check fails more often than any other here, and it takes ten seconds. If there is no way to do it, nothing about the DOM will save the feature. When a keyboard route does exist we use it, then inspect the tree to confirm the nodes moved rather than the styles. Automated tools can spot CSS order and flex-direction properties changing under script, which points at where to look. Whether the result still makes sense in reading order is a person's call.

How affected users experience it

Two different people get hurt here in two different ways. Someone who cannot hold a mouse button down and travel with it cannot reorder anything at all, so the personalization your dashboard sells is not on offer to them. Someone using a screen reader can reorder, watches nothing change, and gets the modules read out in the old order forever. Only a stylesheet moved. The layout on screen and the layout they hear have quietly become two different pages.

Passes vs. fails

Passes: focus follows the layout. Fails: focus teleports around the page.

Passes

list.insertBefore(tasksNode, list.firstChild);
<!-- Inside each module: --> <a href="#" onclick="moveUp(this)">Move up</a>
<!-- The node really moves, and there is a keyboard way to move it. -->

Fails

tasks.style.order = "-1";
// The module jumps to the top on screen. Tab still visits it fourth.

Other ways to satisfy this rule

8 guides on this site are filed under 2.4.3 Focus Order. W3C lists this one as sufficient for that rule when used for changing a web page dynamically, so the condition is part of the test rather than a footnote to it.

This guide is our interpretation of W3C technique SCR27: Reordering page sections using the Document Object Model. 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.