WCAG 2.4.7: Synlig fokus

Vad den här regeln innebär

WCAG 2.4.7 Focus Visible kräver att varje interaktivt element på en webbsida — länkar, knappar, formulärfält, anpassade widgets och alla andra komponenter som kan användas med tangentbord — visar en synlig fokusindikator när det får tangentbordsfokus. Med enklare ord: när en användare trycker på Tab-tangenten för att röra sig genom en sida måste de kunna se exakt vilket element som för närvarande är aktivt.

Kriteriet föreskriver inte någon specifik visuell stil för fokusindikatorn. Det kräver bara att någon synlig förändring sker. Det sagt kan en knappt märkbar indikator — till exempel en en-pixels prickad kontur som smälter in i bakgrunden — tekniskt sett klara 2.4.7 men ändå inte uppfylla det mer krävande WCAG 2.4.11 (Focus Appearance) som infördes i WCAG 2.2. Enligt 2.4.7 ensamt är vilken som helst urskiljbar visuell förändring tillräcklig.

Vad som räknas som godkänt: En fokusindikator är godkänd om en seende användare som tabbar genom sidan kan identifiera vilket element som har fokus utan att behöva förlita sig på skärmläsarutrop eller andra icke-visuella signaler. Vanliga godtagbara implementationer inkluderar webbläsarens standardkonturer, anpassade CSS-regler med outline eller box-shadow, ändrad understrykning eller ändrad bakgrundsfärg som tillämpas på :focus eller :focus-visible.

Vad som räknas som underkänt: Ett fel uppstår när en utvecklare tar bort webbläsarens standardfokusring — vanligtvis via outline: none eller outline: 0 i CSS — och inte ersätter den med en likvärdig anpassad indikator. Fel uppstår också när en anpassad komponent (byggd med <div>- eller <span>-element) görs tangentbordsfokuserbar via tabindex men inte får någon synlig stilförändring vid fokus.

Officiella undantag: WCAG noterar att kriteriet endast gäller tangentbordsopererbara gränssnitt. Komponenter som är enbart dekorativa eller uttryckligen uteslutna från tabb-ordningen (via tabindex='-1') behöver inte visa en fokusindikator, eftersom de inte kan få fokus genom normal tangentbordsnavigering.

Varför det är viktigt

Synlig fokus är grundläggande för tangentbordsåtkomlighet, och tangentbordsåtkomlighet är porten till tillgång för en bred grupp personer med funktionsnedsättning. Ungefär 26% av vuxna i USA lever med någon form av funktionsnedsättning enligt CDC, och många av dessa personer förlitar sig på tangentbord eller hjälpmedel som emulerar tangentbord i stället för pekdon.

Användare med motoriska funktionsnedsättningar — inklusive personer med tillstånd som ALS, cerebral pares, belastningsskador eller Parkinsons sjukdom — förlitar sig ofta på tangentbord, switch-enheter, sug-och-blås-kontroller eller ögonstyrningsprogram. Alla dessa inmatningsmetoder är beroende av webbläsarens fokusmodell för tangentbord. Om fokusindikatorn är osynlig kan dessa användare inte avgöra var de befinner sig på sidan, de kan inte aktivera rätt kontroll och kan bli helt utestängda från kritiska uppgifter som att skicka in ett formulär, slutföra ett köp eller navigera i en meny.

Användare med nedsatt syn som inte använder skärmläsare men kan förstora skärmen är också beroende av synlig fokus. När de zoomar in på en del av sidan talar den synliga fokusringen om vilket element som är aktivt och vägleder deras interaktion.

Kognitiva funktionsnedsättningar och uppmärksamhetsrelaterade svårigheter gynnas också av tydliga fokusindikatorer. Användare med ADHD eller minnessvårigheter tappar ofta bort sin position på en komplex sida; en framträdande fokusindikator ger en pålitlig visuell förankring.

Ett konkret scenario från verkligheten: föreställ dig en användare med multipel skleros som surfar på en e-handelssajt enbart med tangentbord eftersom precisionen med mus har blivit svår. Hen tabbar genom produktsidan för att nå knappen ”Add to Cart”. Om utvecklaren har undertryckt fokusringen ser användaren ingen indikation på var fokus är. Hen trycker på Enter och antingen händer ingenting (fokus hamnade på ett icke-interaktivt element) eller så triggas fel åtgärd. Resultatet är frustration, avbrutna uppgifter och förlorade intäkter för företaget — allt förebyggbart med en enda CSS-regel.

