WCAG 2.4.11: Fokus inte skymd (minimum)

Vad den här regeln innebär

WCAG 2.4.11 Focus Not Obscured (Minimum) är ett kriterium på nivå AA som introducerades i WCAG 2.2 och som tar upp ett vanligt men allvarligt tillgänglighetsproblem: när ett fokuserat element är helt dolt bakom ett annat lager av innehåll på sidan. Kriteriet anger att när en användargränssnittskomponent får tangentbordsfokus får den komponenten inte vara helt dold av innehåll som skapats av utvecklaren.

Nyckelordet här är helt. WCAG 2.4.11 sätter miniminivån — det kräver bara att någon del av det fokuserade elementet förblir synlig. Om en klistrig navigationsrad överlappar den övre halvan av en fokuserad knapp men den nedre halvan fortfarande är synlig, klarar det tekniskt sett 2.4.11. Det strängare kompletterande kriteriet, WCAG 2.4.12 Focus Not Obscured (Enhanced) på nivå AAA, går längre genom att kräva att den fokuserade komponenten inte skymts av innehåll som skapats av utvecklaren överhuvudtaget — inte ens delvis.

De typer av innehåll som skapats av utvecklaren och som oftast orsakar detta problem inkluderar klistriga eller fixed-position-huvuden och -fötter, cookie-samtyckesbanners, chattstödswidgets, notifieringstoasts, modal-overlays, flytande åtgärdsknappar och nedersta navigationsrader i mobilanpassade layouter. Dessa element renderas med hjälp av CSS-egenskaper som position: fixed, position: sticky eller höga z-index-värden, vilket gör att de flyter ovanför det normala dokumentflödet och potentiellt täcker interaktiva element som får fokus.

Ett godkänt resultat innebär att när en tangentbordsanvändare tabbar genom interaktiva element är åtminstone en del av varje fokuserat elements visuella indikator synlig på skärmen hela tiden — även om ett klistrigt UI-element överlappar en del av det. Ett underkänt resultat uppstår när ett fokuserat element är helt dolt under ett lager som skapats av utvecklaren, vilket innebär att användaren inte har någon visuell ledtråd alls om var fokus befinner sig. Innehåll som renderas av webbläsaren, såsom webbläsarens egna verktygsfält, räknas inte som innehåll skapat av utvecklaren och ligger därför utanför detta kriteriums omfattning. På samma sätt undantas innehåll som användaren själv har flyttat (till exempel en panel som användaren kan dra).

Detta kriterium gäller alla interaktiva HTML-element som är tangentbordsfokuserbara som standard eller gjorts fokuserbara via tabindex, inklusive <a>, <button>, <input>, <select>, <textarea> och element med tabindex='0' eller positiva tabindex-värden.

Varför det är viktigt

Tangentbordsnavigering är grundläggande för tillgänglighet för flera grupper av användare. Personer med motoriska funktionsnedsättningar som inte kan använda mus är helt beroende av tangentbord, switch-enheter eller sip-and-puff-kontroller för att ta sig genom en webbsida. Personer som är blinda använder skärmläsare i kombination med tangentbord. Personer med nedsatt syn som använder tangentbordsnavigering utan skärmläsare är starkt beroende av den synliga fokusindikatorn för att förstå var de befinner sig. När det fokuserade elementet är dolt bakom ett klistrigt huvud eller en flytande widget är dessa användare i praktiken vilse — de måste trycka på Tab upprepade gånger, gissa sin position eller överge uppgiften helt.

Föreställ dig ett konkret scenario i verkligheten: en rullstolsanvändare med begränsad handrörlighet fyller i ett formulär för flygbokning på en turkisk flygbolagswebbplats. Hen använder Tab-tangenten för att gå igenom formulärfälten. Sidan har en klistrig cookie-samtyckesbanner längst ned i vyn. När användaren tabbar till den sista kryssrutan för bekräftelse renderas kryssrutan helt under cookie-bannern. Användaren har ingen visuell indikation på att kryssrutan har fokus. Hen kan inte avgöra om Tab-trycket fungerade, om hen behöver trycka på Tab igen eller om kryssrutan ens är obligatorisk. Denna förvirring kan leda till att formuläret överges, att inskickningar missas eller att upprepade tangenttryckningar orsakar oavsiktliga åtgärder.

Effekten sträcker sig bortom användare med funktionsnedsättningar. Avancerade användare som föredrar tangentbordsnavigering för snabbhet — utvecklare, personer som arbetar med dataregistrering och vana användare — drar också nytta av tydlig fokus-synlighet. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor världen över med någon form av funktionsnedsättning, och en betydande del av dessa är beroende av hjälpmedel eller tangentbordsnavigering. I Turkiet rapporterar TurkStat (Turkish Statistical Institute, TÜİK) att omkring 12,7% av befolkningen har någon form av funktionsnedsättning, vilket motsvarar ungefär 10 miljoner människor som direkt kan dra nytta av förbättrad fokus­hantering på digitala plattformar.

