WCAG 1.4.13: Innehåll vid hovring eller fokus

Vad den här regeln innebär

WCAG 1.4.13 behandlar ett vanligt interaktionsmönster på webben: innehåll som blir synligt när en användare hovrar med en pekare över ett element eller flyttar tangentbordsfokus till det. Detta inkluderar verktygstips (tooltips), undermenyer, anpassade rullgardinsledtrådar, datumväljare-popovers och alla andra överlägg som visas som svar på hover- eller fokus-händelser. Kriteriet gäller när sådant innehåll inte styrs inbyggt av webbläsaren (till exempel är det inbyggda verktygstipset från attributet title undantaget), och det fastställer tre kärnkrav som alla måste uppfyllas samtidigt.

Avfärdbart: Användaren måste kunna stänga det extra innehållet utan att flytta pekarfokus eller tangentbordsfokus. Den standardiserade mekanismen för detta är att trycka på Escape-tangenten. Detta förhindrar att överlägget skymmer annat sidinnehåll på ett sätt som användaren inte kan lösa — särskilt kritiskt för användare som har förstorat skärmen och inte bara kan kasta en blick någon annanstans.

Hoverbart: Om det extra innehållet visades för att användaren hovrade över ett utlösande element, måste användaren kunna flytta sin pekare över det nyss visade innehållet utan att det försvinner. Om ett verktygstips försvinner i samma ögonblick som markören lämnar det utlösande elementet kan användare inte läsa längre innehåll, kopiera text från det eller aktivera länkar eller kontroller i det.

Beständigt: Det extra innehållet måste förbli synligt tills hover- eller fokus-utlösaren tas bort, användaren stänger det (till exempel via Escape) eller informationen inte längre är giltig. Innehållet får inte försvinna med en timer eller efter en godtycklig fördröjning medan användarens pekare eller fokus fortfarande är på utlösaren eller själva överlägget.

För att bli godkänd måste alla tre villkoren vara uppfyllda. Ett fel uppstår om något enskilt villkor saknas — till exempel ett verktygstips som försvinner när pekaren flyttas från utlösaren mot verktygstipset (inte hoverbart), eller ett som stängs automatiskt efter tre sekunder (inte beständigt), eller ett som inte kan stängas utan att flytta fokus bort (inte avfärdbart). Det enda officiella undantaget som WCAG gör är när den visuella presentationen av det extra innehållet helt styrs av användaragenten — webbläsarens inbyggda verktygstips som enbart skapas av attributet title faller i denna kategori och är undantagna, även om de har sina egna tillgänglighetsbegränsningar.

Varför det är viktigt

Detta kriterium gynnar främst användare som har svårt att kontrollera vanliga mus- eller tangentbordsinteraktioner, användare som är beroende av skärmförstoring och användare som bearbetar information långsammare. Att förstå vilka som påverkas hjälper team att prioritera åtgärden på rätt sätt.

Användare med nedsatt syn använder ofta skärmförstoringsprogram som ZoomText eller operativsystemets inbyggda förstorare, vilket innebär att de bara ser en liten del av skärmen vid hög zoomnivå. När ett verktygstips visas kan det delvis ligga utanför skärmen, och användaren måste panorera mot det. Om verktygstipset försvinner i samma ögonblick som pekaren lämnar utlösaren kan användaren inte panorera för att läsa det. Enligt Världshälsoorganisationen lever cirka 2,2 miljarder människor globalt med någon form av synnedsättning, och en betydande del av dem som använder datorer är beroende av förstoring snarare än skärmläsare.

Användare med motoriska funktionsnedsättningar — inklusive personer med Parkinsons sjukdom, skakningar eller begränsad finmotorik — kan använda alternativa pekdon, huvudpekare eller ögonstyrningssystem. Precis pekarkontroll är svår för dessa användare, vilket innebär att det kan vara nästintill omöjligt att flytta från ett litet utlösande element till ett litet verktygstips utan att oavsiktligt lämna båda, om hover-ytan inte är förlåtande. Kravet på hoverbarhet adresserar detta direkt.

