WCAG 2.4.11: Focus Not Obscured (Minimum)

What This Rule Means

WCAG 2.4.11 Focus Not Obscured (Minimum) is a Level AA criterion introduced in WCAG 2.2 that addresses a common but serious accessibility problem: when a focused element is completely hidden behind another layer of content on the page. The criterion states that when any user interface component receives keyboard focus, that component must not be entirely concealed by author-created content.

The key word here is entirely. WCAG 2.4.11 sets the minimum bar — it only requires that some portion of the focused element remains visible. If a sticky navigation bar overlaps the top half of a focused button but the bottom half is still visible, that technically passes 2.4.11. The stricter companion criterion, WCAG 2.4.12 Focus Not Obscured (Enhanced) at Level AAA, goes further by requiring that the focused component is not obscured by author-created content at all — not even partially.

The types of author-created content most commonly responsible for this issue include sticky or fixed-position headers and footers, cookie consent banners, chat support widgets, notification toasts, modal overlays, floating action buttons, and bottom navigation bars on mobile-responsive layouts. These elements are rendered using CSS properties such as position: fixed, position: sticky, or high z-index values, which cause them to float above the normal document flow and potentially cover interactive elements that receive focus.

A pass means that when a keyboard user tabs through interactive elements, at least part of every focused element's visual indicator is visible on screen at all times — even if a sticky UI element overlaps part of it. A fail occurs when a focused element is completely hidden beneath an author-created layer, meaning the user has no visual cue whatsoever about where focus currently sits. Browser-rendered content such as a browser's own toolbar does not count as author-created content and is therefore excluded from this criterion's scope. Similarly, content that the user themselves has repositioned (such as a user-draggable panel) is also excluded.

This criterion applies to all interactive HTML elements that are keyboard-focusable by default or made focusable via tabindex, including <a>, <button>, <input>, <select>, <textarea>, and elements with tabindex='0' or positive tabindex values.

Why It Matters

Keyboard navigation is fundamental to accessibility for multiple groups of users. People with motor disabilities who cannot use a mouse rely entirely on keyboards, switch devices, or sip-and-puff controllers to move through a web page. People who are blind use screen readers in combination with keyboards. People with low vision who use keyboard navigation without a screen reader depend heavily on the visible focus indicator to understand where they are. When that focused element is hidden behind a sticky header or floating widget, these users are effectively lost — they must press Tab repeatedly, guess at their position, or abandon the task entirely.

Consider a concrete real-world scenario: a wheelchair user with limited hand mobility is completing a flight booking form on a Turkish airline's website. They use the Tab key to move through form fields. The page has a sticky cookie consent banner at the bottom of the viewport. As the user tabs into the final confirmation checkbox, the checkbox is rendered completely beneath the cookie banner. The user has no visual indication that the checkbox is focused. They cannot tell whether their Tab key press worked, whether they need to press Tab again, or whether the checkbox is even required. This confusion can lead to form abandonment, missed submissions, or repeated keystrokes that cause unintended actions.

The impact extends beyond users with disabilities. Power users who prefer keyboard navigation for speed — developers, data entry professionals, and proficient users — also benefit from clear focus visibility. According to the World Health Organization, approximately 1.3 billion people worldwide live with some form of disability, and a significant portion of those rely on assistive technologies or keyboard navigation. In Turkey specifically, the Turkish Statistical Institute (TÜİK) reports that around 12.7% of the population has some form of disability, which translates to roughly 10 million people who may directly benefit from improved focus management on digital platforms.

From a business perspective, obscured focus indicators increase task abandonment rates, reduce conversion, and expose organizations to legal and regulatory risk. Sites that fail to meet this criterion are also likely to fail accessibility audits required under Turkish law, jeopardizing their ability to obtain or maintain the official Erişilebilirlik Logosu (Accessibility Logo).

Related Axe-core Rules

WCAG 2.4.11 is classified as requiring manual testing in axe-core. There is no automated axe-core rule that directly detects this violation. Understanding why automated tools cannot reliably flag this issue helps teams build better manual testing processes.

