WCAG 2.5.8: Målstorlek (minimi)

Vad den här regeln innebär

WCAG 2.5.8 Target Size (Minimum) är ett framgångskriterium på nivå AA som introducerades i WCAG 2.2. Det anger att storleken på målet för pekarinmatning måste vara minst 24×24 CSS-pixlar, med ett viktigt undantag: om själva målet är mindre än 24×24 CSS-pixlar måste det finnas tillräckligt med offset-avstånd runt det så att den totala ytan — inklusive avståndet — uppfyller 24×24-tröskeln i alla riktningar. Med andra ord måste målets begränsningsruta plus angränsande tomrum som är fritt från andra mål tillsammans nå 24 CSS-pixlar horisontellt och 24 CSS-pixlar vertikalt.

Kriteriet gäller för alla element som kan ta emot en pekarhändelse: länkar (<a>), knappar (<button>), kryssrutor, alternativknappar, select-kontroller, reglage, anpassade widgets med lyssnare för pekarhändelser och alla element som har tilldelats en ARIA-roll som innebär interaktivitet. Det gäller inte icke-interaktiva element som dekorativa bilder eller statisk text, även om de råkar vara stora.

Ett mål klarar detta kriterium när minst ett av följande är sant:

• Målets renderade storlek är minst 24×24 CSS-pixlar i båda dimensionerna.
• Målet är mindre än 24 CSS-pixlar i en eller båda dimensionerna, men avståndet mellan målets kant och närmaste angränsande interaktiva element är tillräckligt stort för att den kombinerade mål-plus-offset-ytan ska vara minst 24×24 CSS-pixlar.
• Målet är ett inline-element i en mening eller textblock, vilket uttryckligen undantas eftersom omflöde av sådana mål skulle störa läsningen.
• Målets visuella storlek bestäms helt av webbläsarens standard-user-agent-stilmall och författaren har inte ändrat den — detta är undantaget för inbyggda kontroller.
• Det finns en icke-interaktiv presentation av samma information och det lilla målet är bara ett alternativ, inte det enda sättet att aktivera funktionen.

Ett mål underkänns när det är mindre än 24×24 CSS-pixlar och det inte finns tillräckligt med offset-avstånd för att kompensera, och inget av undantagen ovan gäller. Vanliga fel i verkligheten inkluderar små ikon-only-knappar (till exempel en 16×16 stäng-ikon i en modal), tätt packade navigationslänkar med minimal padding och rader med delningsikoner där varje ikon renderas i 20×20 pixlar med endast 2px marginal mellan dem.

Det är värt att notera att WCAG 2.5.8 är ett minimikrav. Det relaterade AAA-kriteriet 2.5.5 Target Size (Enhanced) kräver minst 44×44 CSS-pixlar utan undantag för offset-avstånd, och många användbarhetsriktlinjer rekommenderar 44–48 CSS-pixlar som ett bekvämt touch-mål. Att uppfylla 2.5.8 är golvet, inte taket.

Varför det är viktigt

Motoriska funktionsnedsättningar påverkar pekarprecision på många olika sätt. Personer med Parkinsons sjukdom, essentiell tremor, cerebral pares, multipel skleros, stroke-relaterad hemiplegi eller belastningsskador kan ha svårt att träffa ett litet mål på ett tillförlitligt sätt. Äldre vuxna upplever också en naturlig försämring av finmotoriken: ungefär 15% av personer över 65 rapporterar betydande svårigheter att använda mus eller pekskärm. Utöver kliniska tillstånd har även situationellt nedsatta användare — någon som håller en smartphone med en hand på en rörlig buss, eller någon vars finger är stort i förhållande till en liten telefonskärm — svårt med mycket små mål.