Ur ett affärsperspektiv ökar skymda fokusindikatorer avhoppsfrekvensen för uppgifter, minskar konverteringen och utsätter organisationer för juridiska och regulatoriska risker. Webbplatser som inte uppfyller detta kriterium kommer sannolikt också att misslyckas i tillgänglighetsgranskningar som krävs enligt turkisk lag, vilket äventyrar deras möjlighet att få eller behålla den officiella Erişilebilirlik Logosu (Accessibility Logo).

Relaterade Axe-core-regler

WCAG 2.4.11 klassificeras som kräver manuell testning i axe-core. Det finns ingen automatiserad axe-core-regel som direkt upptäcker denna överträdelse. Att förstå varför automatiserade verktyg inte pålitligt kan flagga detta problem hjälper team att bygga bättre manuella testprocesser.

• Manuell testning krävs — Fokus skymt av fixed-position-element: Automatiserade verktyg kan inte upptäcka om ett fokuserat element är visuellt skymt eftersom detta kräver att sidan renderas, att begränsningsrektanglarna för alla fixed- eller sticky-element beräknas vid körning och jämförs med begränsningsrektangeln för det aktuellt fokuserade elementet i fokusögonblicket. Vyfönstrets dimensioner, rullningspositionen och sidans dynamiska tillstånd (till exempel om en cookie-banner redan har avfärdats) påverkar alla resultatet. Ingen statisk analys eller DOM-inspektion kan pålitligt replikera denna visuella beräkning över alla möjliga tillstånd. Axe-core markerar detta kriterium som manuellt eftersom det kräver en mänsklig testare — eller ett avancerat visuellt regressionstestverktyg — som faktiskt tabbar genom sidan och observerar om fokuserade komponenter försvinner bakom överlappande lager.
• Manuell testning krävs — Dynamiskt overlay-innehåll: Många skymmande element injiceras dynamiskt via JavaScript efter den initiala sidladdningen — tredjeparts chattwidgets, GDPR-samtyckesbanners, kampanj-pop-ins och flytande navigationsmenyer. Automatiska skannrar som analyserar den initiala DOM-ögonblicksbilden kanske inte fångar dessa element alls, eller fångar dem i ett kollapsat eller dolt tillstånd som inte återspeglar användarens verkliga upplevelse. Manuell testning av en tangentbordsanvändare som interagerar med sidan i dess fullt renderade, dynamiska tillstånd är det enda pålitliga sättet att upptäcka dessa scenarier.

Hur man testar