Användare med kognitiva funktionsnedsättningar kan läsa långsamt eller behöva läsa om innehåll. Ett verktygstips som stängs automatiskt efter några sekunder ger inte dessa användare tillräckligt med tid att ta till sig informationen, och ett verktygstips som inte kan stängas utan att flytta fokus kan fånga deras uppmärksamhet i ett förvirrande interaktionstillstånd.

Överväg ett konkret scenario: en banksajt visar detaljer om kontots räntesats i ett verktygstips som visas när användaren hovrar över en liten informationsikon. En användare med nedsatt syn som har zoomat till 400 % ser bara en del av sidan åt gången. De hovrar över ikonen, verktygstipset visas, och de börjar flytta pekaren mot verktygstipset för att läsa det finstilta — men verktygstipset försvinner omedelbart eftersom det bara är kopplat till hovringstillståndet på föräldraelementet. Användaren kan inte ta del av den obligatoriska informationen. Detta är inte bara en användbarhetsolägenhet; i reglerade branscher kan det utgöra ett juridiskt tillgänglighetshinder.

Utöver funktionsnedsättningsspecifik påverkan förbättrar korrekt implementering av detta kriterium också den allmänna användbarheten för alla användare på touch- och tangentbordshybridenheter, minskar supportärenden orsakade av ”försvinnande” UI-element och signalerar gränssnittskvalitet till både användare och granskare.

Relaterade Axe-core-regler

WCAG 1.4.13 kräver manuell testning. Automatiserade verktyg kan inte pålitligt upptäcka överträdelser eftersom kriteriet innefattar tidsbaserade och pekarrörelse-beteenden som statisk DOM-analys inte kan utvärdera. Ingen enskild axe-core-regel motsvarar direkt detta kriterium, men följande överväganden förklarar varför automatisering inte räcker och vad man ska leta efter vid manuell granskning.

• Manuell testning krävs — hover-beteende: Automatiska skannrar inspekterar DOM och CSSOM vid en given tidpunkt; de kan inte simulera att flytta en pekare från ett utlösande element mot ett nyss renderat verktygstips och observera om verktygstipset består. Ett verktyg skulle teoretiskt kunna upptäcka att en CSS-:hover-pseudoklass döljer ett barnelement när föräldern förlorar hover, men det kan inte skilja mellan avsiktlig stängning och ett misslyckande med kravet på hoverbarhet utan att simulera pekarvägar.
• Manuell testning krävs — Escape-avfärdande: Att upptäcka om tryck på Escape stänger ett överlägg kräver JavaScript-händelsesimulering som går utöver axe-cores nuvarande regeluppsättning. Axe kan flagga saknade ARIA-roller på popups eller saknade aria-expanded-attribut, men det kan inte verifiera att en keydown-lyssnare för Escape är kopplad till en stängningsfunktion och faktiskt döljer elementet.
• Manuell testning krävs — beständighet / auto-stängning: Ett verktygstips som döljer sig självt via ett setTimeout-anrop efter tre sekunder kommer att verka helt giltigt i en statisk skanning som tas inom det fönstret. Endast en testare som observerar överlägget över tid — eller granskar JavaScript-källan — kan identifiera en auto-stängningstimer som en överträdelse.
• Kompletterande axe-regler att köra tillsammans med manuella kontroller: Även om de inte testar 1.4.13 direkt kan körning av regler som aria-tooltip-name (säkerställa att verktygstips har tillgängliga namn), color-contrast (säkerställa att texten i verktygstipset är läsbar) och focus-visible (säkerställa att fokuserade utlösare är visuellt identifierbara) lyfta fram relaterade problem som förstärker effekten av 1.4.13-fel.

Hur man testar

