The 2025 TestParty Guide to WCAG 2.4.12 – Focus Not Obscured (Enhanced) (Level AAA)

Why did the focused button go to therapy? Because it kept getting covered up by sticky headers and felt invisible!

WCAG 2.4.12 Focus Not Obscured (Enhanced) ensures that when keyboard users navigate to an interactive element, the entire element remains visible—no part of it can be hidden by sticky headers, floating toolbars, cookie banners, or other author-created content. This Level AAA criterion takes accessibility a step further than its Level AA counterpart (2.4.11), demanding complete visibility rather than partial.

Table of Contents

• What WCAG 2.4.12 Requires
• Why This Matters
• Quick Implementation Guide
• Common Mistakes to Avoid
• How to Test for WCAG 2.4.12
• How TestParty Helps
• FAQs

What WCAG 2.4.12 Requires

WCAG 2.4.12 requires that when any user interface component receives keyboard focus, no part of that component is hidden by author-created content.

Key points:

• Complete visibility: Unlike 2.4.11 (Minimum), which allows partial obscuring, this enhanced criterion demands the focused element be 100% visible
• Author-created content only: Browser UI elements (address bars, browser toolbars) don't count—only content you control
• Applies to all focusable elements: Links, buttons, form fields, custom widgets, anything that can receive keyboard focus
• Persistent overlays: Sticky headers, fixed footers, floating chat widgets, cookie banners, and notification bars are common culprits

What's excluded:

• User-initiated overlays (like opening a dropdown menu that temporarily covers other content)
• Browser chrome and operating system UI
• Content obscured by user settings (zoom, custom stylesheets)

Why This Matters

Keyboard-only users—including many people with motor disabilities, blind users navigating with screen readers, and power users who prefer keyboard navigation—rely on visual focus indicators to know where they are on the page. When sticky headers or floating elements cover the focused item, these users lose their place and can't interact with the interface effectively.

Legal and compliance context:

WCAG 2.4.12 is a Level AAA criterion, meaning it's not typically required for baseline ADA, Section 508, or EN 301 549 compliance (which mandate Level AA). However, organizations pursuing excellence in accessibility, government agencies with AAA mandates, or companies facing legal scrutiny often adopt AAA criteria. The European Accessibility Act encourages going beyond minimum standards where feasible.

Business case:

Even if AAA isn't legally required for your organization, this criterion addresses a real usability problem. Sticky headers and persistent navigation are ubiquitous in modern web design. Implementing 2.4.12 improves the experience for all keyboard users, reduces support tickets about "lost" focus, and demonstrates commitment to inclusive design—a differentiator in procurement and brand reputation.

Quick Implementation Guide

The most effective solution is CSS scroll-padding combined with thoughtful layout design.

1. Use CSS scroll-padding to account for fixed elements

When an element receives focus and the browser scrolls it into view, scroll-padding creates a buffer zone so fixed headers don't cover it.

html {
  scroll-padding-top: 80px; /* Height of your sticky header */
}

/* If you have fixed footers or side panels */
html {
  scroll-padding-top: 80px;
  scroll-padding-bottom: 60px;
  scroll-padding-left: 200px; /* For fixed sidebars */
}

2. Ensure focus indicators are fully visible

If your focus outline extends beyond the element's bounding box, account for that in your scroll padding.

3. Test with sticky/fixed positioning

Audit all position: fixed and position: sticky elements. Calculate their total height/width and adjust scroll-padding accordingly.

4. Handle dynamic overlays

For cookie banners or notification bars that appear/disappear, update scroll-padding dynamically via JavaScript when they're shown or dismissed.

5. Consider z-index stacking

Ensure focused elements don't get covered by high z-index overlays. If a modal or tooltip appears, it should either be user-initiated (exempt) or positioned to avoid obscuring focus.

Key WCAG technique:

• C43: Using CSS scroll-padding to un-obscure content

Common Mistakes to Avoid

Sticky headers without scroll-padding

The most common violation. A 100px sticky header covers the top 100px of the viewport, but when users tab to a link near the top of the page, it scrolls under the header.

Fixed chat widgets covering corner elements

Floating chat buttons or help widgets in the bottom-right corner can obscure focused buttons, especially on smaller viewports.

Cookie banners that persist

Cookie consent banners that remain on-screen after initial load can cover focused elements at the bottom of the viewport. Either dismiss them automatically after consent or ensure they don't obscure focus.

Ignoring focus outline size

If your focus indicator is a 4px outline, and your scroll-padding exactly matches your header height, the outline itself might be partially hidden. Add a few extra pixels of buffer.

How to Test for WCAG 2.4.12

Manual keyboard testing (required):

1. Tab through the entire page using only the keyboard (Tab, Shift+Tab, arrow keys for custom widgets)
2. Watch for obscured focus: Does any part of the focused element disappear behind sticky headers, footers, or floating UI?
3. Test at different viewport sizes: Resize your browser—smaller viewports often reveal issues
4. Test with browser zoom: At 200% zoom, fixed elements take up more relative space

Automated tool limitations:

Automated scanners can identify fixed-position elements and flag potential risks, but they can't reliably determine if a focused element is obscured in every layout scenario. This criterion requires human judgment.

What tools can help:

• Browser DevTools to inspect position: fixed/sticky elements and measure their dimensions
• Accessibility testing extensions (axe DevTools, WAVE) to identify focusable elements
• Custom scripts to tab through all focusable elements and check their getBoundingClientRect() against fixed overlays

