Do not use script to throw focus away
This is a documented failure, so a page matching it has a defect rather than a solution. F55 is script that takes focus away the moment an element receives it, almost always a blur() call fired from a focus handler. W3C's own account of the motive is that somebody considered the system focus indicator unsightly. The consequence reaches further than the ring. Focus removed from the content entirely means the content can only be operated with a pointing device. That is why one failure breaks four separate rules at once, and W3C's title names all four. 2.1.1 Keyboard, 2.4.7 Focus Visible, 2.4.13 Focus Appearance at Level AAA, and 3.2.1 On Focus. There is a legitimate version of moving focus and it is worth naming, because teams read this failure as focus must never move. Focus may move when the user asked for it. Into a dialog they opened, back to the trigger when it closes, to the first error after they pressed submit.
How we find it in an audit
W3C's test is two steps and it is exactly what a reviewer does. Reach every interactive element from the keyboard, then check that focus stays where it landed until the user moves it. We tab through with the console open, so when focus arrives and then vanishes we can trace the handler responsible. The finding names the code to delete instead of describing a symptom. Focus that teleports rather than disappearing shows up the same way.
How affected users experience it
For a screen reader user, focus is position. It is where they are in the document, the way a cursor is where you are in a sentence. Code that moves it without being asked is being picked up mid-paragraph and put down somewhere else, with nothing announcing what happened, and reorienting costs the whole context they had built. For a sighted keyboard user the same code is quieter and just as final. Tab moves something invisible, Enter fires at something unknown, and on a form the field simply refuses to accept typing.
Passes vs. fails
Passes
/* focus moves only when the user asked for it */
dialog.addEventListener("close", () => trigger.focus());Fails
<input type="submit" value="Send" onfocus="this.blur();">How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Iframe with interactive elements is not excluded from tab-orderA tool can check this
- Scrollable content can be reached with sequential focus navigationA tool can check this
- Element in sequential focus order has visible focusA tool can check this
The other techniques filed under this rule
13 guides on this site are filed under 2.1.1 Keyboard. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- G90sufficientPair every event handler with keyboard support
- G202sufficientMake every control work with a keyboard
- H91sufficientUse native HTML controls instead of rebuilt ones
- PDF3sufficientFix the reading and tab order in PDFs
- PDF11sufficientTag PDF links so they are announced
- PDF23sufficientUse fillable form fields instead of flat text
This guide is our interpretation of W3C technique F55: Failure of Success Criteria 2.1.1, 2.4.7, 2.4.13, and 3.2.1 due to using script to remove focus when focus is received. 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.