Utöver funktionsnedsättning gynnar fokusindikatorer alla användare i situationer där det är opraktiskt att använda mus: avancerade användare som navigerar med tangentbordskommandon, laptopanvändare utan extern mus och användare som fyller i långa formulär. Synlig fokus förbättrar också SEO indirekt genom att uppmuntra semantisk HTML och korrekt tabb-ordning, vilket sökmotorers crawlers belönar.

Relaterade Axe-core-regler

WCAG 2.4.7 kräver manuell testning eftersom automatiska verktyg inte pålitligt kan avgöra om en fokusindikator är synlig. Axe-core och liknande motorer kan upptäcka att en CSS-regel som outline: none finns, men de kan inte bedöma det renderade visuella resultatet i alla teman, högkontrastlägen och webbläsarmotorer. Följande förklarar testlandskapet:

• Manuell testning krävs — undertryckande av focus-visible: Axe-core levererar inte en dedikerad regel som definitivt flaggar 2.4.7-fel, eftersom det skulle kräva att sidan renderas, att man tabbar genom varje element och utför pixelnivå-kontrastanalys på fokusindikatorn — en uppgift som ligger bortom statisk eller DOM-nivå-analys. I stället måste testare manuellt tabba genom sidan och visuellt bekräfta att varje interaktivt element visar en fokusförändring.
• Delvis signal från css-orientation-lock och stilkontroller: Vissa axe-core-konfigurationer flaggar förekomsten av outline: 0 eller outline: none i stilmallar som en rekommendation om bästa praxis, men detta är en tumregel, inte en definitiv kontroll av överträdelse, eftersom regeln kan åsidosättas av en giltig anpassad fokusstil någon annanstans i kaskaden.
• Varför automatisering inte räcker: En fokusindikator kan vara dold endast i vissa tillstånd (t.ex. när en modal är öppen), endast för vissa elementtyper eller endast i vissa färgteman. Dessa villkorade fel kräver att en mänsklig testare navigerar till varje interaktivt element i den faktiskt renderade miljön och bekräftar synligheten. Verktyg som axe DevTools Pro kan hjälpa genom att markera element som har outline: none tillämpat, men den slutliga godkänd/underkänd-bedömningen måste göras av en människa.

Hur man testar

1. Automatisk förskanning: Kör axe DevTools (webbläsartillägg eller CLI) eller Google Lighthouse på sidan. Leta efter varningar om bästa praxis eller experimentella varningar relaterade till fokusstilar. Även om dessa inte definitivt bekräftar ett 2.4.7-fel lyfter de fram element som är värda att granska. I Lighthouse, kontrollera kategorin ”Accessibility” för fokusrelaterade fynd. Exportera rapporten och notera alla flaggade interaktiva element.
2. Manuellt tabbtest med tangentbord: Koppla bort eller flytta bort musen. Tryck upprepade gånger på Tab från toppen av sidan och navigera genom varje interaktivt element — länkar, knappar, fält, dropdowns, modaler, flikar, dragspel och datumväljare. Vid varje stopp, bekräfta att det fokuserade elementet visuellt går att skilja från sina ofokuserade grannar. Notera alla element där fokus inte ger någon synlig förändring.
3. Omvänt tabbtest: Använd Shift+Tab för att navigera bakåt genom sidan och upprepa den visuella kontrollen. Vissa implementationer bryter fokus-synlighet endast i en riktning på grund av problem med CSS-specificitet.
4. NVDA + Firefox-test: Öppna Firefox med NVDA igång. Använd Browse Mode (piltangenterna) och växla sedan till Forms Mode (Enter) för att interagera med formulärkontroller. Bekräfta att varje element som NVDA meddelar som fokuserat också visar en synlig indikator på skärmen — användbart för att upptäcka skillnader mellan hjälpmedelsfokus och webbläsarfokus.
5. VoiceOver + Safari-test (macOS/iOS): Aktivera VoiceOver och använd Tab eller VO+Högerpil för att röra dig genom interaktiva element. Verifiera visuellt att fokusringen på skärmen stämmer med vad VoiceOver meddelar.
6. JAWS + Chrome-test: Använd JAWS i läget med virtuell markör och sedan i applikationsläge. Tabba genom interaktiva kontroller och bekräfta att den synliga fokusindikatorn visas på varje fokuserat element.
7. Test i högkontrastläge: Aktivera Windows High Contrast Mode (eller macOS Increase Contrast) och upprepa tabbtestet. Vissa fokusindikatorer är beroende av färger som försvinner i högkontrastteman; indikatorn måste förbli synlig i dessa lägen.
8. CSS-inspektion: Öppna webbläsarens DevTools, välj ett interaktivt element, ge det fokus genom att trycka på Tab tills det är aktivt och inspektera de beräknade stilarna. Verifiera att ingen regel sätter outline: none eller outline: 0 utan en kompenserande fokusstil. Kontrollera också :focus-visible kontra :focus för att säkerställa att tangentbordsutlöst fokus täcks.