Checklist:

• [ ] All focusable elements remain 100% visible when focused
• [ ] Scroll-padding accounts for all fixed/sticky UI elements
• [ ] Focus indicators (outlines, rings) are not clipped
• [ ] Dynamic overlays (banners, notifications) don't obscure focus

How TestParty Helps

TestParty's AI-powered platform automates detection of focus obscuring issues and integrates compliance checks directly into your development workflow.

What TestParty detects:

TestParty's DOM and visual regression analysis identifies:

• Fixed and sticky positioned elements that could obscure focus (headers, footers, sidebars, chat widgets, cookie banners)
• Missing or insufficient scroll-padding declarations in your CSS
• Z-index stacking conflicts where high-z-index overlays cover focusable content
• Focus indicator clipping where outlines or shadows are cut off by fixed elements
• Viewport-specific issues by testing across multiple screen sizes and zoom levels

TestParty simulates keyboard navigation through your interface, programmatically focusing each interactive element and measuring whether any part of it is hidden by author-created content. It flags violations with specific element selectors and computed positions.

How TestParty suggests fixes:

For each detected issue, TestParty generates concrete remediation guidance:

• Calculated scroll-padding values based on the measured height/width of your fixed elements (e.g., "Add scroll-padding-top: 85px; to account for your 80px header plus 5px focus outline")
• CSS diffs showing exactly where to add or modify scroll-padding properties
• JavaScript snippets for dynamically adjusting scroll-padding when overlays appear or disappear
• Layout refactoring suggestions when fixed positioning itself is the problem (e.g., recommending a collapsible header on scroll)

All AI-generated fixes are reviewed by TestParty accessibility specialists or your development team before merging, ensuring changes fit your design system and don't introduce regressions.

Developer workflow integration:

TestParty integrates into your CI/CD pipeline and code review process:

• Pre-merge checks: Pull request annotations flag focus obscuring issues with line-level comments on the CSS or component code responsible
• CI/CD gates: Block deployments if critical AAA violations are introduced (configurable—most teams treat AAA as warnings rather than blockers, but you can enforce it)
• IDE integration: Real-time linting in VS Code, WebStorm, or your editor of choice, surfacing 2.4.12 issues as you write CSS

This shift-left approach catches focus obscuring problems during development, before they reach production—especially valuable when adding new sticky UI elements or refactoring layouts.

Ongoing monitoring:

After remediation, TestParty continuously monitors your site:

• Regression detection: Alerts you if a new deploy introduces fixed-position elements without corresponding scroll-padding
• Template-level fixes: For ecommerce platforms (Shopify, WordPress) or design systems, TestParty applies fixes at the theme/component level, cascading corrections across thousands of pages
• Audit-ready reports: Dashboards showing 2.4.12 compliance status over time, with evidence for legal, procurement, or certification reviews

TestParty's monitoring is particularly useful for large sites where multiple teams ship code—one team's new sticky promo banner can inadvertently break keyboard navigation site-wide.

Because 2.4.12 is a Level AAA criterion requiring nuanced visual testing, TestParty combines automated detection with embedded guidance, helping your team understand not just what to fix but why focus visibility matters and how to prevent future issues.

Some TestParty features described in this article are currently under development. Visit TestParty.ai to learn more about our current capabilities and roadmap, or book a demo at TestParty.ai/book-a-demo to see TestParty in action.

Disclaimer: Some of this article was generated with Large Language Models (LLMs) and Artificial Intelligence (AI). There may be some errors and we advise you to consult with human professionals for detailed questions.

FAQs About WCAG 2.4.12

What is WCAG 2.4.12 in plain language?

WCAG 2.4.12 (Focus Not Obscured - Enhanced) means that when someone navigates your site with a keyboard, the element they're focused on must be completely visible—no part of it can be hidden by sticky headers, floating buttons, or other fixed UI elements. This is the stricter, Level AAA version of the criterion.

Is WCAG 2.4.12 required for ADA compliance?

No, WCAG 2.4.12 is a Level AAA criterion and is not required for baseline ADA compliance, which typically follows WCAG 2.1 Level AA. However, some government contracts, accessibility certifications, or organizations pursuing best-in-class accessibility may adopt AAA standards voluntarily.

What's the difference between 2.4.11 and 2.4.12?

WCAG 2.4.11 (Focus Not Obscured - Minimum, Level AA) allows a focused element to be partially hidden as long as some part remains visible. WCAG 2.4.12 (Enhanced, Level AAA) requires the entire focused element to be visible—no part can be obscured by author-created content.

Does scroll-padding work in all browsers?

CSS scroll-padding is supported in all modern browsers (Chrome, Firefox, Safari, Edge) as of 2020. For legacy browser support (IE11), you may need JavaScript-based scroll adjustments, though IE11 is no longer widely supported and most organizations have dropped compatibility.

What if my sticky header is essential for navigation?

Sticky headers are fine—you just need to ensure they don't cover focused elements. Use scroll-padding-top to create a buffer zone equal to (or slightly larger than) your header's height. The browser will automatically scroll focused elements into the visible area below the header.

Can automated tools fully test for 2.4.12 compliance?

No. Automated tools can identify fixed-position elements and flag potential risks, but determining whether a focused element is obscured in every layout scenario requires manual keyboard testing. Tools like TestParty combine automated detection with guided manual review to ensure comprehensive coverage.