WCAG 2.5.5: Målstorlek (utökad)

Vad den här regeln innebär

WCAG 2.5.5 Target Size (Enhanced) är ett kriterium på nivå AAA enligt WCAG 2.2 som fastställer en strikt minsta storlek för interaktiva element. Specifikt kräver den att storleken på målet — det klickbara eller tryckbara området för en användargränssnittskomponent — måste vara minst 44 gånger 44 CSS-pixlar i både bredd och höjd. Detta gäller alla pekarbaserade interaktioner, inklusive musklick, tryck på pekskärm och inmatning med penna.

Det är viktigt att förstå vad som exakt utgör ”målet” i detta sammanhang. Målet är hela det aktiverbara området för kontrollen, inte bara dess visuella representation. En liten ikon kan visuellt vara 16×16 pixlar, men om den omgivande utfyllnaden (padding) utökar det klickbara området till 44×44 pixlar kan kriteriet ändå uppfyllas. Detta innebär att utvecklare kan använda padding strategiskt för att uppfylla kravet utan att dramatiskt ändra den visuella designen.

Kriteriet definierar ett godkänt som varje interaktivt element vars målarea mäter minst 44×44 CSS-pixlar. Ett underkänt inträffar när ett interaktivt elements aktiverbara område hamnar under denna tröskel i någon dimension — till exempel skulle en länk som är 44 pixlar bred men bara 20 pixlar hög ändå underkännas.

WCAG 2.5.5 innehåller flera officiella undantag där kravet 44×44 inte gäller. Dessa är:

• Avstånd: För små mål är acceptabla om tillräckligt avstånd skiljer dem från alla andra mål. Målet måste vara placerat så att om en cirkel på 44×44 CSS-pixlar centrerades på det, skulle den cirkeln inte skära något annat mål eller begränsningsrutan för någon annan måls 44×44-cirkel. Detta undantag förhindrar att regeln kräver layoutändringar när angränsande kontroller är i sig små men väl separerade.
• Likvärdigt: En alternativ kontroll på samma sida utför samma funktion och uppfyller minimikravet på storlek.
• Inline: Målet finns i en mening eller dess storlek är annars begränsad av radavståndet (line-height) för icke-måltext. Hyperlänkar i ett stycke brödtext är till exempel undantagna eftersom en storleksändring skulle störa textflödet.
• Användaragentkontroll: Storleken bestäms helt av webbläsaren eller operativsystemet och kan inte ändras av författaren. Inbyggda formulärkontroller i webbläsaren i ostylat tillstånd kan falla i denna kategori.
• Väsentligt: En viss presentation av målet är väsentlig för den information som förmedlas. Detta är ett snävt undantag för fall där en ändring av målstorleken fundamentalt skulle förändra betydelse eller funktionalitet.

Detta kriterium introducerades i WCAG 2.2 och ersätter den tidigare, mindre strikta vägledningen om pekarmål. Dess följeslagare, kriteriet WCAG 2.5.8 Target Size (Minimum) på nivå AA, sätter en lägre gräns på 24×24 CSS-pixlar med en avståndsbaserad beräkning, men 2.5.5 förblir guldstandarden för förbättrad tillgänglighet.

Varför det är viktigt

Motoriska och finmotoriska nedsättningar påverkar en betydande del av världens befolkning. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor — eller 16% av världens befolkning — med någon form av betydande funktionsnedsättning, där motoriska och muskuloskeletala tillstånd är bland de vanligaste. Tillstånd som Parkinsons sjukdom, essentiell tremor, cerebral pares, multipel skleros, stroke-relaterad hemiplegi och belastningsskador minskar alla en persons förmåga att utföra precisa pekarrörelser. På mobila enheter kan även användare utan funktionsnedsättning ha svårt med små mål när de använder handskar, när händerna är blöta eller helt enkelt när de använder en telefon med en hand.

