WCAG 2.4.12: Fokus inte skymd (utökad)

Vad den här regeln innebär

WCAG 2.4.12 — Fokus inte skymt (förbättrad) — är AAA-motsvarigheten till WCAG 2.4.11 (Fokus inte skymt, AA). Där AA-kriteriet tillåter att en fokuserad komponent är delvis synlig, kräver AAA-kriteriet att den fokuserade komponenten är helt synlig — ingen del av den får döljas av innehåll som skapats av författaren när den får tangentbordsfokus.

I praktiken innebär detta att när en användare tabbar till ett interaktivt element som en länk, knapp, formulärfält eller anpassad widget, måste hela elementets begränsningsyta vara oskymd av alla klistriga headers, fixerade footers, modal-overlays, cookie-banners, chatt-widgets eller annat innehåll som författaren har placerat på sidan. Regeln riktar sig specifikt mot författarskapat innehåll; W3C gör ett uttryckligt undantag för innehåll som användaren själv har flyttat för att skymma fokusindikatorn — till exempel ett flytande panel som användaren dragit framför det fokuserade elementet. I det fallet är inte författaren ansvarig.

För att klara 2.4.12 krävs att när ett element får fokus är hela den fokuserade komponenten synlig inom viewporten och inte täcks av något klistrigt, fixerat eller absolut positionerat element som sidans författare kontrollerar. Ett fel uppstår när någon del av det fokuserade elementets synliga gräns döljs bakom sådana overlays — även en enda pixel av fokusringen eller komponenten som klipps räknas som ett misslyckande på AAA-nivå.

Det är viktigt att förstå vad 2.4.12 inte omfattar. Det kräver inte en viss stil på fokusindikatorn (det behandlas av 2.4.11 och 2.4.7). Det kräver inte att fokusindikatorer har ett minimikontrastförhållande (täcks av 2.4.13). Det behandlar specifikt den rumsliga relationen mellan det fokuserade elementet och annat innehåll på sidan — lagerproblemet som oftast uppstår genom fixed och sticky positionering i CSS.

Berörda HTML-element inkluderar alla fokuserbara eller tabb-bara element: <a>, <button>, <input>, <select>, <textarea>, <details>, element med tabindex och anpassade interaktiva widgets byggda med ARIA-roller. Kriteriet gäller i alla webbläsarkontexter inklusive iframes, dialoger och routningsövergångar i single-page-applikationer.

Varför det är viktigt

Tangentbordsnavigering är en primär åtkomstmetod för en bred grupp användare. Personer med motoriska funktionsnedsättningar — inklusive de som lever med tillstånd som ALS, multipel skleros, cerebral pares eller belastningsskador — är helt beroende av tangentbordet eller switch-enheter i stället för en mus. Blinda och synsvaga användare som använder skärmläsare navigerar också med tangentbord, och även om deras hjälpmedel meddelar fokuspositionen hörbart, är seende tangentbordsanvändare helt beroende av den visuella fokusindikatorn för att orientera sig på sidan.

När det fokuserade elementet skymts, även delvis, möter dessa användare en frustrerande och potentiellt desorienterande upplevelse: sidan verkar inte erbjuda något fokuserat element alls, eller så måste användaren gissa var de befinner sig i dokumentet. På AA-nivå (2.4.11) tolereras delvis synlighet — åtminstone någon del av komponenten är synlig och ger en ledtråd. AAA-kriteriet eliminerar denna kompromiss helt och hållet, eftersom även en delvis dold fokusindikator kan missas av användare med nedsatt kontrastkänslighet, tunnelseende eller kognitiva tillstånd som gör det mer krävande att skanna en skärm.