• Manual Testing Required — Focus Obscured by Fixed Positioning: Automated tools cannot detect whether a focused element is visually obscured because determining this requires rendering the page, computing the bounding rectangles of all fixed or sticky elements at runtime, and comparing them against the bounding rectangle of the currently focused element at the moment of focus. The viewport dimensions, scroll position, and dynamic state of the page (such as whether a cookie banner has already been dismissed) all affect the outcome. No static analysis or DOM inspection can reliably replicate this visual calculation across all possible states. Axe-core flags this criterion as manual because it requires a human tester — or a sophisticated visual regression tool — to actually tab through the page and observe whether focused components disappear behind overlapping layers.
• Manual Testing Required — Dynamic Overlay Content: Many obscuring elements are injected dynamically via JavaScript after the initial page load — third-party chat widgets, GDPR compliance banners, promotional pop-ins, and floating navigation menus. Automated scanners that analyze the initial DOM snapshot may not capture these elements at all, or may capture them in a collapsed or hidden state that does not reflect the user's real experience. Manual testing by a keyboard user who interacts with the page in its fully rendered, dynamic state is the only reliable way to detect these scenarios.

How to Test

1. Run an automated accessibility scan first. Use axe DevTools (browser extension), Lighthouse in Chrome DevTools, or a CI-integrated axe-core scan to identify any automatically detectable issues on the page. While 2.4.11 itself requires manual verification, an automated scan may surface related problems such as missing focus indicators (2.4.7) or incorrect z-index stacking that suggests overlapping elements. Note all elements flagged as potentially problematic before beginning manual testing.
2. Identify all fixed and sticky elements on the page. Open browser DevTools and inspect the CSS of the page. Search for elements using position: fixed or position: sticky. Also check for elements with high z-index values (e.g., 100 or above). Document each of these elements — headers, footers, banners, chat widgets, cookie notices — as they are the most likely candidates for obscuring focused components. Resize the browser window to simulate different viewport sizes, including tablet and mobile widths, as sticky/fixed elements often behave differently across breakpoints.
3. Perform a full keyboard tab traversal. Click outside any interactive element to ensure focus starts from the top of the page, then press Tab repeatedly to cycle through every focusable element. Watch each element carefully as it receives focus. Pay particular attention to elements that appear near the top or bottom of the viewport, where fixed headers or footers are most likely to overlap. If at any point the visible focus ring or highlighted element disappears completely behind a fixed layer, that is a failure of 2.4.11. Use Shift+Tab to traverse in reverse as well, since scroll position and layout may differ.
4. Test with NVDA and Firefox. Open NVDA (free, open-source screen reader for Windows) and launch Firefox. Enable NVDA's browse mode and use Tab to move through the page. While NVDA will announce each focused element audibly, also observe the screen visually. Note any element where NVDA announces focus but no visual focus indicator is visible due to obscuring content. This combination is widely used in Turkey and globally and represents a key assistive technology pairing.
5. Test with VoiceOver and Safari on macOS/iOS. Enable VoiceOver (Command+F5 on Mac) and use Tab or VoiceOver's navigation gestures to move through focusable elements. On iOS, use swipe gestures. Verify that focused elements are visually present and not hidden beneath fixed UI layers, particularly on mobile where navigation bars and cookie banners may consume a larger proportion of the viewport.
6. Test with JAWS and Chrome. Open JAWS (Job Access With Speech) and use Chrome. Tab through all interactive elements and monitor for any moment where the JAWS cursor moves to an element that is visually hidden beneath a fixed layer. JAWS is widely used in enterprise and government environments, making this combination particularly important for testing public-sector and corporate websites.
7. Test after user interactions that change layout. Dismiss cookie banners, open and close navigation menus, trigger notification toasts, and open chat widgets. After each state change, perform a fresh Tab traversal to ensure that the new layout does not introduce new instances of focus being obscured. Dynamic content is a common source of 2.4.11 failures that only appear after user interaction.
8. Test at multiple scroll positions. Scroll to the middle or bottom of a long page, then Tab through elements in that region. Fixed headers may not obscure elements near the top of the page but can cover elements that appear at the viewport's top edge as the user scrolls down. Confirm that no combination of scroll position and focused element results in complete visual concealment.

How to Fix

Sticky Header Overlapping Focused Links — Incorrect

<!-- Sticky header with no scroll offset accommodation -->
<header style='position: fixed; top: 0; left: 0; width: 100%; height: 60px; z-index: 1000; background: white;'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- No scroll-margin-top set; focused link at top of main scrolls under the header -->
  <a href='/section-one'>Go to Section One</a>
  <a href='/section-two'>Go to Section Two</a>