Föreställ dig ett konkret scenario i verkligheten: en person med reumatoid artrit surfar på en turkisk e-handelsplattform på en pekskärmsplatta för att köpa medicin. Kassaflödet innehåller små alternativknappar (radio buttons), smala rullgardinsmenyer och en 24×18-pixelknapp ”Bekräfta beställning”. Varje feltryck antingen väljer fel alternativ eller gör ingenting, vilket tvingar användaren att försöka flera gånger. Frustrationen är inte bara obekväm — den kan få personen att avbryta köpet helt, vilket förvandlar ett tillgänglighetsfel till en direkt intäktsförlust för företaget.

Utöver motoriska nedsättningar gynnar tillräckligt stora mål en bred grupp användare. Äldre vuxna upplever ofta både nedsatt finmotorik och försämrad synskärpa, vilket gör små mål dubbelt svåra. Användare med kognitiva funktionsnedsättningar kan behöva längre tid för att placera en pekare och är mer benägna att utlösa angränsande kontroller om målen är trångt placerade. Även seende, icke-funktionsnedsatta användare gynnas av större mål på mobila enheter — en sanning som har drivit designkonventioner hos stora teknikföretag i många år. Apples Human Interface Guidelines rekommenderar ett minsta tryckmål på 44×44 punkter, och Googles Material Design-riktlinjer rekommenderar minst 48×48 densitetsoberoende pixlar av samma skäl.

Ur ett SEO- och användbarhetsperspektiv belönar Googles Core Web Vitals-mått ”Interaction to Next Paint” (INP) gränssnitt där användarinteraktioner registreras snabbt och korrekt. Feltryck orsakade av för små mål ökar frekvensen av misslyckade interaktioner, ökar tiden för att utföra uppgifter och höjer avvisningsfrekvensen — alla signaler som indirekt kan påverka sökrankning. Tillgänglighetsförbättringar på pekarnivå har därför mätbara affärskonsekvenser utöver efterlevnad.

Relaterade Axe-core-regler

WCAG 2.5.5 kräver manuell testning. Det finns ingen helt automatiserad axe-core-regel som pålitligt flaggar alla överträdelser av målstorlek för detta förbättrade kriterium. Anledningen till att automatiserade verktyg har svårt här är mångfacetterad: den effektiva målstorleken beror på beräknad CSS-layout inklusive padding, marginaler och pseudo-elementdimensioner som varierar beroende på visningsfönster, enhetens pixeltäthet och dynamisk rendering. Dessutom kräver avståndsundantaget att man beräknar det geometriska avståndet mellan angränsande mål — en beräkning som kräver hela det renderade layoutträdet och närhetsanalys som automatiserade DOM-parsningsverktyg inte kan utföra korrekt i alla fall. Vidare kräver bedömningen av om ett element kvalificerar för undantagen ”inline” eller ”likvärdigt” semantisk och kontextuell förståelse som ligger bortom automatiserade regelmotorer.

• target-size (axe-core experimental): Axe-core innehåller en experimentell regel med namnet target-size som kontrollerar interaktiva element mot WCAG 2.5.8-nivå AA-tröskeln på 24×24 CSS-pixlar med avståndsjusteringar. Även om denna regel kan lyfta fram vissa mindre överträdelser, upprätthåller den inte den strängare tröskeln 44×44 som krävs av 2.5.5, och den kan missa överträdelser där padding eller pseudo-element påverkar det renderade träffområdet på sätt som DOM-ögonblicksbilden inte fångar. Behandla alla resultat från denna regel som en utgångspunkt, inte en fullständig granskning.
• Manuell visuell inspektion: Eftersom ingen automatiserad regel täcker 2.5.5 fullt ut måste testare visuellt inspektera och mäta interaktiva mål med hjälp av webbläsarens utvecklarverktyg, CSS-pixel-linjal eller tillgänglighetsutökningar för webbläsare. Detta inkluderar att kontrollera att padding ingår i träffområdet och att avståndsundantag verkligen uppfylls — inte bara antas.

Hur man testar