Överväg ett konkret scenario: en turkisk e-handelswebbplats använder en fixerad navigationsrad som är 80px hög längst upp i viewporten och en klistrig cookie-samtyckesbanner som är 60px hög längst ned. En användare som trycker på Tab för att navigera genom produktkort kan upptäcka att det fokuserade kortets övre eller nedre kant — inklusive dess fokusring — glider under en av dessa fixerade ytor. Enligt WCAG 2.4.11 (AA) klarar sig webbplatsen om någon del av kortet fortfarande är synlig. Enligt 2.4.12 (AAA) måste hela kortet vara fullt synligt. Denna skillnad är betydelsefull: en delvis dold knappetikett kombinerad med en delvis dold fokusring kan göra det genuint omöjligt för en synsvag användare att avgöra vilket element som är aktivt eller vilken åtgärd det kommer att utföra.

Enligt Världshälsoorganisationen har cirka 2,2 miljarder människor globalt någon form av synnedsättning, och motoriska funktionsnedsättningar påverkar hundratals miljoner fler. Förbättringar av tangentbordsåtkomlighet gynnar inte bara dessa grupper utan också avancerade användare som föredrar tangentbordsnavigering för snabbhet, användare på enheter utan pekdon och användare i situationer där finmotoriken tillfälligt är nedsatt.

Utöver tillgänglighet för personer med funktionsnedsättning förbättrar fullt synligt fokus den allmänna användbarheten och minskar supportkostnader. När alla användare — inklusive de utan funktionsnedsättning — tydligt kan följa fokuspositionen förbättras formulärifyllnadsgraden och felminskningen. För webbplatser som riktar sig till den turkiska marknaden signalerar AAA-överensstämmelse ett moget tillgänglighetsprogram och bygger förtroende hos både användare och institutionella upphandlare.

Relaterade Axe-core-regler

WCAG 2.4.12 klassificeras som att den kräver manuell testning och är en del av tilläggen i WCAG 2.2. Det finns ingen fullt automatiserad axe-core-regel som pålitligt kan upptäcka denna överträdelse, och att förstå varför är viktigt för team som bygger sina testpipelines.

• Manuell inspektion — focus-not-obscured-enhanced (ingen automatiserad regel): Automatiserade tillgänglighetsskannrar som axe-core arbetar på den statiska DOM:en eller en ögonblicksbild av renderat tillstånd. Att upptäcka om ett fokuserat element är skymt kräver: (1) att simulera tangentbordsfokus på varje interaktivt element i tur och ordning, (2) att beräkna elementets begränsningsrektangel efter fokusinducerad scrollning, (3) att identifiera alla fixed- och sticky-positionerade element och deras begränsningsrektanglar och (4) att testa geometrisk överlappning. Även om partiell automatisering teoretiskt är möjlig gör den dynamiska naturen hos scrollbeteende, CSS-scroll-padding, mjuk scrollning och JavaScript-styrd fokus­hantering detta mycket opålitligt i praktiken. Ett fokuserat element som är perfekt synligt vid en viewportstorlek kan vara helt skymt vid en annan. axe-core markerar detta kriterium som att det kräver mänsklig bedömning och markerar fynd som ”needs review” i stället för automatiska överträdelser. Testare måste manuellt tabba genom varje interaktivt element och visuellt bekräfta full synlighet vid varje relevant viewportbredd.
• scrollable-region-focusable (axe-regel): Även om den inte är direkt kopplad till 2.4.12 flaggar denna axe-regel element inuti scrollbara regioner som är fokuserbara men kanske inte scrollar in i vy korrekt. Det är en relaterad signal som indikerar scrollhanteringsproblem som kan göra att fokus skymts av klistriga headers eller footers — det vanligaste felmönstret för 2.4.12.

Eftersom automatiserade verktyg inte pålitligt kan fånga överträdelser av 2.4.12 måste organisationer bygga in manuella tangentbordsgenomgångar i sin QA-process, helst vid flera viewportstorlekar och med alla persistenta UI-lager (navigationsrader, chatt-widgets, cookie-banners, GDPR-notiser) aktiva.

Hur man testar