</main>

Sticky Header Overlapping Focused Links — Correct

<!-- Fixed header with scroll-margin-top applied to all focusable elements -->
<header class='site-header'>
  <nav>
    <a href='/'>Home</a>
    <a href='/about'>About</a>
  </nav>
</header>

<main>
  <!-- scroll-margin-top ensures the browser scrolls the element into view
       with enough clearance so the fixed header does not cover it -->
  <a href='/section-one' class='content-link'>Go to Section One</a>
  <a href='/section-two' class='content-link'>Go to Section Two</a>
</main>

<!-- In your stylesheet: -->
<!-- .site-header { position: fixed; top: 0; height: 60px; z-index: 1000; } -->
<!-- * { scroll-margin-top: 70px; } -->
<!-- The 70px (header height + 10px buffer) keeps focused elements
     visible below the fixed header when the browser auto-scrolls. -->

Cookie Banner Covering Bottom-Focused Form Field — Incorrect

<!-- Cookie banner fixed at bottom with no accommodation for form fields above it -->
<div id='cookie-banner' class='cookie-overlay'>
  <p>We use cookies. <button>Accept</button></p>
</div>

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <!-- This checkbox renders in the viewport area covered by the cookie banner -->
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Cookie Banner Covering Bottom-Focused Form Field — Correct

<!-- Cookie banner pushes page content up instead of overlapping it -->
<div id='cookie-banner' class='cookie-banner-flow'>
  <p>We use cookies. <button id='accept-cookies'>Accept</button></p>
</div>

<!-- In your stylesheet: -->
<!-- .cookie-banner-flow { position: static; } instead of position: fixed -->
<!-- Alternatively, if fixed positioning is required for design reasons,
     add scroll-margin-bottom to all focusable elements equal to the
     banner height, or apply padding-bottom to <body> equal to
     the banner height so content is never hidden beneath it. -->

<form>
  <label for='email'>Email Address</label>
  <input type='email' id='email' name='email'>

  <label for='confirm'>Confirm Subscription</label>
  <input type='checkbox' id='confirm' name='confirm'>

  <button type='submit'>Submit</button>
</form>

Third-Party Chat Widget Overlapping Focused Button — Incorrect

<!-- Third-party chat widget injected in bottom-right corner
     with a high z-index, obscuring the focused Submit button -->
<div id='chat-widget' class='chat-fixed'>
  <!-- Injected by third-party script, covers 120x120px in bottom-right -->
</div>

<section class='cta-section'>
  <!-- Button positioned in the bottom-right area of the layout;
       when focused, it is completely hidden beneath the chat widget -->
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

Third-Party Chat Widget Overlapping Focused Button — Correct

<!-- Approach 1: Reposition the chat widget to avoid overlapping focusable content -->
<div id='chat-widget' class='chat-fixed-adjusted'>
  <!-- Widget repositioned to bottom-left, away from the CTA button -->
</div>

<!-- Approach 2: Ensure the button has scroll-margin that keeps it
     clear of the widget when focused -->
<section class='cta-section'>
  <button type='button' class='cta-button'>Get a Free Quote</button>
</section>

<!-- Approach 3: Use JavaScript to detect focus events on elements
     near the widget's bounding box and temporarily collapse or
     move the widget so the focused element is visible. -->
<script>
  // Example: collapse widget when nearby element gains focus
  document.querySelectorAll('.cta-button').forEach(function(btn) {
    btn.addEventListener('focus', function() {
      var widget = document.getElementById('chat-widget');
      if (widget) widget.setAttribute('aria-hidden', 'false');
      // Additional logic to reposition or minimize widget
    });
  });
</script>

Common Mistakes