Enligt Världshälsoorganisationen lever över 1,3 miljarder människor världen över med någon form av funktionsnedsättning, och motorisk funktionsnedsättning är en av de vanligaste kategorierna. När interaktiva element är för små eller sitter för tätt upplever dessa användare oavsiktliga aktiveringar, missade tryckningar och upprepade fel som gör en webbplats i praktiken oanvändbar. Frustrationen förstärks på touch-enheter där det inte finns något hover-tillstånd som bekräftar markörens position innan man klickar.

Överväg ett konkret scenario: en turkisk e-handelssajt som säljer elektronik visar en rad med fem delningsikoner högst upp på varje produktsida, vardera 18×18 pixlar med 3px mellanrum. En användare med essentiell tremor som försöker dela en produkt till WhatsApp trycker upprepade gånger på fel ikon, vilket utlöser oönskade Facebook-delningar. Det finns inget sätt för henne att snabbt ångra dessa delningar, och uppgiften blir så felbenägen att hon överger den helt. Att öka varje ikon till 24×24 CSS-pixlar, eller lägga till padding så att den klickbara ytan når 24×24, skulle lösa problemet utan att ändra den visuella designen nämnvärt.

Utöver tillgänglighet korrelerar tillräcklig målstorlek med högre konverteringsgrad, lägre avvisningsfrekvens och bättre Core Web Vitals-poäng relaterade till interaktionsberedskap. Mobil-först-indexering av sökmotorer gynnar också sidor som erbjuder god touch-användbarhet, vilket gör målstorlek till en faktor som förenar tillgänglighet och SEO.

Relaterade Axe-core-regler

• target-size (experimental): Den här regeln kontrollerar om interaktiva element har en renderad storlek på minst 24×24 CSS-pixlar eller, för mindre element, om det finns tillräckligt med offset-avstånd så att den totala nåbara ytan uppfyller tröskeln. Regeln frågar efter beräknade dimensioner och begränsningsrektanglar för fokuserbara och pekar-interaktiva element och flaggar alla som inte klarar storleks-eller-offset-testet. Eftersom den för närvarande är markerad som experimental ingår den inte i axe-core:s standardregeluppsättning och måste uttryckligen aktiveras med runOnly: { type: 'tag', values: ['wcag22aa', 'experimental'] } eller genom att aktivera experimentella regler i axe DevTools. Regeln kan ge falska positiva för inline-textlänkar och inbyggda kontroller som webbläsare storleksbestämmer olika på olika plattformar, så manuell granskning rekommenderas alltid efter en automatiserad skanning. Den kan inte på ett tillförlitligt sätt upptäcka offset-baserade godkännanden när komplexa CSS-layouts, transformeringar eller överlappande z-index-staplingskontexter är inblandade, vilket är anledningen till att manuell inspektion av beräknade stilar i DevTools förblir nödvändig.

Eftersom målstorlek beror på visuell rendering, beräknad CSS, viewport-dimensioner och närheten till angränsande interaktiva element kan automatiska verktyg flagga uppenbara fel men kan inte ersätta mänskligt omdöme. Ett verktyg kan mäta en knapps begränsningsruta, men att avgöra om offset-avståndet mellan två angränsande mål verkligen är fritt från andra interaktiva element — särskilt i dynamiska eller JavaScript-drivna gränssnitt — kräver manuell verifiering.

Hur man testar