1. Automatiserad grundskanning: Kör axe DevTools eller Lighthouse på sidan som innehåller hover-/fokus-utlöst innehåll. Notera eventuella flaggade problem med roller för verktygstips, kontrast eller fokus-synlighet — dessa bekräftar inte efterlevnad av 1.4.13 men etablerar en baslinje. Dokumentera vilka element som utlöser överläggsinnehåll så att du kan rikta in dig på dem i manuella steg.
2. Identifiera allt hover-/fokus-utlöst innehåll: Skrolla genom sidan och hovra systematiskt över varje interaktivt element — ikonknappar, länkar med extra beskrivningar, formulärfältsledtrådar, navigationsobjekt, datatabellrubriker och datapunkter i diagram. Lista varje element som gör att extra innehåll visas.
3. Testa kravet på hoverbarhet: För varje identifierad utlösare, hovra över den för att visa överlägget och flytta sedan långsamt pekaren från det utlösande elementet till själva överläggsinnehållet. Överlägget måste förbli synligt under hela denna förflyttning. Om det försvinner innan pekaren når det, misslyckas kriteriet.
4. Testa kravet på avfärdbarhet: Medan ett överlägg är synligt (utlöst av antingen hover eller tangentbordsfokus), tryck på Escape-tangenten. Överlägget måste stängas. Om det inte stängs misslyckas kriteriet. Gör detta test med pekaren fortfarande på utlösaren och även med pekaren över överlägget.
5. Testa kravet på beständighet: Utlös ett överlägg och låt sedan pekaren ligga stilla på utlösaren eller överlägget i minst 10–15 sekunder. Överlägget måste förbli synligt under hela tiden. Om det tonas ut, tidsgränssätts eller försvinner utan användaråtgärd misslyckas kriteriet.
6. Tangentbords-only-test: Tabba genom sidan med enbart tangentbordet. När fokus hamnar på en utlösare som visar extra innehåll, verifiera: (a) att innehållet visas, (b) att tryck på Escape stänger det och (c) att innehållet inte försvinner av sig självt medan fokus ligger kvar på utlösaren. Använd NVDA med Firefox, JAWS med Chrome och VoiceOver med Safari för att bekräfta att skärmläsare också exponerar innehållet korrekt.
7. Test med skärmförstoring: Ställ in webbläsarzoom på 400 % eller aktivera förstoring på OS-nivå. Upprepa hover-testerna. Bekräfta att en användare som måste panorera vyn för att nå verktygstipset kan göra det utan att verktygstipset försvinner.
8. Granska JavaScript-källan: Sök i kodbasen efter setTimeout, mouseleave, mouseout och blur-händelsehanterare som är kopplade till logik för att dölja överlägg. Bekräfta att dold-logik inte triggas medan pekaren är över överlägget eller medan utlösaren behåller fokus, och att ingen auto-stängningstimer är inställd.

Hur man åtgärdar

Endast CSS-verktygstips som försvinner vid mouseleave — Felaktigt

<!-- Tooltip only shown via CSS :hover on parent; disappears as soon as
     the pointer moves off the trigger toward the tooltip text -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; }
.tip-wrapper:hover .tooltip { display: block; }
-->

Endast CSS-verktygstips som försvinner vid mouseleave — Korrekt

<!-- Correct: tooltip is also shown when the pointer is over the tooltip itself,
     and the gap between trigger and tooltip is covered so pointer movement
     does not accidentally dismiss the overlay. -->
<span class='tip-wrapper'>
  Info
  <span class='tooltip' role='tooltip' id='tip1'>This is the tooltip content.</span>
</span>

<!-- CSS (illustrative) -->
<!--
.tooltip { display: none; position: absolute; }
.tip-wrapper:hover .tooltip,
.tooltip:hover { display: block; }
/* Use padding or a transparent pseudo-element bridge between trigger and tooltip */
-->

JavaScript-verktygstips utan Escape-avfärdande — Felaktigt

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
// Only mouseenter/mouseleave — no keyboard or Escape handling
document.querySelector('button').addEventListener('mouseenter', () => {
  document.getElementById('tip2').removeAttribute('hidden');
});
document.querySelector('button').addEventListener('mouseleave', () => {
  document.getElementById('tip2').setAttribute('hidden', '');
});
</script>

JavaScript-verktygstips utan Escape-avfärdande — Korrekt

<button aria-describedby='tip2' data-tooltip='Account balance details'>
  Balance
</button>
<div id='tip2' role='tooltip' hidden>Account balance details</div>

<script>
const btn = document.querySelector('button');
const tip = document.getElementById('tip2');

function showTip() { tip.removeAttribute('hidden'); }
function hideTip() { tip.setAttribute('hidden', ''); }

