When should you use Keyboard focus is visible?

Run this whenever styles change. The single most common way to break keyboard accessibility is a stylesheet line removing the browser's focus outline without putting anything in its place, and it is invisible to anyone testing with a mouse. Run it at phone and desktop widths, because different elements are on screen at each.

It proves focus changes something visible; it does not judge whether the change is strong enough. The contrast and size of a focus indicator are the subject of WCAG 2.2's newer criteria (2.4.11 and 2.4.13), which are not decided here. It examines the first 40 focus stops.

outline: none with no replacement style; custom buttons that show no focus; focus landing on off-screen elements

A failure names an element whose surroundings look pixel-for-pixel identical focused and unfocused, or an element that takes focus while not visible on screen. A keyboard user arriving there cannot tell where they are. Elements next to video, canvas or moving content are listed for review, because that content changes the pixels by itself.

There is no threshold beyond "something visible changes". The comparison is exact, taken with the page held still and the text caret hidden, so any genuine indicator — outline, underline, colour, shadow — is detected.

SchemaFirst.org publishes community-governed standards for digital QA. ArbiterQA is a supporter and commercial licensee of those standards; citation does not mean SchemaFirst operates ArbiterQA.