1. Automatisk skanning med axe DevTools: Installera webbläsartillägget axe DevTools. Öppna sidan som ska testas. I panelen för axe DevTools, aktivera experimentella regler innan du kör skanningen (leta efter filter för regeltaggar och lägg till experimental). När skanningen är klar, filtrera resultaten efter regel-ID:t target-size. För varje flaggat element, notera de rapporterade dimensionerna. Verifiera fyndet manuellt innan du loggar det som ett bekräftat fel, eftersom experimentella regler har en högre andel falska positiva.
2. Automatisk skanning med Lighthouse: Kör en Lighthouse-tillgänglighetsgranskning i Chrome DevTools eller via CLI. Lighthouse inkluderar en tap-targets-granskning som kontrollerar mål mindre än 48×48 CSS-pixlar med otillräckligt avstånd — observera att detta använder en striktare tröskel än WCAG 2.5.8, så Lighthouse-fel är en superset av WCAG-fel. Granska de flaggade elementen i rapporten och korsreferera med WCAG-tröskeln 24×24 för att avgöra vilka som utgör faktiska fel på nivå AA jämfört med bästa praxis-rekommendationer.
3. Manuell mätning med webbläsarens DevTools: Öppna DevTools och inspektera varje interaktivt element. I panelen Computed, kontrollera width och height. Om någon av dem är under 24px, växla till Box Model-vyn och kontrollera padding. Om padding gör att målet når 24×24, är det godkänt. Om inte, mät avståndet till närmaste angränsande interaktiva element med hjälp av elementets begränsningsrektangel: kör document.querySelector('your-selector').getBoundingClientRect() i konsolen och jämför koordinaterna för angränsande element. Om det kombinerade avståndet i varje dimension gör den effektiva nåbara ytan till 24px, är det godkänt.
4. Touch-simulering: Aktivera enhetsemulering i Chrome DevTools och växla till en touch-optimerad enhetsprofil. Försök att trycka på varje litet interaktivt element. Notera alla tillfällen där det är svårt att aktivera det avsedda elementet eller där angränsande element oavsiktligt triggas.
5. Tangentbords- och skärmläsartestning (för sammanhang): Även om WCAG 2.5.8 specifikt är ett pekar-kriterium hjälper det att bekräfta att små mål också har synliga fokusindikatorer och är nåbara med tangentbord för att identifiera sammansatta problem. Använd NVDA med Firefox eller JAWS med Chrome för att navigera mellan interaktiva element och bekräfta att de är nåbara och kan aktiveras oavsett storlek.
6. Testning på verkliga enheter: Testa på en fysisk mobil enhet — helst både en Android med stor skärm och en mindre iOS-enhet — för att bekräfta att mål som klarar kraven på desktop också gör det vid mobila viewport-storlekar, eftersom CSS-pixeltäthet och zoom-beteende kan påverka upplevd målstorlek.

Hur man åtgärdar

Liten ikon-only-knapp — Felaktig

<!-- Close button is only 16x16 CSS pixels, no padding, adjacent to other controls -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    width: 16px;
    height: 16px;
    padding: 0;
    border: none;
    background: none;
    cursor: pointer;
  }
</style>

Liten ikon-only-knapp — Korrekt

<!-- Adding padding increases the interactive area to 24x24 CSS pixels
     while the visual icon remains 16x16. The min-width/min-height
     ensures the target meets the WCAG 2.5.8 threshold. -->
<button class='close-btn' aria-label='Close dialog'>
  <svg width='16' height='16' aria-hidden='true'></svg>
</button>

<style>
  .close-btn {
    min-width: 24px;
    min-height: 24px;
    padding: 4px;
    border: none;
    background: none;
    cursor: pointer;
    display: inline-flex;
    align-items: center;
    justify-content: center;
  }
</style>

Tätt packade navigationslänkar — Felaktigt

<!-- Each link renders at roughly 20px tall with 1px margin,
     leaving insufficient offset spacing between targets -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list li { margin: 1px 0; }
  .nav-list a { font-size: 12px; line-height: 1.4; display: block; }
</style>

Tätt packade navigationslänkar — Korrekt

<!-- Padding on each anchor ensures the target area is at least 24px tall.
     The gap between items is now large enough to satisfy the offset rule
     even if the text itself is smaller than 24px. -->
<nav aria-label='Main navigation'>
  <ul class='nav-list'>
    <li><a href='/about'>About</a></li>
    <li><a href='/services'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

<style>
  .nav-list { list-style: none; padding: 0; margin: 0; }
  .nav-list a {
    display: block;
    padding: 6px 8px; /* vertical padding brings block height to >= 24px */
    font-size: 14px;
    line-height: 1.4;
    text-decoration: none;
  }
</style>

Kryssruta med mycket liten träffyta — Felaktig

