WCAG 3.2.1: Vid fokus

Vad den här regeln innebär

WCAG:s framgångskriterium 3.2.1 Vid fokus (Nivå A) säger: ”Om någon komponent får fokus initierar den inte en förändring av sammanhanget.” Med enklare ord: själva handlingen att flytta fokus till ett interaktivt element – genom att trycka på Tabb, Skift+Tabb, piltangenter eller någon annan tangentbordsmetod – får inte i sig orsaka att något dramatiskt och oväntat händer på sidan.

En förändring av sammanhang definieras av WCAG som en större förändring av sidans innehåll som, om den sker utan att användaren är medveten om det, kan göra användaren desorienterad. Specifikationen identifierar fyra konkreta typer av sammanhangsförändring: förändringar av användaragenten (till exempel att öppna ett nytt webbläsarfönster eller en ny flik), förändringar av vyn (till exempel automatisk rullning till en avlägsen del av sidan), förändringar av fokus i sig (till exempel att automatiskt flytta fokus någon annanstans) och förändringar av innehåll som avsevärt ändrar sidans innebörd (till exempel att skicka ett formulär eller ladda en helt annan vy).

Den avgörande skillnaden som kriteriet gör är mellan att ta emot fokus och att aktivera en kontroll. Att tabba till en knapp och därigenom få den att skicka ett formulär är ett brott. Men att trycka på Enter eller Mellanslag medan knappen har fokus – en avsiktlig, medveten aktivering – är helt acceptabelt och till och med förväntat. Användarens avsikt är det som skiljer en förutsägbar interaktion från en desorienterande.

Vanliga mönster som bryter mot detta kriterium inkluderar:

• En <select>-rullgardinsmeny som automatiskt navigerar till en ny URL så snart ett alternativ får fokus (inte när användaren bekräftar sitt val).
• En datumväljare som öppnar en modal dialog i samma ögonblick som något av dess inmatningsfält får fokus, utan någon användaraktivering.
• En karusell eller bildspel som automatiskt går vidare till nästa bild när dess navigationsprickar får fokus.
• En tooltip eller popover som, när den triggas av fokus, samtidigt flyttar tangentbordsfokus till sig själv utan förvarning och lämnar användaren strandsatt på en oväntad plats.
• Ett sökfält som omedelbart skickar och laddar om sidan när det får fokus.

Mönster som uttryckligen inte är överträdelser inkluderar: en tooltip eller beskrivningspanel som visas visuellt men inte flyttar fokus eller ändrar sidans primära innehåll; en fokusindikator (som en kontur eller ring) som visas runt det fokuserade elementet; eller ett element som expanderar för att visa ytterligare innehåll inline, så länge fokus förblir där användaren placerade det.

Det finns inga officiella undantag definierade i WCAG 3.2.1. Kriteriet gäller universellt för alla UI-komponenter på en sida. WCAG:s Understanding-dokument noterar dock att sammanhangsförändringar som triggas av en användares avsiktliga aktivering (klick, Enter, Mellanslag) faller utanför kriteriets räckvidd, som endast rör den passiva handlingen att ta emot fokus.

Varför det är viktigt

Kriteriet Vid fokus ligger under Princip 3 – Förståelig – eftersom förutsägbarhet är en grundläggande förutsättning för användbarhet. När en sida beter sig oväntat som svar på enbart fokus kan konsekvenserna variera från mild förvirring till fullständig förlust av åtkomst, beroende på användarens behov och hjälpmedel.

Endast tangentbordsanvändare (personer som inte kan använda mus på grund av motoriska funktionsnedsättningar, belastningsskador eller förlamning) är helt beroende av tangentbordsnavigering. När tabbning in i ett formulärfält triggar en sidomladdning kan de förlora all data de redan har matat in och hamna bort från sitt mål. Att återhämta sig från en sådan störning kan ta betydande tid och ansträngning – eller så ger de helt enkelt upp.

Skärmläsaranvändare (som ofta också är endast tangentbordsanvändare) möter ett ytterligare lager av desorientering. Skärmläsare meddelar vilket element som för närvarande har fokus för användaren. Om fokus oväntat hoppar till ett nytt element – till exempel en modal som öppnades automatiskt – meddelar skärmläsaren det nya sammanhanget utan att ge användaren någon referensram för vad som just hände eller varför. Detta är analogt med att fysiskt bli upplyft och flyttad till ett annat rum utan förvarning.

