Focus indicator test page
Ten controls. Some have a visible focus indicator, some do not, and some have one that is too faint to count. Tab through them and look. Then run this page through whatever accessibility checker you use and see how many of them it has an opinion about.
This page is a fixture, not a demo. Every case is a pattern that occurs in real code. Each one states the correct answer underneath, so you can check our result as easily as anyone else's.
Why this page exists
The most widely used engine in this field, axe-core, has no rule for
either of these success criteria. You can check that yourself: search the shipped
bundle for wcag247 or wcag1411 and you will find nothing.
Anything built on axe-core inherits that gap, which includes Lighthouse.
Deque publish their own field data across roughly 300,000 real issues. For 2.4.7 Focus Visible they record 7,312 issues and 0.00% automated capture. For 1.4.11 Non-text Contrast, 4,539 issues and 0.00%.
This is not an oversight. axe-core's lead maintainer explains it in issue 4262: judging visible focus without false positives would mean actually focusing elements in the page, and "axe-core is built to do single-state testing". A tool that reads the DOM once cannot see a style that only exists while something is focused.
W3C's ACT Rules describe the method that does work (rule oj04fd): compare the pixels of the element focused against the same element unfocused, and look for a difference. That requires a real browser and two states.
Who else tests these, honestly
It would be easy to imply nobody does. Three vendors do claim 2.4.7, and we would rather say so than have you find out.
- Siteimprove has a rule for it. Their engine, Alfa, is open source, so you can read what it actually does: sia-r65 compares computed CSS styles between the focused and unfocused states, not pixels, and when that finds nothing it hands the question to a human rather than failing. Their own help page says the automation fails "when the focus indicator is injected on the website using JavaScript" — which is case 3 below.
- Silktide lists 2.4.7 as an automated check, described as "ensure controls change appearance when they are selected". They do not publish the method. Detecting that something changed is not the same as judging whether the change can be seen — case 4 below is the difference.
- Evinced markets computer vision for focus-indicator contrast. Their own rule documentation maps that check to SC 1.4.1 Use of Colour rather than 1.4.11, and they publish no method.
1.4.11 Non-text Contrast is the wider gap. Siteimprove's rule package maps 35 success criteria and 1.4.11 is not among them; Evinced has no web rule for it; Silktide's covers form controls only. And 2.4.13 Focus Appearance — the criterion that actually specifies a 3:1 difference between focused and unfocused pixels — has no check at any of the three.
All of that was read from their own documentation and source in September 2026. If any of it is out of date, tell us and we will correct this page.
The fixtures
1. Outline removed, nothing put back
Correct verdict: fails 2.4.7. outline: none with no replacement. This is the one case a static analyser can catch, because the removal is visible in the stylesheet.
2. Focus ring drawn with box-shadow
Correct verdict: passes. The outline is removed but a 3px shadow ring replaces it. A tool that only sees outline: none will report a failure that is not there — the most common false positive in this criterion.
3. Focus styles applied by JavaScript
Correct verdict: passes. Nothing in the stylesheet says so — the ring is set from a focus event handler. Reading CSS cannot answer this one either way.
4. A focus ring you cannot see
Correct verdict: fails. There is an outline, and it is #f2f2f2 on a white background — about 1.1:1. Present in the CSS, invisible on screen. Checking that an outline exists is not the same as checking it can be seen.
5. :focus-visible only
Correct verdict: passes for keyboard users. Worth knowing: a checker that focuses elements programmatically does not trigger :focus-visible, so this case has to be recognised from the stylesheet. We say so in our own report rather than pretending we measured it.
6. Indicator hidden behind a sticky header
Correct verdict: fails 2.4.11 Focus Not Obscured. The ring is drawn, and something covers it. Geometry, not CSS.
7. Input border too faint
Correct verdict: fails 1.4.11. The border is #dcdcdc on white, about 1.4:1, where the criterion asks for 3:1. Nothing else marks the field's boundary.
8. Faint border, but the control is filled
Correct verdict: passes. Same faint border as case 7, but the button's own fill stands well clear of the page behind it, and that is what identifies the control. A checker that only measures the border reports a failure here. We used to, until this page's sibling case found it.
9. Checkbox with a low-contrast boundary
Correct verdict: fails 1.4.11. A custom checkbox whose only boundary is #e8e8e8 on white.
10. Link distinguished by colour alone
A paragraph of ordinary text with a link inside it that carries no underline.
Correct verdict: fails 1.4.1 Use of Colour — the link is #5a7fa8 against #333333 body text, about 1.6:1 between them, and nothing else marks it as a link.
What we found when we ran it
Measured 2026-09-23. We publish our own result so it can be checked, and we will correct it here if it is wrong.
Run this page through our free checker — no account needed. Then run it through yours.
If your tool catches something ours misses, we would rather know. Tell us and we will fix it and say so here.