1. Kör först en automatiserad tillgänglighetsskanning. Använd axe DevTools (webbläsartillägg), Lighthouse i Chrome DevTools eller en CI-integrerad axe-core-skanning för att identifiera eventuella automatiskt upptäckbara problem på sidan. Även om 2.4.11 i sig kräver manuell verifiering kan en automatiserad skanning lyfta fram relaterade problem som saknade fokusindikatorer (2.4.7) eller felaktig z-index-stapling som tyder på överlappande element. Notera alla element som flaggats som potentiellt problematiska innan du påbörjar manuell testning.
2. Identifiera alla fixed- och sticky-element på sidan. Öppna webbläsarens DevTools och inspektera sidans CSS. Sök efter element som använder position: fixed eller position: sticky. Kontrollera också element med höga z-index-värden (t.ex. 100 eller högre). Dokumentera vart och ett av dessa element — headers, footers, banners, chattwidgets, cookie-notiser — eftersom de är de mest sannolika kandidaterna för att skymma fokuserade komponenter. Ändra storlek på webbläsarfönstret för att simulera olika vyfönsterstorlekar, inklusive surfplatta och mobilbredd, eftersom sticky/fixed-element ofta beter sig olika över brytpunkter.
3. Genomför en fullständig tangentbords­tabbning genom sidan. Klicka utanför alla interaktiva element för att säkerställa att fokus startar från toppen av sidan, tryck sedan upprepade gånger på Tab för att gå igenom alla fokuserbara element. Titta noga på varje element när det får fokus. Var särskilt uppmärksam på element som visas nära över- eller nederkanten av vyfönstret, där fixed-huvuden eller -fötter med störst sannolikhet överlappar. Om den synliga fokusringen eller det markerade elementet vid något tillfälle försvinner helt bakom ett fixed-lager är det ett fel enligt 2.4.11. Använd Shift+Tab för att gå baklänges också, eftersom rullningsposition och layout kan skilja sig åt.
4. Testa med NVDA och Firefox. Öppna NVDA (gratis, öppen källkod-skärmläsare för Windows) och starta Firefox. Aktivera NVDAs läsläge (browse mode) och använd Tab för att gå genom sidan. Även om NVDA kommer att läsa upp varje fokuserat element, ska du också observera skärmen visuellt. Notera alla element där NVDA meddelar fokus men ingen visuell fokusindikator är synlig på grund av skymmande innehåll. Denna kombination används i stor utsträckning i Turkiet och globalt och representerar en viktig kombination av hjälpmedel.
5. Testa med VoiceOver och Safari på macOS/iOS. Aktivera VoiceOver (Command+F5 på Mac) och använd Tab eller VoiceOvers navigeringsgester för att gå genom fokuserbara element. På iOS använder du svepgester. Kontrollera att fokuserade element är visuellt närvarande och inte dolda under fixed UI-lager, särskilt på mobila enheter där navigationsrader och cookie-banners kan uppta en större del av vyfönstret.
6. Testa med JAWS och Chrome. Öppna JAWS (Job Access With Speech) och använd Chrome. Tabba genom alla interaktiva element och övervaka om JAWS-markören vid något tillfälle flyttas till ett element som är visuellt dolt under ett fixed-lager. JAWS används i stor utsträckning i företags- och myndighetsmiljöer, vilket gör denna kombination särskilt viktig för testning av offentliga och företagswebbplatser.
7. Testa efter användarinteraktioner som ändrar layouten. Avfärda cookie-banners, öppna och stäng navigationsmenyer, trigga notifieringstoasts och öppna chattwidgets. Efter varje tillståndsändring genomför du en ny tabbning med Tab för att säkerställa att den nya layouten inte introducerar nya fall där fokus skymts. Dynamiskt innehåll är en vanlig källa till 2.4.11-fel som bara uppträder efter användarinteraktion.
8. Testa vid flera rullningspositioner. Rulla till mitten eller botten av en lång sida och tabba sedan genom element i det området. Fixed-huvuden kanske inte skymmer element nära toppen av sidan men kan täcka element som visas vid vyfönstrets överkant när användaren rullar nedåt. Bekräfta att ingen kombination av rullningsposition och fokuserat element resulterar i fullständig visuell skymning.

Hur man åtgärdar

Klistrigt huvud som överlappar fokuserade länkar — Felaktigt

<!-- 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>

Klistrigt huvud som överlappar fokuserade länkar — Korrekt

<!-- 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 som täcker formulärfält längst ned med fokus — Felaktigt

<!-- 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 som täcker formulärfält längst ned med fokus — Korrekt

<!-- 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>

Tredjeparts chattwidget som överlappar fokuserad knapp — Felaktigt

<!-- 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>

Tredjeparts chattwidget som överlappar fokuserad knapp — Korrekt

<!-- 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>

Vanliga misstag