<!-- The default checkbox is visually 13px on many browsers and has no
     associated label providing additional target area -->
<input type='checkbox' id='agree'>
<span>I agree to the terms</span>

Kryssruta med associerad label — Korrekt

<!-- Wrapping the input in a <label> makes the entire label text also
     a valid pointer target. The label's line-height and padding ensure
     the combined hit area easily exceeds 24x24 CSS pixels.
     The input itself is given min-width/min-height as a fallback. -->
<label class='checkbox-label'>
  <input type='checkbox' id='agree' class='checkbox-input'>
  I agree to the terms
</label>

<style>
  .checkbox-label {
    display: inline-flex;
    align-items: center;
    gap: 8px;
    padding: 4px 0;
    cursor: pointer;
    min-height: 24px;
  }
  .checkbox-input {
    min-width: 24px;
    min-height: 24px;
    cursor: pointer;
  }
</style>

Rad med delningsikoner — Felaktig

<!-- Each icon is 18x18px with only 2px gap; the combined
     reachable area for each icon is only 20px, below the 24px threshold -->
<div class='share-row'>
  <a href='#' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 2px; }
  .share-row a { display: inline-block; line-height: 1; }
</style>

Rad med delningsikoner — Korrekt

<!-- Each anchor now has min-width and min-height of 24px via padding,
     and the gap between anchors is at least 3px so the offset rule is
     satisfied independently even without the padding. -->
<div class='share-row'>
  <a href='#' class='share-link' aria-label='Share on Twitter'>
    <img src='twitter.svg' width='18' height='18' alt=''>
  </a>
  <a href='#' class='share-link' aria-label='Share on Facebook'>
    <img src='facebook.svg' width='18' height='18' alt=''>
  </a>
</div>

<style>
  .share-row { display: flex; gap: 6px; }
  .share-link {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 24px;
    min-height: 24px;
    padding: 3px;
  }
</style>

Vanliga misstag

• Att sätta width och height på ikonen inuti en knapp i stället för på själva knappen: Utvecklare begränsar ofta SVG:n eller bilden till 16–20px men glömmer att <button>-elementet behöver min-width: 24px; min-height: 24px och lämplig padding för att skapa ett tillräckligt stort touch-mål.
• Att ta bort webbläsarens standardpadding från knappar och inmatningsfält med padding: 0 eller en global reset: CSS-resets som nollställer padding på formelement tar bort bufferten som håller inbyggda kontroller i en användbar storlek. Lägg alltid till explicit padding igen efter en reset.
• Att enbart förlita sig på line-height för att öka länkhöjden utan display: block eller display: inline-block: Inline-element reagerar inte på height eller vertikal padding på samma sätt som blockelement, så en länk kan se högre ut visuellt medan dess faktiska klickbara begränsningsruta förblir liten.
• Att använda pointer-events: none på en wrapper och koppla klick-händelser till ett mycket litet inre element: Detta motverkar all padding eller min-storlek som tillämpas på wrappern och reducerar det effektiva målet till det inre elementets renderade storlek.
• Att tillämpa overflow: hidden på en knappbehållare som klipper bort knappens padding: Den visuella klickytan klipps till behållarens gränser, vilket gör det effektiva målet mindre än vad knappens egna dimensioner antyder.
• Att glömma att ta hänsyn till CSS-transformeringar som scale(): En knapp som skalas ned visuellt via transform: scale(0.7) har fortfarande sin ursprungliga begränsningsruta för pekarhändelser i de flesta webbläsare, men detta beteende är inkonsekvent och opålitligt — storleksbestäm alltid mål i deras slutliga renderade skala.
• Att anta att en stor <label> kompenserar för ett mycket litet <input> när label och input inte är programmatiskt associerade: Om <label> inte använder for som matchar inputens id, eller om input inte är innesluten i labeln, aktiverar inte ett klick på label-texten inputen, så endast inputens egen lilla målyta är funktionell.
• Att inte testa vid de viewport-storlekar där målen faktiskt renderas: En knapp som är 32×32 CSS-pixlar på desktop kan renderas i 22×22 CSS-pixlar i en smal mobil viewport på grund av flytande skalning eller viewport-relativa enheter (vw, vmin), vilket skapar ett fel som bara uppträder på mobil.
• Att tolka WCAG 2.5.8-undantaget för inline-textlänkar alltför brett: Undantaget gäller endast länkar som verkligen är inline i en textström (t.ex. en hyperlänk i ett stycke). Fristående länkar som är stylade för att se ut som text — såsom en "Forgot password?"-länk under ett formulär — är inte inline-länkar och måste uppfylla 24×24-tröskeln.
• Att inte granska tredjepartswidgets och inbäddade komponenter: Bannrar för cookie-samtycke, chatt-widgets och analysöverlägg innehåller ofta mycket små knappar (acceptera, stäng, minimera) som injiceras av externa skript. Dessa är fortfarande en del av sidans tillgänglighetsprofil och måste följa WCAG 2.5.8 även om koden inte är skriven internt.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer bindande tillgänglighetskrav för ett brett spektrum av digitala tjänsteleverantörer som är verksamma i Turkiet. Cirkuläret hänvisar uttryckligen till WCAG 2.2 som den tekniska standarden, och överensstämmelse på nivå AA krävs för att kvalificera sig för Erişilebilirlik Logosu (tillgänglighetslogotypen) som utfärdas av Ministeriet för familje- och socialtjänster (Aile ve Sosyal Hizmetler Bakanlığı). Eftersom WCAG 2.5.8 är ett kriterium på nivå AA i WCAG 2.2 faller det direkt inom ramen för detta obligatoriska ramverk.

