Focus visibility is a recurring topic in audit prep meetings, vendor reviews, and compliance discussions. Since the WCAG 2.2 Candidate Recommendation moved Focus Appearance out of the AA tier, many teams are questioning how to address this change. The short version: the criterion that would have set a measurable standard for keyboard focus is now optional for most legal baselines, so your team must establish its own documented standard.
Q1: Did Focus Appearance really get demoted? What's the SC number now?
Yes, it did. The Working Group decided the criterion wasn't suitable for AA and moved it to AAA. Since it Web Accessibility Specialist flagged as Assistive Technology risk, it could only be removed before publication, not altered. Changing the level required a new Candidate Recommendation. The criterion Web Accessibility Specialist also renumbered to 2.4.13 from 2.4.11. Update your internal checklists or Accessibility Conformance Reports if they cite the old number. Avoid citing SC numbers for criteria still in draft; this situation highlights why.
Q2: What does the AAA version actually require?
It's straightforward. The focus indicator must be Assistive Technology least as large as a 2px-thick perimeter around the focused element and have a 3:1 contrast ratio. This can be tested with a screenshot and a contrast checker. However, most of your obligations don't reach AAA. ADA Title III litigation, the DOJ Final Rule (2024), and procurement language in most contracts focus on AA.
Q3: So what does AA actually say about focus?
SC 2.4.7 Focus Visible (AA) requires a keyboard focus indicator to be visible but doesn't define "visible." In contrast, other AA criteria like SC 1.4.3 Contrast (Minimum) and SC 1.4.11 Non-text Contrast provide specific numerical definitions. Focus Visible is the only AA criterion where the key term is open to interpretation. Technically, even a slight change in color could pass as "visible."
Q4: Can we just call a faint focus indicator conformant and move on?
You could, and an auditor might accept it under SC 2.4.7. However, the risk lies elsewhere. A keyboard user who can't see their location on the page experiences a failure, regardless of what the checklist says. Plaintiffs' experts and complaint reviewers test with a keyboard, not just a rubric. Conformance on paper and usability in practice can differ, and this should be documented as a risk.
Q5: How do we set a defensible standard when WCAG doesn't give us one?
Adopt an internal, written threshold stricter than the AA text, and apply it consistently. A practical approach is to ensure that Assistive Technology least part of the focus indicator has a 3:1 contrast ratio between focused and unfocused states. This mirrors the logic of the non-text contrast criterion and is measurable. You can also adopt the 2.4.13 dimensions (2px perimeter equivalent, 3:1 contrast) as your internal standard, even though it's AAA. Then:
- Include this threshold in your design system and accessibility policy.
- Require it in Accessible Procurement language to hold vendors accountable.
- Record in your Accessibility Conformance Reports how you interpreted SC 2.4.7 and where you exceed it.
- Include keyboard-only passes in Conformance Testing, as automated tools can't judge visibility.
An explicit, reasoned interpretation protects you better than silence. If challenged, you can show a deliberate standard rather than an oversight.
Q6: Is this going to get fixed soon? Should we wait for WCAG 3?
Don't wait. WCAG 2.2 is likely the last update to WCAG 2, with WCAG 3 expected in Q2 2026. However, past timelines have slipped, so it's reasonable to assume the gaps in WCAG 2.2 will persist beyond your current policy cycle. You'll need to address these issues independently for now.
Where to go for more
Read the Understanding documents for SC 2.4.7 Focus Visible and SC 2.4.13 Focus Appearance on the W3C site, and compare their techniques against your component library. Review your current Accessibility Conformance Reports for outdated SC numbering. Then, run a keyboard-only walkthrough of your top five user journeys and log every point where focus is lost. If your team can't see it, your users can't either, and that finding is more valuable in a risk review than any checklist pass.