1. Kör en automatiserad skanning som baslinje: Öppna axe DevTools eller Lighthouse i Chrome DevTools på sidan som testas. I axe DevTools, filtrera resultaten efter ”target-size” om det finns under experimentella regler. Notera alla flaggade element, men förstå att denna skanning inte kommer att fånga alla 2.5.5-överträdelser och kan referera till 2.5.8-tröskeln snarare än 44×44 pixlar. Använd Lighthouse tillgänglighetsgranskning för att leta efter relaterade varningar om pekarmål.
2. Mät målstorlekar med webbläsarens DevTools: Öppna Chrome eller Firefox DevTools och använd panelen Elements för att inspektera varje interaktivt element — knappar, länkar, formulärfält, kryssrutor, alternativknappar, anpassade kontroller och ikon-only-kontroller. I panelen för beräknade stilar (Computed) kontrollerar du renderad bredd och höjd. Kom ihåg att padding ingår i klickmålet för blockelement men kanske inte för inline-element. Verifiera att det beräknade träffområdet är minst 44×44 CSS-pixlar.
3. Använd webbläsarens inbyggda tillgänglighetsverktyg: I Chrome DevTools, öppna fliken Rendering och aktivera ”Emulate a focused page” eller använd Accessibility Tree för att inspektera element. För Firefox, använd Accessibility Inspector för att identifiera interaktiva element och korsreferera deras begränsningsrutedimensioner.
4. Testa på riktiga pekskärmsenheter: Anslut en fysisk iOS-enhet och testa med VoiceOver aktiverat (tryck tre gånger på sidoknappen för att aktivera). Navigera genom att trycka och använd rotorn för att flytta mellan interaktiva element. Försök att aktivera små mål och notera hur ofta angränsande element utlöses av misstag. Upprepa på en Android-enhet med TalkBack (svep åt höger för att navigera, dubbeltryck för att aktivera). Var särskilt uppmärksam på anpassade widgetar byggda från <div>- eller <span>-element.
5. Testa avståndsundantag manuellt: För alla mål mindre än 44×44 pixlar som hävdar avståndsundantaget, rita en tänkt begränsningsruta på 44×44 pixlar centrerad på det målet och bekräfta visuellt att inget annat interaktivt element faller inom den rutan. Webbläsartillägg eller överläggsverktyg som ritar begränsningsrutor kan hjälpa här.
6. Tangentbords- och skärmläsarverifiering: Testa med NVDA + Firefox och JAWS + Chrome genom att tabba igenom alla interaktiva element. Även om tangentbordsfokus inte direkt testar pekarmålstorlek hjälper det till att identifiera om kontroller är nåbara och bekräftar den elementinventering som du kommer att korsreferera mot pekarstorlekar. VoiceOver + Safari på macOS kan användas för att verifiera att anpassade kontroller annonserar sig korrekt och har tillräckliga aktiveringsytor när de klickas med pekare.
7. Testa vid flera visningsfönsterstorlekar: Målstorlekar kan variera mellan desktop- och mobillayouter. Testa vid visningsfönsterbredderna 320px, 768px och 1280px för att bekräfta att responsiva designer bibehåller minimum 44×44 vid alla brytpunkter, särskilt i hamburgermenyer, karuseller och åtgärdskolumner i datatabeller.

Hur man åtgärdar

Endast ikonknapp med otillräcklig storlek — Felaktig

<!-- A close button rendered as a small SVG icon with no padding.
     The rendered size is approximately 16x16 CSS pixels, far below the 44x44 minimum. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

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

Endast ikonknapp med otillräcklig storlek — Korrekt

<!-- Padding is added to expand the hit area to at least 44x44 CSS pixels
     while preserving the visual icon size. The button itself has explicit
     min-width and min-height to guarantee compliance across browsers. -->
<button class='close-btn'>
  <svg width='16' height='16' aria-hidden='true'>
    <use href='#icon-close'></use>
  </svg>
  <span class='sr-only'>Close dialog</span>
</button>

<style>
.close-btn {
  background: none;
  border: none;
  padding: 14px; /* 16px icon + 14px * 2 padding = 44px total hit area */
  min-width: 44px;
  min-height: 44px;
  cursor: pointer;
  display: inline-flex;
  align-items: center;
  justify-content: center;
}
</style>

Anpassad kryssruta byggd från en div — Felaktig

