Focus Indicator & :focus-visible Checker
Scan stylesheets and live webpages for destructive outline: none declarations and missing :focus-visible rules.
<style> blocks within the fetched HTML — it does not download externally linked stylesheets (<link rel="stylesheet">), which is how most WordPress themes actually deliver their CSS. If a page has no inline styles, this scan cannot evaluate its real focus-ring rules. For a genuine audit, paste your theme's compiled CSS directly using the "Paste CSS Stylesheet" tab above.Technical Deep-Dive: Focus Indicators and WCAG Compliance
📌 On this page
- 1. Why the default browser outline gets removed so often
- 2. :focus vs :focus-visible: the key distinction
- 3. WCAG 2.4.7 vs WCAG 2.2's 2.4.13 Focus Appearance
- 4. Designing a focus ring that meets contrast requirements
- 5. Common frameworks and libraries that strip focus styles
- 6. How this tool's scoring works
1. Why the default browser outline gets removed so often
Every browser ships a built-in focus outline (a blue ring in Chrome, a similar highlight in other browsers), and it has a well-earned reputation among designers for looking visually inconsistent with custom UI and clashing with rounded corners or dark themes. This has led to a long-standing, damaging pattern: developers add outline: none or outline: 0 to "clean up" the design, often copy-pasted from a CSS reset or framework boilerplate, without realizing they have just made every interactive element on the page invisible to keyboard navigation.
2. :focus vs :focus-visible: the key distinction
The :focus pseudo-class matches an element whenever it has keyboard or programmatic focus, including after a mouse click — which is why older focus-ring implementations often looked "flashy" on every click and led some developers to remove them entirely out of frustration. :focus-visible is the browser's own heuristic for "focus that the user would actually want to see visually" — it fires reliably for Tab-key navigation but is suppressed after a plain mouse click in most cases, letting you show a clean, visible ring only for the users who genuinely need it (keyboard and assistive-technology users) without visual noise for mouse users.
3. WCAG 2.4.7 vs WCAG 2.2's 2.4.13 Focus Appearance
WCAG 2.1's Success Criterion 2.4.7 (Focus Visible) is a Level AA requirement that simply mandates any visible indicator exists at all when an element receives keyboard focus — it does not specify exact size or contrast. WCAG 2.2 introduced the stricter 2.4.13 (Focus Appearance) as an additional AA criterion, which does specify measurable requirements: the focus indicator must have an area at least equivalent to a 2px-thick perimeter around the component, and a minimum 3:1 contrast ratio against both the unfocused and focused states of adjacent colors. A site can technically pass 2.4.7 with a barely visible 1px outline while still failing the newer 2.4.13 standard.
4. Designing a focus ring that meets contrast requirements
A safe, broadly compatible approach is a solid-color outline at least 2px thick with outline-offset to create visual separation from the element's edge, using a color that maintains 3:1 contrast against both the element's background and the surrounding page background — since focus rings can appear over varying backgrounds depending on where an element sits on the page, testing against your site's actual color palette (not just a single swatch) matters. The boilerplate CSS above uses this pattern as a reasonable starting point, but always verify actual contrast values with a contrast-checking tool against your specific brand colors.
5. Common frameworks and libraries that strip focus styles
Several widely used CSS resets and utility frameworks have historically included outline: none as part of their base styles, intended to be paired with custom focus styling that developers sometimes forget to add. Popular UI component libraries and some WordPress page builders' generated CSS have also shipped with this pattern in past versions. If a focus-ring audit turns up unexpected "outline: none" declarations you didn't write yourself, check whether they originate from a third-party library or framework reset rather than your own theme code — the fix location differs accordingly.
6. How this tool's scoring works
The 100-point score starts at full marks and subtracts 25 points for each detected outline: none or outline: 0 declaration (a direct WCAG 2.4.7 violation risk), and an additional 20 points if no :focus or :focus-visible rules exist anywhere in the analyzed CSS at all (indicating no custom focus styling was ever configured). This is a static-analysis heuristic based on pattern matching against the provided CSS text — it does not render the page or verify that focus styles actually meet the 3:1 contrast and 2px-area requirements of WCAG 2.2's 2.4.13; use a dedicated contrast checker alongside this tool for full compliance verification.
Frequently Asked Questions
Why is "outline: none" one of the most critical accessibility violations?
Keyboard-only and switch-device users navigate websites by pressing the Tab key. The browser focus outline is the only visual cue indicating which button, link, or form field is currently selected. Removing it makes the site impossible to navigate without a mouse.
What is the modern standard for styling focus rings (:focus-visible)?
Instead of removing outlines globally, use :focus-visible. It displays focus indicators only when navigating via keyboard or assistive technology, while suppressing them on mouse/touch clicks.
What are the WCAG 2.2 SC 2.4.13 (Focus Appearance) requirements?
Under WCAG 2.2 Level AA, the focus indicator must have an area at least as large as a 2px solid perimeter around the component and a contrast ratio of at least 3:1 against adjacent colors in both focused and unfocused states.
Does this tool enforce SSRF security checks?
Yes. All live audits enforce strict SSRF safeguards, blocking requests to private networks, loopbacks, and cloud metadata IPs.
Does the live URL scan check my theme's actual external stylesheet?
No — this is an important limitation to understand. The live scan only reads CSS from inline <style> blocks present in the fetched HTML; it does not fetch or parse externally linked stylesheet files (<link rel="stylesheet" href="...">), which is how the vast majority of WordPress themes actually deliver their CSS. If your page has no inline styles, use the "Paste CSS Stylesheet" tab and paste your theme's real compiled CSS for an accurate audit.
Is removing "outline: none" always the right fix?
Removing the declaration entirely is the safest fix, since it restores the browser default focus ring — but many teams remove it because the default outline clashed with their design. In that case, replace it (do not just delete it) with a custom, visible focus style using :focus-visible, ensuring the replacement meets the WCAG 2.4.7 visibility requirement and, under WCAG 2.2, the 2.4.13 contrast/size requirements described below.