1. Automatiserad grundskanning: Kör axe DevTools eller Lighthouse mot sidan för att identifiera relaterade problem som överträdelser av scrollable-region-focusable eller CSS-overflow-problem. Dessa fynd, även om de inte är direkta 2.4.12-överträdelser, indikerar områden på sidan som mest sannolikt orsakar fokus-skymmande problem. I axe DevTools, filtrera på WCAG 2.2-kriterier och granska alla ”needs review”-poster relaterade till fokus­synlighet.
2. Identifiera allt persistent överlagrat innehåll: Innan tangentbordstestning, kartlägg visuellt varje element med position: fixed eller position: sticky på sidan — vanligtvis navigationsrader, cookie-banners, chatt-widgets, flytande åtgärdsknappar och footer-verktygsfält. Notera deras höjder och positioner så att du vet vilka zoner i viewporten de upptar.
3. Genomgång med tangentbordsnavigering: Börja från toppen av sidan (eller efter att ha stängt en initial modal) och tryck upprepade gånger på Tab för att flytta fokus genom varje interaktivt element. Vid varje fokusstopp, verifiera att det hela fokuserade elementet — inklusive dess synliga fokusindikator (outline eller ring) — är helt inom det oskymda viewportområdet. Acceptera inte delvis synlighet. Om någon del av elementet eller dess fokusring försvinner bakom ett fixerat element, registrera detta som ett 2.4.12-fel.
4. Omvänd navigering: Upprepa genomgången med Shift+Tab för att navigera bakåt. Fixerade footers missas ofta i tester som bara går framåt men kan skymma element när man tabbar baklänges.
5. Skärmläsartestning med NVDA + Firefox: Öppna NVDA, starta Firefox och navigera med Tab. När NVDA meddelar fokus på ett element, bekräfta visuellt att elementet är helt synligt. NVDAs fokusläge scrollar inte automatiskt element så att de frigörs från fixerade lager, så överträdelser kan skilja sig från webbläsarens inbyggda beteende.
6. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver och använd Tab (eller svep på iOS) för att navigera. Safaris scrollhantering skiljer sig ibland från Chromiums, vilket potentiellt avslöjar skymda fokus­tillstånd som inte syns i Chrome.
7. Testning i responsiva viewports: Upprepa tangentbordsgenomgången vid vanliga brytpunkter — 320px, 768px, 1024px och 1440px breda. Klistriga element blir ofta högre eller ompositioneras vid olika brytpunkter, vilket ändrar vilka zoner som är i riskzonen.
8. Testa efter användarinteraktioner: Öppna dropdown-menyer, expandera accordions, trigga modaler och navigera till nya routes i single-page-applikationer. Efter varje tillståndsändring, återuppta Tab-navigering och verifiera på nytt full fokus­synlighet, eftersom dynamiskt innehåll ofta introducerar nya fixerade overlays.

Hur man åtgärdar

Klistrig header som skymmer fokuserade länkar — felaktigt

<!-- Fixed header with no scroll compensation -->
<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main>
  <!-- When Tab reaches this link near the top of main, the header covers it -->
  <a href='/products'>View all products</a>
</main>

Klistrig header som skymmer fokuserade länkar — korrekt

<!-- scroll-padding-top ensures focused elements scroll clear of the fixed header -->
<style>
  html {
    /* Match this value to the height of your fixed header */
    scroll-padding-top: 88px; /* 80px header + 8px breathing room */
  }
</style>

<header style='position:fixed; top:0; height:80px; background:#fff; width:100%;'>
  <nav>...</nav>
</header>

<main style='margin-top:80px;'>
  <!-- Focus now scrolls the element fully clear of the header -->
  <a href='/products'>View all products</a>
</main>

Cookie-banner som täcker interaktiva element längst ned i viewporten — felaktigt

<!-- Cookie banner fixed to the bottom, no scroll compensation -->
<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- These links at the bottom of the page get covered by the cookie banner -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

Cookie-banner som täcker interaktiva element längst ned i viewporten — korrekt

<!-- Add scroll-padding-bottom and body padding to compensate for the banner height -->
<style>
  html {
    scroll-padding-bottom: 80px; /* 72px banner + 8px breathing room */
  }
  body {
    padding-bottom: 80px; /* Prevent content from being permanently under the banner */
  }