Användare med kognitiva funktionsnedsättningar, inklusive personer med ADHD, ångestsyndrom eller minnesnedsättningar, är beroende av förutsägbara gränssnitt för att bygga och upprätthålla en mental modell av en sida. Plötsliga, oförklarliga förändringar i sammanhanget krossar den modellen och skapar förvirring, ångest och fel. En studie av WebAIM Million-projektet visar konsekvent att komplexa interaktiva komponenter med oväntade beteenden är bland de främsta källorna till tillgänglighetsklagomål från användare med kognitiva funktionsnedsättningar.

Användare med nedsatt syn som använder skärmförstoringsprogram (som ZoomText eller Windows Förstoringsglas) ser bara en liten del av skärmen åt gången. Om fokus orsakar en automatisk rullning eller navigering kan det relevanta innehållet flyttas helt ut ur deras inzoomade vy, så att de stirrar på ett tomt eller orelaterat område av skärmen.

Fundera på ett konkret scenario i verkligheten: ett turkiskt banksystem för onlineöverföringar innehåller en rullgardinsmeny för att välja mottagarbank. Utvecklaren har implementerat en onchange-liknande händelse på <select>-elementet som inte triggas vid bekräftelse utan så snart något alternativ får fokus via piltangenterna. En skärmläsaranvändare som tabbar in i fältet och trycker på Nedåtpil för att utforska tillgängliga banker triggar omedelbart en formulärskickning eller sidomladdning. De slutför aldrig överföringen och kan inte avgöra vad som gick fel. Detta scenario är inte hypotetiskt – det var ett dokumenterat mönster i många tidiga single-page-applikationer.

Utöver tillgänglighet finns det konkreta användbarhets- och affärsfördelar. Formulär som inte kapar fokus har lägre avhoppsfrekvens. Sidor som beter sig förutsägbart får bättre resultat i användbarhetstester med alla målgrupper. Sökmotorers crawlers gynnas också av förutsägbara navigationsflöden, eftersom oväntade omdirigeringar som triggas av fokushändelser kan förvirra crawlers logik i vissa scenarier med dynamisk rendering.

Relaterade Axe-core-regler

WCAG 3.2.1 Vid fokus kräver manuell testning eftersom automatiska verktyg inte pålitligt kan avgöra användarens avsikt eller förutse alla möjliga sammanhangsförändringar. Axe-core och liknande automatiska skannrar kan tolka statisk HTML och ARIA-attribut, men de kan inte observera JavaScript-beteende i realtid som svar på fokushändelser – särskilt inte om detta beteende utgör en ”större” sammanhangsförändring enligt WCAG:s definition. Ett skript som flyttar fokus, skickar ett formulär eller navigerar till en URL vid focus-händelsen är osynligt för en statisk skanner om inte verktyget faktiskt simulerar fokusinteraktioner över varje interaktivt element och sedan analyserar vad som ändrats i DOM, vy och URL efteråt. Denna nivå av beteendesimulering är inte pålitligt möjlig i en automatiserad körning utan en oacceptabelt hög andel falska positiva.

• Manuell testning krävs – sammanhangsförändring vid fokus: Testare måste manuellt tabba igenom varje interaktivt element på sidan (länkar, knappar, inmatningsfält, select-element, anpassade widgets) och observera om fokus i sig – utan någon aktivering – triggar en sammanhangsförändring enligt WCAG:s definition. Detta inkluderar att se efter URL-förändringar, nya fönster eller flikar som öppnas, fokus som flyttas bort från det aktuella elementet, formulärskickningar och större innehållsersättningar. Automatiska verktyg flaggar JavaScript-händelselyssnare kopplade till fokusrelaterade händelser (focus, focusin, onfocus) som kandidater för manuell granskning, men kan inte avgöra om dessa hanterare orsakar en diskvalificerande sammanhangsförändring.

Hur man testar