De enhetstyper som omfattas av cirkuläret inkluderar offentliga institutioner och statliga myndigheter på central och lokal nivå, banker och finansiella tjänsteföretag, sjukhus och privata vårdgivare, telekomoperatörer med 200,000 eller fler abonnenter, e-handelsplattformar, resebyråer, privata transportföretag och privatskolor som auktoriserats av Ministeriet för nationell utbildning (Milli Eğitim Bakanlığı). För alla dessa organisationer är efterlevnad av WCAG 2.5.8 inte bara en rekommendation om bästa praxis — det är en regulatorisk skyldighet kopplad till möjligheten att visa tillgänglighetslogotypen och att kunna uppvisa juridisk efterlevnad vid revisioner.

I praktiken innebär detta att en turkisk banks mobilanpassade webbapplikation måste säkerställa att dess knappar för bekräftelse av överföringar, engångslösenordsfält och navigationskontroller alla uppfyller minimikravet 24×24 CSS-pixlar för målstorlek. På samma sätt måste en e-handelssajt verifiera att dess lägg-i-varukorg-knappar, kvantitetsväljare och filterkontroller är tillräckligt stora i alla enhetsprofiler. Vårdsajter måste granska bokningskalendrar för tider, som är ökända för små datumceller, och antingen förstora dessa celler eller tillhandahålla tillräckligt offset-avstånd. Självbetjäningsportaler för telekom måste kontrollera att deras länkar för kontohantering och växlingskontroller i dataplansväljare uppfyller tröskeln.

Underlåtenhet att följa cirkuläret kan leda till administrativa sanktioner och kan hindra en organisation från att visa tillgänglighetslogotypen, som i allt högre grad används som en förtroendesignal av turkiska konsumenter. Utöver sanktioner utsätter bristande efterlevnad organisationer för klagomål som lämnas in till relevanta tillsynsorgan. Med tanke på att Turkiet har en växande andel äldre — Turkiets statistikinstitut förutspår att personer 65 år och äldre kommer att utgöra 16,3% av befolkningen år 2040 — kommer den praktiska påverkan av små mål bara att öka över tid, vilket gör tidig efterlevnad både till en etisk prioritet och en sund långsiktig affärsstrategi.