• Att använda position: fixed på headers och footers utan att lägga till scroll-margin-top eller scroll-margin-bottom på fokuserbara element. Webbläsarens inbyggda fokus­rullning tar inte hänsyn till fixed överlappande element, så fokuserade objekt rullas till över- eller nederkanten av vyfönstret och hamnar dolda bakom fixed-lagret. En global CSS-regel som * { scroll-margin-top: [header-height]px; } löser detta effektivt.
• Att sätta body { padding-top: 60px; } för att kompensera för ett fixed huvud men glömma att lägga till motsvarande scroll-margin-top för tangentbordsfokus. Padding säkerställer att innehåll inte initialt är dolt, men när tangentbordsfokus triggar webbläsarens automatiska rullning kan rullningsmålet ändå hamna bakom huvudet. Båda metoderna måste användas tillsammans.
• Att använda z-index: 9999 på kampanjbanners eller chattwidgets utan att granska vilka fokuserbara element som hamnar inom deras yta. Ett högt z-index garanterar att overlayn renderas ovanpå allt, inklusive fokuserade knappar och länkar, vilket gör det till den vanligaste grundorsaken till 2.4.11-fel.
• Att avfärda cookie-banners via JavaScript utan att omedelbart ta bort dem från layouten. Om banner-elementet i DOM:en finns kvar med visibility: hidden eller opacity: 0 men fortfarande upptar utrymme eller har ett icke-noll z-index kan det fortsätta att visuellt skymma fokuserade element i vissa webbläsar­renderingsscenarier.
• Att bädda in tredjepartswidgets (livechatt, tillgänglighets-overlays, GDPR-hanterare) utan att verifiera deras påverkan på tangentbordsfokus-synlighet. Tredjepartsskript injicerar ofta fixed-position-element med mycket höga z-index-värden. Team måste testa dessa integrationer uttryckligen som en del av sin tillgänglighets-QA-process.
• Att inte testa 2.4.11 efter ändringar i responsiva brytpunkter. En klistrig navigationsrad som är 60px hög på desktop kan expandera till 120px på surfplatta när en hamburgermeny är öppen, vilket plötsligt skymmer ett mycket större område och skapar nya fel vid brytpunkter som klarade testet på desktop.
• Att bara använda scroll-margin-top på ankarmål (<h2>, <section>) men inte på interaktiva element som <input>, <button> och <a>. Rullningskompensation för ankare hanteras ofta, men tangentbordsfokus automatisk rullning till icke-ankarelement påverkas lika mycket och måste täckas av samma CSS-regel.
• Att anta att eftersom ett fokuserat element läses upp av en skärmläsare är det också visuellt synligt. Skärmläsare använder tillgänglighetsträdet, inte den visuella renderingen. Ett element kan vara helt dolt bakom ett fixed overlay och ändå läsas upp korrekt av NVDA eller JAWS. Detta är två separata frågor — 2.4.11 handlar specifikt om visuell fokus-synlighet för seende tangentbordsanvändare.
• Att underlåta att testa fokus-skymning efter routningsändringar i single-page applications (SPA). I React-, Vue- eller Angular-appar renderas fixed-huvuden ofta om med uppdaterat tillstånd vid routningsövergångar, och fokus­hantering under navigering kan placera fokus på element som omedelbart skymts av ett återmonterat klistrigt huvud innan användaren ser den nya sidan.
• Att enbart förlita sig på automatiserade testverktyg och dra slutsatsen att inga 2.4.11-problem finns eftersom ingen automatiserad regel flaggade sidan. Eftersom axe-core inte har någon automatiserad regel för detta kriterium innebär en ren automatiserad rapport inte att sidan är godkänd. Manuell tangentbords­tabbning över alla vyfönsterstorlekar och sidtillstånd är obligatorisk.

Relation till Turkiets tillgänglighetsreglering

WCAG 2.4.11 Focus Not Obscured (Minimum) är direkt relevant för Turkiets framväxande juridiska ramverk för tillgänglighet. Turkiets presidentcirkulär 2025/10, publicerat i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska digitala tillgänglighetskrav som är i linje med WCAG 2.2. Detta cirkulär representerar en betydande utvidgning av Turkiets åtagande för digital inkludering och inför verkställbara skyldigheter för ett brett spektrum av aktörer på den turkiska digitala marknaden.

Cirkuläret omfattar ett brett spektrum av organisationer, inklusive offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och vårdorganisationer, telekommunikationsföretag med mer än 200 000 abonnenter, resebyråer, privata transportföretag och privatskolor som auktoriserats av Ministry of National Education (MoNE). Alla dessa aktörer förväntas säkerställa att deras digitala gränssnitt — webbplatser, mobilapplikationer och webbaserade verktyg — uppfyller nivå AA i WCAG 2.2.

Eftersom WCAG 2.4.11 är ett kriterium på nivå AA i WCAG 2.2 är efterlevnad av denna regel inte valfri för berörda aktörer. Organisationer som vill få eller behålla den officiella Erişilebilirlik Logosu (Accessibility Logo), utfärdad av Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı), måste uppnå överensstämmelse på nivå AA. Accessibility Logo fungerar som en offentlig signal om åtagande för digital inkludering och förväntas i allt högre grad av turkiska konsumenter och offentliga upphandlande organ.

I praktiken innebär detta att turkiska myndighetswebbplatser med klistriga navigationshuvuden, e-handelssajter med persistenta kampanjbanners, bankportaler med flytande hjälpwidgets och system för vårdbokning med cookie-samtyckesoverlays alla måste testas och åtgärdas för fokus-skymning enligt 2.4.11. Fel i detta kriterium är särskilt sannolika i komplexa, marknadsföringstunga gränssnitt — exakt den typ av webbplatser som drivs av de stora kommersiella aktörer som omfattas av cirkuläret.

Organisationer som verkar under cirkuläret bör inkludera testning av 2.4.11 i sina regelbundna tillgänglighetsgranskningscykler. Eftersom detta kriterium kräver manuell testning kommer enbart automatiserad skanning inte att uppfylla kraven på aktsamhet. Turkiska aktörer som strävar efter full efterlevnad rekommenderas att genomföra manuell tangentbords­tabbning över alla vyfönsterstorlekar och dynamiska sidtillstånd som en del av sin dokumentation för överensstämmelse, och att åtgärda alla identifierade problem med fokus-skymning som en del av sin åtgärdsplan innan ansökan om eller förnyelse av tillgänglighetslogotypen.