1. Automatisk förskanning: Kör axe DevTools (webbläsartillägg eller CLI) eller Google Lighthouse mot sidan. Även om inget av verktygen definitivt kan flagga överträdelser av Vid fokus kan axe DevTools lyfta fram relaterade problem med fokus­hantering (som scrollable-region-focusable eller fokusfällor) som förtjänar närmare manuell granskning. Använd panelen ”Needs Review” i axe DevTools – poster som flaggas där är ofta relaterade till interaktiva komponentbeteenden som kräver mänsklig bedömning.
2. Identifiera alla interaktiva element: Innan tangentbordstestning, gör en lista över alla interaktiva komponenter: länkar, knappar, formulärfält, rullgardinsmenyer, kryssrutor, radioknappar, datumväljare, karuseller, dragspel, flikar, modaler och alla anpassade widgets som använder tabindex. Var särskilt uppmärksam på anpassade JavaScript-widgets som lyssnar på focus- eller focusin-händelser.
3. Test med endast tangentbord: Använd endast tangentbordet (ingen mus) och tryck på Tabb sekventiellt genom varje fokuserbart element på sidan. Efter varje Tabb-tryckning, innan du trycker på något annat, observera: Ändrades URL:en? Öppnades ett nytt fönster eller en ny flik? Flyttades fokus bort från elementet du just tabbade till? Skickades ett formulär? Förändrades sidans primära innehåll dramatiskt? Varje ”ja”-svar är en möjlig överträdelse.
4. Test av select-element: Fokusera en <select>-rullgardinsmeny. Använd Upp- och Nedåtpil för att gå igenom alternativen utan att trycka på Enter eller Mellanslag. Kontrollera att navigering genom alternativen inte triggar någon navigering, formulärskickning eller sammanhangsförändring. Detta är ett av de vanligaste mönstren som bryter mot kriteriet.
5. NVDA + Firefox: Aktivera NVDA (gratis, Windows). Öppna Firefox och gå till sidan. Tryck på Tabb genom alla interaktiva element. Lyssna på NVDA:s meddelanden – om NVDA börjar meddela en helt annan del av sidan eller ett nytt sid­sammanhang efter ett Tabb-tryck (utan att du tryckt på Enter eller Mellanslag) är detta en stark signal om en överträdelse.
6. JAWS + Chrome: Aktivera JAWS. Öppna Chrome. Använd Tabb för att navigera. JAWS meddelar varje fokuserat element. Övervaka oväntade meddelanden om nya dialoger, sidor eller fokuspositioner som du inte avsiktligt navigerade till.
7. VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver (Cmd+F5 på macOS). Navigera med Tabb (eller svep på iOS). Övervaka oväntade sammanhangsskiften. Testa på iOS även med switch access för att simulera användare med svåra motoriska funktionsnedsättningar som navigerar genom skanning.
8. Inspektion av händelselyssnare i webbläsarens DevTools: I Chrome DevTools, markera ett misstänkt interaktivt element, gå till panelen Elements och klicka på ”Event Listeners”. Leta efter focus- eller focusin-lyssnare. Om sådana finns, granska den kopplade JavaScript-koden för att avgöra om hanteraren triggar navigering, formulärskickning, fokusförflyttning eller andra sammanhangsförändrande åtgärder.

Hur man åtgärdar

Autosändande select-rullgardinsmeny – Felaktig

<!-- FAIL: Selecting an option via arrow key immediately navigates to a new URL -->
<label for='region'>Select Region</label>
<select id='region' onchange='window.location = this.value;'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>

Autosändande select-rullgardinsmeny – Korrekt

<!-- PASS: Navigation only occurs when the user explicitly activates the Go button -->
<label for='region'>Select Region</label>
<select id='region'>
  <option value='/istanbul'>Istanbul</option>
  <option value='/ankara'>Ankara</option>
  <option value='/izmir'>Izmir</option>
</select>
<button type='button' onclick='navigateToRegion()'>Go</button>

<script>
function navigateToRegion() {
  var select = document.getElementById('region');
  window.location = select.value; // Only fires on deliberate button activation
}
</script>

Modal som öppnas vid fokus på inmatningsfält – Felaktig

<!-- FAIL: Focusing the date input immediately opens a modal dialog and moves focus -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' onfocus='openDatePickerModal()' />