</style>

<div id='cookie-banner' style='position:fixed; bottom:0; height:72px; width:100%; background:#222;'>
  <button>Accept All</button>
  <button>Manage Preferences</button>
</div>

<footer>
  <!-- Links now scroll fully into the unobscured viewport area -->
  <a href='/privacy'>Privacy Policy</a>
  <a href='/terms'>Terms of Service</a>
</footer>

JavaScript-fokushantering som inte tar hänsyn till fixerade lager — felaktigt

<!-- SPA route change: focus moved to heading but scrollIntoView ignores header -->
<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  heading.focus();
  // scrollIntoView with no offset — heading scrolls behind fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

JavaScript-fokushantering som inte tar hänsyn till fixerade lager — korrekt

<!-- Use scroll-margin-top on the target element, or manually offset scrollY -->
<style>
  .focus-target {
    /* scroll-margin-top offsets this element's scroll position from the top */
    scroll-margin-top: 96px;
  }
</style>

<script>
function navigateTo(section) {
  const heading = document.querySelector('#' + section + ' h2');
  heading.setAttribute('tabindex', '-1');
  // scroll-margin-top on the element handles the visual offset automatically
  heading.classList.add('focus-target');
  heading.focus();
  // scrollIntoView now respects scroll-margin-top, clearing the fixed header
  heading.scrollIntoView({ behavior: 'smooth', block: 'start' });
}
</script>

Vanliga misstag

• Att sätta scroll-padding-top på body i stället för html: CSS-egenskapen scroll-padding måste tillämpas på scrollbehållaren. För scrollning av hela sidan är scrollbehållaren html-elementet, inte body. Att tillämpa den på body har ingen effekt i de flesta webbläsare och är ett av de vanligaste implementationsfelen.
• Att hårdkoda ett fast pixelvärde för scroll-padding-top som inte matchar den faktiska headerhöjden vid alla brytpunkter: När headern kollapsar till en mindre höjd på mobil eller expanderar för att inkludera en sekundär navigationsrad på desktop blir den statiska offseten fel. Använd CSS-variabler som uppdateras via JavaScript eller använd calc() med relativa enheter för att hålla värdet i synk.
• Att glömma scroll-margin-top på mål för interna ankarlänkar: Även när global scroll-padding-top är korrekt för Tab-navigering kan ankarlänksmål som får programmatiskt fokus (t.ex. hoppa-till-innehåll-länkar, hash-navigering i SPAs) fortfarande hamna under headern om inte scroll-margin-top också sätts på dessa specifika element.
• Att stänga cookie-bannern utan att testa igen: Många team testar tangentbordsnavigering först efter att ha accepterat cookie-bannern. Eftersom bannern upptar nederdelen av viewporten kan fokusbara element som är förankrade längst ned skymmas endast medan bannern är aktiv. Testa alltid med alla persistenta UI-lager i fullt visat tillstånd.
• Att bara testa vid en viewportbredd: Klistriga element ändrar ofta höjd, blir synliga eller försvinner helt vid olika brytpunkter. Ett fel vid 375px kanske inte syns vid 1440px, och vice versa. Att testa vid endast en storlek missar en betydande andel av verkliga överträdelser.
• Att använda overflow: hidden på en föräldrakontainer för att klippa fokusindikatorer: När en kortkomponent eller kontainer har overflow: hidden klipps webbläsarens standardfokus-outline på barnelement vid kontainergränsen. Detta kan göra att fokus verkar vara helt synligt i DevTools elementinspektion samtidigt som det visuellt skärs av för användaren.
• Att anta att skärmläsare hanterar scroll automatiskt så att visuell testning är onödig: Även om skärmläsare meddelar det fokuserade elementet hörbart är seende tangentbordsanvändare — inklusive de som använder skärmförstoringsverktyg — helt beroende av visuell position. Ett visuellt skymt fokustillstånd är ett verkligt fel oavsett skärmläsarbeteende.
• Att inte testa modaldialoger och drawer-overlays: När en modal öppnas och fokus flyttas in i den kan bakgrunden eller själva modalens chrome skymma det första fokuserade elementet i dialogen. Detta är särskilt vanligt i drawer-paneler som animeras in från sidan eller botten.
• Att ignorera tredjepartswidgets som live-chattbubblor och interstitiella annonsbanners: Flytande chatt-widgets (t.ex. Intercom, Zendesk) och fixerade reklambanners som injiceras av tagghanterare är författarskapat innehåll och omfattas av detta kriterium. Team förbiser dem ofta eftersom de hanteras utanför huvudkodbasen.
• Att enbart förlita sig på automatiska tillgänglighetsskanningar och stänga ärendet: Eftersom 2.4.12 kräver manuell testning bekräftar inte en ren axe-core-skanning överensstämmelse. Att stänga tillgänglighetsärenden baserat enbart på automatiska resultat kommer konsekvent att missa detta kriterium.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer bindande krav på webb- och mobiltillgänglighet för ett brett spektrum av aktörer som är verksamma i Turkiet. Cirkuläret antar WCAG 2.1 nivå AA som sin grundläggande standard för överensstämmelse, vilket innebär att WCAG 2.4.12 — som ett WCAG 2.2 AAA-kriterium — inte är direkt föreskrivet enligt den nuvarande regleringen. Dess relation till Turkiets tillgänglighetsramverk är dock betydelsefull av flera skäl.