<!-- A visually styled custom checkbox that is too small to meet the target size
     requirement. The div has no padding and renders at 20x20 pixels. -->
<div role='checkbox' aria-checked='false' tabindex='0' class='custom-check'></div>

<style>
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  cursor: pointer;
}
</style>

Anpassad kryssruta byggd från en div — Korrekt

<!-- The visual box remains 20x20 pixels but is wrapped in a label element
     whose total clickable area is expanded to 44x44 via padding.
     Using a native input element is strongly preferred over role=checkbox
     because it provides built-in keyboard and pointer behavior. -->
<label class='check-wrapper'>
  <input type='checkbox' class='sr-only'>
  <span class='custom-check' aria-hidden='true'></span>
  Subscribe to newsletter
</label>

<style>
.check-wrapper {
  display: inline-flex;
  align-items: center;
  gap: 8px;
  min-height: 44px; /* entire label row is at least 44px tall */
  cursor: pointer;
  padding: 12px 0; /* vertical padding expands the hit area */
}
.custom-check {
  width: 20px;
  height: 20px;
  border: 2px solid #333;
  border-radius: 3px;
  flex-shrink: 0;
}
.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
</style>

Navigationslänkar i ett verktygsfält med trångt avstånd — Felaktigt

<!-- Toolbar links rendered as small inline elements.
     Each link is approximately 32px wide and 24px tall,
     and they are spaced only 4px apart — failing both size and spacing exceptions. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 12px;
  padding: 2px 4px;
  margin: 0 2px;
}
</style>

Navigationslänkar i ett verktygsfält med trångt avstånd — Korrekt

<!-- Each link now has padding that expands its hit area to at least 44x44 px.
     The gap between links is also increased so the spacing exception would
     apply even if sizing were relaxed in future. -->
<nav aria-label='Secondary navigation'>
  <a href='/help' class='nav-link'>Help</a>
  <a href='/settings' class='nav-link'>Settings</a>
  <a href='/logout' class='nav-link'>Logout</a>
</nav>

<style>
.nav-link {
  font-size: 14px;
  display: inline-flex;
  align-items: center;
  min-height: 44px;
  padding: 0 16px; /* horizontal padding extends width well past 44px */
  margin: 0 4px;
  text-decoration: underline;
}
</style>

Vanliga misstag

• Att anta att den visuella begränsningsrutan är lika med träffområdet: Att sätta width: 44px; height: 44px på ikonbilden inuti en knapp gör inte knappen 44×44 — endast genom att lägga till dessa dimensioner eller motsvarande padding på själva <button>-elementet skapas rätt träffområde.
• Att använda padding: 0 för att återställa webbläsarens standardstilar utan en kompenserande minsta storlek: CSS-resets tar ofta bort all padding från knappar och inmatningsfält. Efter en reset bör du alltid återställa tillräcklig padding eller explicita värden för min-width och min-height för att återställa aktiveringsytan.
• Att enbart förlita sig på line-height för att öka målets höjd: Att öka line-height påverkar textavstånd men utökar inte alltid det klickbara området för en länk eller knapp. Använd istället padding-top och padding-bottom.
• Att placera flera små ikonknappar sida vid sida utan tillräckligt avstånd: En rad med 24×24 sociala medier-delningsikoner med endast 2px marginaler uppfyller varken storlekskravet eller avståndsundantaget, eftersom 44px-cirklarna centrerade på varje ikon skulle överlappa sina grannar.
• Att felaktigt tillämpa undantaget för inline-text på navigationslänkar: Undantaget gäller länkar inom en mening eller ett stycke med löpande text. Navigationsmenyer, verktygsfält och länklistor är inte inline-text och kvalificerar inte för detta undantag, även om de använder display: inline.
• Att bygga anpassade kontroller med role='button' på ett <span> och glömma att storleksanpassa span-elementet: Skärmläsare kommer att annonsera span som en knapp, men dess standardrenderade storlek bestäms endast av dess textinnehåll, vilket vanligtvis ligger långt under 44×44 pixlar. Lägg alltid till display: inline-flex, min-width, min-height och padding.
• Att inte testa på riktiga pekskärmsenheter i faktisk visningsfönsterstorlek: Att mäta pixlar i desktop-DevTools är inte tillräckligt. CSS-pixeltäthet och operativsystemets beteende för träfftestning av tryckmål kan skilja sig mellan simulerade och fysiska enhetsmiljöer.
• Att förbise dynamiskt renderade kontroller: Verktygstips, datumväljardagar, förslagsposter i autoslutförande och modala stängknappar injiceras ofta av JavaScript-bibliotek med hårdkodade små storlekar. Granska utdata från tredjepartswidgetar och åsidosätt deras stilar vid behov.
• Att hävda avståndsundantaget utan att mäta det: Avståndsundantaget är geometriskt och precist. Att visuellt anta att kontroller ser tillräckligt långt ifrån varandra ut är inte tillräckligt — 44px-cirkeltestet måste tillämpas på varje för litet mål för att bekräfta att ingen överlappning finns.
• Att glömma att verifiera efter ändringar vid responsiva brytpunkter: En knapp som är 44×44 på desktop kan krympa till 30×30 på ett mobilt visningsfönster på 375px på grund av procentuella bredder eller flexbox-krympning. Testa alltid målstorlekar på nytt vid varje större brytpunkt.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular No. 2025/10, publicerad i Official Gazette nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webb- och mobiltillgänglighet baserade på standarden WCAG 2.2. Cirkuläret gäller en definierad uppsättning aktörer som är verksamma i Turkiet och fastställer rättsliga skyldigheter för överensstämmelse med specifika WCAG-nivåer.