<script>
function openDatePickerModal() {
  var modal = document.getElementById('date-modal');
  modal.style.display = 'block';
  modal.querySelector('button').focus(); // Moves focus away without user intent
}
</script>

Modal som öppnas vid fokus på inmatningsfält – Korrekt

<!-- PASS: The date picker opens only when the user explicitly clicks or presses Enter/Space -->
<label for='departure'>Departure Date</label>
<input type='text' id='departure' readonly aria-haspopup='dialog'
       aria-label='Departure Date — press Enter to open date picker' />
<button type='button' id='open-picker'
        aria-controls='date-modal'
        onclick='openDatePickerModal()'>
  Choose Date
</button>

<script>
function openDatePickerModal() {
  // Only called on explicit activation (click or Enter/Space on the button)
  var modal = document.getElementById('date-modal');
  modal.removeAttribute('hidden');
  modal.querySelector('[data-initial-focus]').focus();
}
</script>

Karusell som auto-avancerar vid fokus – Felaktig

<!-- FAIL: Focusing a navigation dot advances the carousel slide, changing page content -->
<div class='carousel-dots'>
  <button class='dot' onfocus='showSlide(0)'>1</button>
  <button class='dot' onfocus='showSlide(1)'>2</button>
  <button class='dot' onfocus='showSlide(2)'>3</button>
</div>

Karusell som auto-avancerar vid fokus – Korrekt

<!-- PASS: The carousel only changes slides when the dot is explicitly activated (click/Enter) -->
<div class='carousel-dots' role='tablist' aria-label='Carousel navigation'>
  <button class='dot' role='tab' aria-selected='true'
          aria-controls='slide-0' onclick='showSlide(0)'>
    Slide 1
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-1' onclick='showSlide(1)'>
    Slide 2
  </button>
  <button class='dot' role='tab' aria-selected='false'
          aria-controls='slide-2' onclick='showSlide(2)'>
    Slide 3
  </button>
</div>
<!-- onclick only fires on deliberate activation, not on Tab focus -->

Vanliga misstag

• Att använda onfocus som ersättning för onclick på navigationselement: Utvecklare kopplar ibland onfocus-hanterare till navigationslänkar eller knappar för att ”förladda” en destination, men triggar av misstag en fullständig navigering i stället för bara en förhämtning. Använd alltid onclick eller onkeydown (med kontroll av Enter/Mellanslag) för alla åtgärder som ändrar sammanhang.
• Att binda onchange på <select>-element utan en separat skicka-åtgärd: I skrivbordswebbläsare triggas onchange på ett <select> när ett alternativ bekräftas, men i vissa äldre implementationer och vissa mobila webbläsare kan det triggas när piltangenterna flyttar sig genom alternativen. Koppla alltid select-baserad navigering till en uttrycklig skicka-knapp eller använd ett <form> med en <button type='submit'>.
• Att flytta fokus programmatiskt inuti en focus-händelsehanterare: Att anropa element.focus() inuti en annan komponents onfocus- eller focusin-hanterare skapar ett oväntat fokushopp. Detta är en direkt överträdelse – användaren tabbade till element A och fokus flyttades tyst till element B. Flytta alltid fokus endast som svar på avsiktliga användaråtgärder.
• Att öppna modala dialoger på fokus-händelser för någon triggerkomponent: En vanlig genväg är att koppla en modal-öppningshanterare till focus-händelsen för en triggerknapp eller ett inmatningsfält. Modaler får endast öppnas som svar på ett klick, Enter-tangent eller Mellanslag – aldrig enbart vid fokus.
• Att auto-spela media eller animationer som ändrar vy-sammanhanget vid fokus: En hero-banner som startar en helskärmsvideo eller en stor animation i samma ögonblick som dess uppspelningsknapp får fokus ändrar det visuella sammanhanget avsevärt. Koppla uppspelningsåtgärder till aktiveringshändelser, inte fokushändelser.
• Att trigga live region-uppdateringar som rullar sidan till nytt innehåll vid fokus: Vissa dynamiska widgets uppdaterar en live region och rullar sedan vyn till den regionen så snart ett inmatningsfält får fokus. Detta ändrar vy-sammanhanget och desorienterar användare av skärmförstoring. Koppla om möjligt bort live region-uppdateringar från fokushändelser.
• Att implementera anpassade fokusfällor som omedelbart fångar användare utan information: En anpassad komponent som fångar alla Tabb-tryckningar i samma ögonblick som den får fokus, utan att meddela användaren att de befinner sig i en fokusfälla, bryter mot både bokstav och anda i detta kriterium. Fokusfällor är endast lämpliga inuti fullt öppna modala dialoger, och användare måste informeras om hur de tar sig ut.
• Att använda CSS :focus för att trigga display: block på rullgardinsmenyer som innehåller fokuserbara barn, vilket orsakar kaskadartade oväntade fokusförflyttningar: Menyer som enbart styrs av CSS och fokus, och som visar fokuserbara objekt, kan orsaka förvirrande hopp när webbläsarens fokusordning sedan flyttar in i de nyss synliga objekten. Säkerställ att visade menyer är förväntade och tydligt kommunicerade via ARIA-attribut som aria-expanded.
• Att förlita sig på tredjepartswidgetbibliotek utan att granska deras fokusbeteende: Många UI-komponentbibliotek (datumväljare, rich text-redigerare, select2-liknande rullgardinsmenyer) har historiskt brutit mot 3.2.1 genom att öppna popup-fönster eller flytta fokus vid focus-händelser. Granska alltid tredjepartskomponenter manuellt innan driftsättning, oavsett bibliotekets tillgänglighetsanspråk.
• Att glömma att testa i single-page application (SPA)-routing-sammanhang: I React-, Vue- och Angular-SPA:er kan fokushändelser på navigationslänkar ibland trigga ruttbyten via routerns förhämtningslogik eller händelsebubbling, särskilt när fokushändelser inte stoppas korrekt från att bubbla. Testa SPA-navigationskomponenter uttryckligen för efterlevnad av 3.2.1.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet som uttryckligen hänvisar till WCAG 2.2 som teknisk standard. WCAG 3.2.1 Vid fokus är ett kriterium på nivå A, vilket innebär att det ligger på den grundläggande nivån för obligatorisk efterlevnad enligt cirkuläret. Det finns inga undantag för kriterier på nivå A – alla berörda aktörer måste uppfylla dem inom de angivna tidsramarna.