// Show on hover and focus
btn.addEventListener('mouseenter', showTip);
btn.addEventListener('focus', showTip);

// Hide only when pointer leaves BOTH trigger AND tooltip
btn.addEventListener('mouseleave', (e) => {
  // Short delay allows pointer to reach the tooltip
  setTimeout(() => {
    if (!tip.matches(':hover') && !btn.matches(':hover')) hideTip();
  }, 100);
});
tip.addEventListener('mouseleave', () => {
  if (!btn.matches(':hover')) hideTip();
});

// Hide on blur (keyboard)
btn.addEventListener('blur', hideTip);

// Dismissible via Escape key — required by 1.4.13
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape' && !tip.hidden) hideTip();
});
</script>

Auto-stängande verktygstips med setTimeout — Felaktigt

<button id='info-btn'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
document.getElementById('info-btn').addEventListener('mouseenter', () => {
  const t = document.getElementById('tip3');
  t.removeAttribute('hidden');
  // Violation: auto-dismisses after 3 seconds regardless of user state
  setTimeout(() => t.setAttribute('hidden', ''), 3000);
});
</script>

Auto-stängande verktygstips med setTimeout — Korrekt

<button id='info-btn' aria-describedby='tip3'>More info</button>
<div id='tip3' role='tooltip' hidden>Here is the additional information for this field.</div>

<script>
const btn2 = document.getElementById('info-btn');
const tip3 = document.getElementById('tip3');

// No setTimeout — tooltip persists until user removes hover/focus or presses Escape
function show() { tip3.removeAttribute('hidden'); }
function hide() {
  setTimeout(() => {
    if (!tip3.matches(':hover') && !btn2.matches(':hover') && document.activeElement !== btn2) {
      tip3.setAttribute('hidden', '');
    }
  }, 100);
}

btn2.addEventListener('mouseenter', show);
btn2.addEventListener('focus', show);
btn2.addEventListener('mouseleave', hide);
btn2.addEventListener('blur', hide);
tip3.addEventListener('mouseleave', hide);
document.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') tip3.setAttribute('hidden', '');
});
</script>

Vanliga misstag