• Applying position: fixed to headers and footers without adding scroll-margin-top or scroll-margin-bottom to focusable elements. The browser's native focus scrolling does not account for fixed overlapping elements, so focused items scroll to the top or bottom of the viewport and end up hidden behind the fixed layer. A global CSS rule such as * { scroll-margin-top: [header-height]px; } solves this efficiently.
• Setting body { padding-top: 60px; } to offset a fixed header but forgetting to add equivalent scroll-margin-top for keyboard focus. The padding ensures content is not initially hidden, but when keyboard focus triggers browser auto-scrolling, the scroll target may still slip behind the header. Both approaches must be used together.
• Using z-index: 9999 on promotional banners or chat widgets without auditing which focusable elements fall within their footprint. A high z-index guarantees the overlay renders on top of everything, including focused buttons and links, making it the most common root cause of 2.4.11 failures.
• Dismissing cookie banners via JavaScript without removing them from the layout immediately. If the banner's DOM element remains with visibility: hidden or opacity: 0 but still occupies space or has a non-zero z-index, it can continue to obscure focused elements visually in certain browser rendering scenarios.
• Embedding third-party widgets (live chat, accessibility overlays, GDPR managers) without verifying their impact on keyboard focus visibility. Third-party scripts often inject fixed-position elements with very high z-index values. Teams must test these integrations explicitly as part of their accessibility QA process.
• Failing to test 2.4.11 after responsive breakpoint changes. A sticky navigation bar that is 60px tall on desktop may expand to 120px on tablet when a hamburger menu is open, suddenly obscuring a much larger area and creating new failures at breakpoints that passed on desktop.
• Applying scroll-margin-top only to anchor targets (<h2>, <section>) but not to interactive elements like <input>, <button>, and <a>. Anchor scroll offset is commonly addressed, but keyboard focus auto-scroll to non-anchor elements is equally affected and must be covered by the same CSS rule.
• Assuming that because a focused element is announced by a screen reader, it is also visually visible. Screen readers access the accessibility tree, not the visual rendering. An element can be completely hidden behind a fixed overlay while still being announced correctly by NVDA or JAWS. These are two separate issues — 2.4.11 is specifically about visual focus visibility for sighted keyboard users.
• Neglecting to test focus obscurement after single-page application (SPA) route changes. In React, Vue, or Angular apps, route transitions often re-render fixed headers with updated state, and focus management during navigation can place focus on elements that are immediately obscured by a re-mounted sticky header before the user sees the new page.
• Relying solely on automated testing tools and concluding that no 2.4.11 issues exist because no automated rule flagged the page. Since axe-core does not have an automated rule for this criterion, a clean automated report does not mean the page passes. Manual keyboard traversal across all viewport sizes and page states is mandatory.

Relation to Turkey's Accessibility Regulations

WCAG 2.4.11 Focus Not Obscured (Minimum) is directly relevant to Turkey's emerging legal accessibility framework. Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory digital accessibility requirements that align with WCAG 2.2. This circular represents a significant expansion of Turkey's commitment to digital inclusion and imposes enforceable obligations on a wide range of entities operating in the Turkish digital market.

The circular covers a broad scope of organizations, including public institutions and government agencies, e-commerce platforms, banks and financial service providers, hospitals and healthcare organizations, telecommunications companies with more than 200,000 subscribers, travel agencies, private transportation companies, and private schools authorized by the Ministry of National Education (MoNE). All of these entities are expected to ensure their digital interfaces — websites, mobile applications, and web-based tools — conform to Level AA of WCAG 2.2.

Because WCAG 2.4.11 is a Level AA criterion in WCAG 2.2, compliance with this rule is not optional for covered entities. Organizations seeking to obtain or maintain the official Erişilebilirlik Logosu (Accessibility Logo), issued by the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı), must meet Level AA conformance. The Accessibility Logo serves as a public signal of digital inclusion commitment and is increasingly expected by Turkish consumers and government procurement bodies.

In practical terms, this means that Turkish public institution websites with sticky navigation headers, e-commerce sites with persistent promotional banners, banking portals with floating help widgets, and healthcare appointment systems with cookie consent overlays must all be tested and remediated for focus obscurement under 2.4.11. Failures in this criterion are particularly likely in complex, marketing-heavy interfaces — exactly the type of sites operated by the large commercial entities covered by the circular.

Organizations operating under the circular should incorporate 2.4.11 testing into their regular accessibility audit cycles. Given that this criterion requires manual testing, reliance on automated scanning alone will not satisfy due diligence obligations. Turkish entities pursuing full compliance are advised to conduct manual keyboard traversal testing across all viewport sizes and dynamic page states as part of their conformance documentation, and to address any identified focus obscurement issues as part of their remediation roadmap before accessibility logo application or renewal.