Hur man åtgärdar

Globalt borttagande av outline utan ersättning — Felaktigt

<!-- CSS-resets som tar bort alla fokusindikatorer globalt -->
<style>
  * {
    outline: none; /* Tar bort fokusring från alla element */
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>

Globalt borttagande av outline utan ersättning — Korrekt

<!-- Ta bort den globala outline: none-resetten.
     Ge en anpassad fokusstil som är visuellt tydlig. -->
<style>
  /* Respektera användare som föredrar minskad rörelse */
  :focus-visible {
    outline: 3px solid #005fcc;
    outline-offset: 2px;
  }
</style>

<a href='/products'>View Products</a>
<button type='submit'>Buy Now</button>
<!-- Nu visar båda elementen en högkontrast blå kontur när de får fokus via tangentbord -->

Anpassad div-baserad knapp utan fokusstil — Felaktigt

<!-- En div som är stylad som en knapp, gjord fokuserbar, men saknar :focus-CSS -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  /* Ingen :focus- eller :focus-visible-regel definierad */
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>

Anpassad div-baserad knapp utan fokusstil — Korrekt

<!-- Lägg till :focus-visible på den anpassade komponenten så att
     tangentbordsanvändare ser en tydlig indikator när elementet har fokus -->
<style>
  .fake-btn {
    display: inline-block;
    padding: 10px 20px;
    background: #e00;
    color: #fff;
    cursor: pointer;
  }
  .fake-btn:focus-visible {
    outline: 3px solid #ffcc00;
    outline-offset: 3px;
  }
</style>

<div class='fake-btn' tabindex='0' role='button'
     onclick='addToCart()' onkeydown='handleKey(event)'>
  Add to Cart
</div>
<!-- Den gula konturen visas bara vid tangentbordsfokus, inte vid musklick -->

Fokusring dold inuti en modal overlay — Felaktigt

<!-- Modal använder overflow:hidden och en stacking context som klipper
     standardkonturen, vilket gör den osynlig -->
<style>
  .modal-body {
    overflow: hidden; /* Klipper konturer som sträcker sig utanför elementet */
    border-radius: 8px;
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Fokusring dold inuti en modal overlay — Korrekt

<!-- Använd box-shadow i stället för outline så att den renderas
     inuti stacking context och aldrig klipps -->
<style>
  .modal-body {
    overflow: hidden;
    border-radius: 8px;
  }
  .modal-body button:focus-visible {
    /* box-shadow klipps inte av overflow:hidden --
       den stannar inom elementets egen box -->
    box-shadow: 0 0 0 3px #005fcc;
    outline: none; /* Ta bort standarden för att undvika dubbel ring */
  }
</style>

<div class='modal-body'>
  <button>Confirm Order</button>
  <button>Cancel</button>
</div>

Vanliga misstag

• Att lägga till outline: none i en grundläggande CSS-reset utan att granska vilka element den påverkar. Många populära resets (t.ex. äldre versioner av normalize.css eller Bootstrap-utilities) undertrycker fokusringar globalt. Följ alltid upp med en uttrycklig :focus-visible-regel som återställer synligheten för tangentbordsanvändare.
• Att enbart förlita sig på :focus när :focus-visible är mer lämpligt — eller tvärtom. Att bara använda :focus gör att indikatorn också visas vid musklick, vilket kan se märkligt ut. Att bara använda :focus-visible utan en :focus-fallback kan lämna äldre webbläsare utan någon indikator. Testa i alla målwebbläsare.
• Att tillämpa outline: none i en temauppsättning för ett komponentbibliotek utan att förstå kaskaden. En enda override i en temafil kan tyst radera fokusindikatorer för varje komponent som ärver från den, inklusive tredjepartswidgets.
• Att använda en fokusfärg som har otillräcklig kontrast mot elementet eller sidans bakgrund. En ljusgrå kontur på en vit bakgrund lägger tekniskt sett till en kontur men kan vara omöjlig att uppfatta. Även om 2.4.7 inte föreskriver ett specifikt kontrastförhållande gör 2.4.11 det — och fokusindikatorer med låg kontrast är en vanlig källa till granskningsfel även när utvecklare tror att de har följt kraven.
• Att sätta overflow: hidden eller clip-path på en container, vilket klipper webbläsarens standardkontur. Lösningen är att byta till fokusindikatorer baserade på box-shadow, som renderas inom elementets egen box och inte klipps av överordnade overflow-regler.
• Att glömma fokusindikatorer på interaktiva element inuti SVG- eller Canvas-komponenter. Anpassade diagramverktygstips, SVG-baserade ikonknappar och canvas-baserade ritverktyg har ofta ingen inbyggd fokusstil. Dessa kräver uttryckliga ARIA-roller, tabindex och :focus-visible-CSS eller JavaScript-styrd visuell återkoppling.
• Att ta bort fokus-synlighet endast i produktions-CSS (t.ex. via en post-processor eller ett byggsteg) samtidigt som den lämnas synlig i utvecklingsmiljön. Detta gör att utvecklingsteamet klarar sin lokala QA samtidigt som de levererar bristande tillgänglighet till slutanvändare.
• Att bara tillämpa en fokusindikator på <a>-elementet men inte på role='link'-span-element som används för SPA-navigationslänkar. Varje tangentbordsfokuserbart element — oavsett dess inbyggda tagg — behöver ett synligt fokusläge.
• Att dölja fokusringar endast i vissa viewport-bredder via media queries, i tron att mobila användare alltid rör vid skärmen. Surfplatteanvändare med Bluetooth-tangentbord och användare i liggande läge som förlitar sig på tangentbordsinmatning lämnas utan någon fokusindikator.
• Att använda JavaScript för att anropa .blur() omedelbart efter programmatisk fokus för att förhindra att fokusringen visas. Detta är ett allvarligt fel som helt tar bort fokus-synlighet och får aldrig användas som en designgenväg.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Official Gazette 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 kräver överensstämmelse med WCAG 2.2 på nivå AA för berörda organisationer, vilket gör WCAG 2.4.7 Focus Visible till ett direkt verkställbart krav snarare än enbart en rekommendation om bästa praxis.

De aktörer som omfattas av cirkuläret inkluderar offentliga institutioner och myndigheter, 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 godkänts av Ministry of National Education (MoNE). För alla dessa organisationer är brist på synliga fokusindikatorer i deras digitala gränssnitt en fråga om regulatorisk bristande efterlevnad, inte bara en brist i användbarhet.

Erişilebilirlik Logosu (tillgänglighetslogotypen), utfärdad av Ministry of Family and Social Services, fungerar som den officiella certifieringsmärkningen som berörda aktörer kan visa för att demonstrera överensstämmelse. För att erhålla tillgänglighetslogotypen krävs att man klarar en formell granskning enligt WCAG 2.2 nivå AA. WCAG 2.4.7 är ett av AA-kriterierna som revisorer kommer att utvärdera, vanligtvis genom manuell tangentbordstestning enligt beskrivningen i testavsnittet ovan. En organisation vars webbplats undertrycker fokusringar eller inte implementerar synlig fokus på anpassade komponenter kommer inte att klara den granskning som krävs för logotypen.

För turkiska e-handelsplattformar i synnerhet har fokus-synlighet direkta kommersiella konsekvenser: tillgängliga webbplatser når en bredare användarbas, inklusive kunder med motoriska funktionsnedsättningar som handlar uteslutande via tangentbord eller switch-access, och efterlevnad av Presidential Circular 2025/10 skyddar organisationer från administrativa åtgärder. Att bygga in focus-visible-mönster i komponentbiblioteket från början — i stället för att eftermontera dem efter en granskning — är det mest kostnadseffektiva sättet att behålla Erişilebilirlik Logosu och uppfylla Turkiets tillgänglighetskrav.