De aktörstyper som omfattas av cirkuläret inkluderar: offentliga institutioner och myndigheter på både central och lokal nivå; banker och finansiella institutioner som regleras av Banking Regulation and Supervision Agency (BDDK); sjukhus och vårdgivare, både offentliga och privata; teleoperatörer med 200,000 eller fler abonnenter; e-handelsplattformar över angivna omsättnings- eller transaktionströsklar; resebyråer som driver bokningstjänster online; privata transportföretag som erbjuder digital biljettförsäljning eller bokning; samt privata skolor och utbildningsinstitutioner auktoriserade av Ministry of National Education (MoNE).

WCAG 2.5.5 Target Size (Enhanced) är ett kriterium på nivå AAA och ingår inte bland de minimikrav som fastställs av cirkuläret, som främst fokuserar på efterlevnad av nivå A och AA. Cirkuläret uppmuntrar dock uttryckligen de aktörer som omfattas — särskilt de som betjänar allmänheten, vårdpatienter och studenter — att sträva efter AAA-överensstämmelse där det är möjligt, med erkännandet att det representerar bästa praxis för tillgänglighet.

För organisationer i Turkiet har implementering av WCAG 2.5.5 särskilt strategiskt värde i flera sammanhang. Myndighetsportaler som betjänar äldre medborgare, system för vårdbokning som används av patienter med kroniska tillstånd och bankapplikationer som används av personer med motoriska nedsättningar gynnas alla av målstorlekar på 44×44 pixlar. Turkiet har en snabbt åldrande befolkning, och Turkish Statistical Institute (TÜİK) förutspår att medborgare 65 år och äldre kommer att utgöra över 16% av befolkningen år 2040 — en demografi för vilken pekarmålstorlek är en kritisk användbarhetsfaktor.

Även där AAA inte är juridiskt obligatoriskt visar organisationer som frivilligt uppfyller WCAG 2.5.5 ett engagemang som kan minska risken för rättsprocesser, stärka möjligheterna i upphandlingar av offentliga kontrakt som kräver tillgänglighetsdokumentation och förbättra användarnöjdhetsmått på konkurrensutsatta marknader som e-handel och fintech. Accsible’s SDK tillhandahåller konfigurerbara funktioner för förbättrade tryckmål som kan hjälpa organisationer att uppfylla eller närma sig detta kriterium, och dokumentation av sådana insatser kan utgöra en del av en Accessibility Conformance Report (ACR) eller VPAT-inlämning som krävs i institutionella upphandlingsprocesser.