• Att bara använda CSS-:hover utan att täcka gapet mellan utlösaren och verktygstipset: När det finns ett gap på bara 1–2 px mellan det utlösande elementet och verktygstipsbehållaren gör förflyttning av pekaren mellan dem att hover-tillståndet försvinner, vilket döljer verktygstipset innan användaren når det. Använd ett transparent pseudo-element eller överlappande padding för att överbrygga detta gap.
• Att binda dold-logik till mouseleave på utlösaren utan att kontrollera om pekaren har flyttats till verktygstipset: Verktygstipset försvinner i samma ögonblick som markören lämnar utlösaren, även om destinationen är själva verktygstipset. Kontrollera alltid tip.matches(':hover') innan du döljer, eller använd en kort debounce-fördröjning.
• Att glömma att koppla fokus- och blur-händelser tillsammans med mouseenter och mouseleave: Tangentbords-only-användare som tabbar till utlösaren kommer aldrig att se verktygstipset om endast mushändelser hanteras, vilket gör den associerade informationen helt otillgänglig utan mus.
• Att inte lägga till en Escape-tangentlyssnare och anta att det räcker att klicka bort: Tangentbordsanvändare och användare av skärmförstoring kan inte enkelt ”klicka bort” från ett överlägg. Escape är den förväntade och obligatoriska avfärdandemekanismen för detta kriterium.
• Att placera Escape-lyssnaren endast på det utlösande elementet istället för på document: Om användaren flyttar fokus till verktygstipset eller till ett annat element kommer en lyssnare som är begränsad till utlösaren inte att köras. Escape-hanteraren måste ligga på dokumentet eller en gemensam förfader som alltid tar emot tangentbordshändelser när överlägget är öppet.
• Att använda setTimeout för att auto-stänga verktygstips efter en fast varaktighet: All timerbaserad stängning som triggas medan pekaren fortfarande är på utlösaren eller verktygstipset, eller medan utlösaren fortfarande har tangentbordsfokus, är en direkt överträdelse av kravet på beständighet. Ta bort alla auto-stängningstimrar från hover-/fokus-utlösta överlägg.
• Att utlösa verktygstips-synlighet uteslutande genom att ersätta attributet title med anpassad styling: Utvecklare som tar bort det inbyggda verktygstipset från title och ersätter det med en anpassad version måste själva implementera alla tre kraven i 1.4.13. Undantaget för webbläsarens inbyggda verktygstips gäller inte för anpassade JavaScript-reproduktioner av samma mönster.
• Att inte testa med skärmförstoring vid 400 % zoom: Ett verktygstips som verkar tillgängligt vid normal zoom kan vara delvis utanför skärmen vid hög zoomnivå, vilket kräver att användaren panorerar — och om det stängs innan de kan panorera till det, misslyckas testet som klarade vid 100 % zoom i verkliga användningsförhållanden.
• Att använda pointer-events: none på verktygstipsbehållaren: Denna CSS-egenskap förhindrar att pekaren någonsin anses vara ”över” verktygstipset, vilket gör det omöjligt att uppfylla kravet på hoverbarhet oavsett annan logik. Verktygstips som användare kan behöva interagera med eller helt enkelt hovra över för att hålla synliga får aldrig ha pointer-events: none.
• Att behandla ARIA-role='tooltip' som tillräckligt för efterlevnad: Att lägga till role='tooltip' och aria-describedby är viktigt för skärmläsartillgänglighet men adresserar ett annat lager av problemet. Dessa ARIA-attribut gör inte automatiskt innehåll avfärdbart, hoverbart eller beständigt — interaktionsbeteendet måste fortfarande implementeras uttryckligen.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i den officiella tidningen med nummer 32933 den 21 juni 2025, fastställer ett formellt tillgänglighetsmandat som införlivar WCAG-standarder genom hänvisning. Cirkuläret kräver att berörda aktörer implementerar webbtillgänglighetsåtgärder i linje med internationellt erkända riktlinjer, och nivå AA-konformitet — som inkluderar WCAG 1.4.13 — är både starkt uppmuntrad och obligatorisk för aktörer som söker tillgänglighetslogotypen (Erişilebilirlik Logosu) som utfärdas av familje- och socialdepartementet (Aile ve Sosyal Hizmetler Bakanlığı).

Cirkuläret omfattar ett brett spektrum av aktörstyper som är verksamma i Turkiet. Offentliga institutioner och statliga organ på alla administrativa nivåer är skyldiga att göra sina digitala tjänster tillgängliga. Inom den privata sektorn sträcker sig skyldigheten till e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och privata vårdinrättningar, teleoperatörer med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor som verkar med tillstånd från utbildningsministeriet (Millî Eğitim Bakanlığı).

WCAG 1.4.13 är särskilt relevant i turkiska digitala sammanhang där mönster med verktygstips och popovers används i stor utsträckning i e-förvaltningsportaler (såsom e-Devlet-integrationer), bank- och fintech-gränssnitt som visar avgifts- eller ränteinformation i verktygstips och system för vårdbokning som visar ytterligare instruktioner via hover-utlösta överlägg. En bankplattform som inte uppfyller 1.4.13 kan hindra kunder med nedsatt syn från att läsa ränteinformation som levereras via verktygstips — ett scenario som har både tillgänglighets- och konsumentskyddsmässiga konsekvenser.

För aktörer som eftersträvar Erişilebilirlik Logosu kommer en tillgänglighetsrevision att inkludera manuell testning av hover- och fokus-beteenden just eftersom automatiserade verktyg inte kan upptäcka dessa överträdelser. Organisationer som använder ett tillgänglighetsöverläggs-SDK som Accsible bör säkerställa att alla verktygstips, guidade tur-popovers eller kontextuella hjälppaneler som injiceras av själva SDK:t fullt ut uppfyller alla tre kraven i 1.4.13 — avfärdbara via Escape, hoverbara utan att stängas och beständiga tills användaren agerar. Underlåtenhet att göra detta skulle introducera nya hinder genom det verktyg som är avsett att förbättra tillgängligheten, vilket undergräver både regelefterlevnad och användarnas förtroende.