De aktörer som omfattas av presidentcirkulär 2025/10 inkluderar offentliga institutioner och statliga organ på alla nivåer, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och vårdorganisationer, telekommunikationsföretag med 200 000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor som har auktoriserats av utbildningsministeriet (MoNE). För alla dessa organisationer är det en rättslig skyldighet att uppnå WCAG 2.1 AA-efterlevnad, och cirkuläret förväntas genomdrivas genom revisionsmekanismer som administreras av relevanta tillsynsorgan.

Även om AAA-överensstämmelse inte krävs enligt cirkuläret har organisationer i reglerade sektorer starka praktiska skäl att sträva efter efterlevnad av WCAG 2.4.12. För det första utvecklas den turkiska regleringsmiljön: cirkuläret innebär en betydande skärpning av tillgänglighets­efterlevnad jämfört med tidigare vägledning, och framtida revideringar kan anta WCAG 2.2 eller höja överensstämmelsenivån. Organisationer som bygger AAA-praxis nu kommer att vara bättre positionerade för regulatoriska förändringar. För det andra gynnar offentliga upphandlingsprocesser och tillträde till EU-marknaden i allt högre grad leverantörer som kan visa upp förbättrade tillgänglighetsprogram, och dokumentation av AAA-överensstämmelse ger en konkurrensfördel.

För det tredje, och mest direkt relevant för WCAG 2.4.12, behandlar kriteriet ett felmönster som oproportionerligt drabbar användare av hjälpmedel i Turkiet — en population som uppskattas till flera miljoner människor när motoriska, visuella och kognitiva funktionsnedsättningar räknas tillsammans. Banker, sjukhus och e-förvaltningsportaler som i hög grad förlitar sig på fixerad navigationschrome och persistenta notifieringslager är just de webbplatser där fokus-skymmande fel är vanligast. Att investera i full efterlevnad av WCAG 2.4.12 visar ett genuint engagemang för att betjäna alla användare, ligger i linje med andemeningen i presidentcirkuläret även där ordalydelsen ännu inte kräver det, och minskar juridisk och reputationsmässig risk i takt med att den turkiska tillsynen mognar.

För organisationer som använder Accsible overlay SDK tillhandahåller plattformen verktyg för att granska tangentbordsfokusvägar och identifiera konflikter med sticky-positionering, vilket stödjer både de obligatoriska AA-kraven i presidentcirkulär 2025/10 och frivilliga AAA-förbättringar som WCAG 2.4.12.