Offentliga institutioner måste uppnå full överensstämmelse inom ett år från cirkulärets publiceringsdatum. Privata aktörer inom tillämpningsområdet ges två år. De aktörer som omfattas av presidentcirkulär 2025/10 inkluderar ett brett spektrum av organisationer: alla offentliga institutioner och myndigheter, e-handelsplattformar och online-marknadsplatser, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekommunikationsföretag med 200 000 eller fler abonnenter, resebyråer och bokningsplattformar, privata transportföretag samt privata skolor och utbildningsinstitutioner som auktoriserats av Ministry of National Education (MoNE).

Relevansen av WCAG 3.2.1 Vid fokus för dessa aktörstyper är direkt och praktisk. Tänk på en e-handelsplattform där en rullgardinsmeny för produktkategorier auto-navigerar vid fokus – en kund med rörelsenedsättning som använder tangentbord kan inte bläddra bland produktkategorier och kommer att avbryta köpet. Ett banksystem för onlineöverföringar med fokus­triggade formulärskickningar kan orsaka oavsiktliga finansiella transaktioner eller upprepade misslyckade försök för skärmläsaranvändare. Ett sjukhus bokningssystem för tider där datumfält öppnar modaler vid fokus kan hindra patienter med funktionsnedsättningar från att boka vård självständigt.

Enligt cirkuläret utsätter bristande efterlevnad berörda aktörer för administrativa sanktioner och reputationsrisk. För aktörer som för närvarande genomgår digital transformation eller upphandlar nya webbsystem är det både mer kostnadseffektivt och bättre i linje med regleringens anda att bygga in efterlevnad av WCAG 3.2.1 i upphandlingskrav och utvecklar­riktlinjer redan nu – i stället för att göra efterhandsanpassningar efter ett klagomål. Organisationer som använder Accsible overlay SDK drar nytta av inbyggda verktyg för fokushantering som hjälper till att identifiera och åtgärda oväntade beteenden vid fokus som en del av ett bredare arbete för efterlevnad av WCAG 2.2 nivå A.