WCAG 2.5.1: Pekgester

Vad den här regeln innebär

WCAG 2.5.1 Pointer Gestures kräver att all funktionalitet på en webbsida som är beroende av flerpunktgester (gester som använder två eller fler samtidiga beröringspunkter, såsom nyp med två fingrar för att zooma eller svep med tre fingrar) eller banbaserade gester (gester där banan som pekaren färdas är viktig, såsom ett svep, en dragning längs en specifik rutt eller en ritad form) också måste kunna användas med en enda pekare på ett sätt som inte kräver en banbaserad gest. En enda pekare är all inmatning som verkar på en enda punkt — detta inkluderar en enkel fingertryckning, ett musklick, en stylus-tryckning och liknande inmatningar.

I praktiken innebär detta att om din karusell går vidare mellan bilder när användaren sveper horisontellt över den, måste du också tillhandahålla framåt- och bakåtknappar som kan aktiveras med en enkel tryckning eller ett klick. Om din anpassade kartwidget reagerar på nyp med två fingrar för att zooma in eller ut, måste du också tillhandahålla zooma in- och zooma ut-kontroller som bara kräver en enkel tryckning. Kriteriet förbjuder inte flerpunkt- eller banbaserade gester — det kräver helt enkelt att det alltid finns en likvärdig alternativ lösning med en enda pekare.

Det officiella WCAG-undantaget säger: kravet gäller inte när flerpunkt- eller banbaserade gester är väsentliga. En väsentlig gest är en där borttagning skulle förändra informationen eller funktionaliteten i grunden, och text eller ett annat alternativ inte kan uppnå samma syfte. En frihands-signaturwidget eller ett ritprogram där den ritade banan i sig är resultatet skulle kvalificera som väsentlig. Den stora majoriteten av navigations-, karusell-, kart- och reglageinteraktioner kvalificerar dock inte för detta undantag, eftersom de kan återskapas med enkla tryck-/klickalternativ utan någon informationsförlust.

Detta kriterium gäller all pekarinmatning: pekskärmar, mus, stylus, ögonspårningspekare och alla andra pekdon. Det är ett krav på nivå A enligt WCAG 2.2, vilket innebär att det betraktas som ett grundläggande tillgänglighetskrav som måste uppfyllas för minsta överensstämmelse.

En godkänd implementation tillhandahåller minst en mekanism för att utföra varje gestberoende funktion med en aktivering med en enda punkt som inte är banbaserad — vanligtvis en synlig knapp, länk eller annan fokuserbar kontroll. En underkänd implementation förlitar sig uteslutande på en svep-, nyp-, spreta-, rotera- eller ritad-bana-gest för att utföra en funktion, utan att någon likvärdig alternativ lösning med en enda pekare tillhandahålls.

Varför det är viktigt

Motoriska funktionsnedsättningar påverkar en betydande del av världens befolkning. Tillstånd som Parkinsons sjukdom, essentiell tremor, cerebral pares, stroke-relaterad hemiplegi, extremitetsskillnader och belastningsskador kan göra det svårt eller omöjligt för användare att utföra precisa flerpunkt- eller banbaserade gester på ett tillförlitligt sätt. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor världen över med någon form av betydande funktionsnedsättning, och motoriska och rörlighetsrelaterade funktionsnedsättningar är bland de vanligaste kategorierna. När webbgränssnitt uteslutande förlitar sig på komplexa gester stängs dessa användare helt ute från funktionalitet som seende användare utan funktionsnedsättning tar för given.

Föreställ dig ett konkret scenario i verkligheten: en användare med essentiell tremor surfar på en turkisk e-handelssajt på en surfplatta. Produktbildgalleriet använder endast en svepgest för att gå mellan foton. Användaren kan inte pålitligt utföra ett rent horisontellt svep — deras tremor orsakar oavsiktliga tryckningar, diagonala rörelser eller oavsiktliga flerfingerberöringar. Utan föregående/nästa-knappar kan de inte visa fler produktbilder och kan helt avbryta köpet. Att lägga till två enkla pilknappar kostar utvecklingsteamet några minuter men tar bort en total barriär för den här användaren.

Utöver motoriska funktionsnedsättningar gynnar detta kriterium också användare med överproteser eller enknappshjälpmedel som emulerar en enda pekare, användare som använder enheter monterade på rullstolar där rotation eller multitouch är mekaniskt opraktiskt, och äldre vuxna som upplever komplexa touchgester som ointuiva eller svåra att lära sig. Användare som använder en enhet med mus eller en icke-touch-stylus påverkas också direkt — dessa inmatningsmetoder är i grunden enkelpekare och kan inte utföra flerpunktgester över huvud taget.

Ur ett användbarhets- och affärsperspektiv förbättrar tillhandahållandet av explicita kontroller för en enda pekare (knappar, länkar) också upptäckbarheten för alla användare, minskar den kognitiva belastningen och kan bidra positivt till uppgiftsgenomförandegrad och konverteringsmätvärden. Sökmotorer kan också tolka och följa knappdriven navigering mer tillförlitligt än gestdrivna interaktioner, vilket ger sekundära SEO-fördelar för genomsökningsbar navigering.

Relaterade Axe-core-regler

WCAG 2.5.1 kräver manuell testning eftersom automatiserade verktyg inte på ett tillförlitligt sätt kan upptäcka om ett gestberoende beteende har ett alternativ med en enda pekare. Ingen automatiserad axe-core-regel motsvarar direkt detta kriterium. Skälen till att automatiserad upptäckt är otillräcklig är:

• Manuell testning krävs — gestdetektering: Automatiska skannrar analyserar statisk DOM-struktur och beräknade stilar. De kan inte observera JavaScript-händelselyssnares beteende vid körning på ett sätt som skiljer mellan om en touchstart/touchmove/touchend-hanterare implementerar ett banberoende svep eller bara en tryckning. En skanner ser att touchhändelser finns men kan inte avgöra om den resulterande funktionaliteten också är tillgänglig via ett alternativ med en enda pekare. Detta kräver att en mänsklig testare interagerar med gränssnittet med både gestbaserade och enkelpekarmetoder och jämför den tillgängliga funktionaliteten.
• Manuell testning krävs — verifiering av likvärdighet: Även om ett verktyg skulle kunna markera att en flerpunktgest-lyssnare finns, kan det inte utvärdera om en tillhandahållen knapp eller länk uppnår funktionellt likvärdiga resultat. Att verifiera likvärdighet — att alternativet utlöser samma resultat, att det är synligt och nåbart och att det inte är dolt bakom ett extra steg — kräver mänskligt omdöme baserat på kriteriets avsikt.
• Manuell testning krävs — undantaget för väsentliga gester: Att avgöra om en gest kvalificerar för undantaget ”väsentlig” kräver kontextuell förståelse av applikationens syfte som ingen automatiserad regel på ett tillförlitligt sätt kan bedöma.

Testare bör använda webbläsarens utvecklarverktyg för att inspektera bifogade händelselyssnare (i Chrome DevTools, högerklicka på ett element, välj ”Inspect” och visa sedan fliken ”Event Listeners”) som en utgångspunkt för att identifiera vilka element som har touch- eller pekarhändelsehanterare, och sedan manuellt verifiera förekomsten och likvärdigheten hos alternativ med en enda pekare.

Hur man testar

1. Kör en automatisk skanning som baslinje: Använd axe DevTools, Lighthouse eller Accsible-widgetens inbyggda granskning för att skanna sidan. Även om ingen regel direkt motsvarar 2.5.1 kan skanningsresultaten markera relaterade problem (såsom saknade fokuserbara kontroller) som ger kontext för manuell granskning. Notera alla interaktiva element som flaggas för saknat tangentbords- eller pekarstöd.
2. Identifiera gestberoende funktionalitet: Utforska sidan manuellt på en touchenhet (eller med webbläsarens enhetsemulering i Chrome DevTools — växla enhetsverktygsfältet och interagera med simulerad touch). Leta efter karuseller, reglage, kartor, dragspel, bildgallerier, rullningsbara paneler, dra-och-släpp-gränssnitt, ritverktyg och alla andra komponenter som svarar på touchgester. Dokumentera varje funktion du upptäcker som utlöses av ett svep, nyp, rotera eller annan banbaserad eller flerpunktgest.
3. Försök med motsvarigheter med en enda pekare: För varje gestberoende funktion som identifierats, försök att utföra samma funktion med endast enkla tryckningar (eller musklick på en stationär dator). Kontrollera om det finns synliga kontroller såsom knappar, pilar eller länkar som utlöser samma resultat. Försök att använda dessa kontroller med mus, tangentbord (Tab för att fokusera, Enter/Space för att aktivera) och skärmläsare.
4. Verifiering med skärmläsare (NVDA + Firefox): Öppna NVDA och Firefox. Navigera genom de interaktiva komponenterna med Tab- och piltangenterna. Verifiera att kontroller med en enda pekare (knappar, länkar) för gestbaserade funktioner annonseras av skärmläsaren, är nåbara via tangentbordet och ger förväntat resultat när de aktiveras.
5. Verifiering med skärmläsare (VoiceOver + Safari på iOS): Aktivera VoiceOver på en iPhone eller iPad. Svep åt höger med ett finger för att navigera mellan element. Verifiera att alla kontroller som tillhandahåller alternativ med en enda pekare till gester är nåbara och kan aktiveras via VoiceOvers tryckgest, och att de ger korrekt resultat.
6. Verifiering med skärmläsare (JAWS + Chrome): Använd JAWS med Chrome på Windows. Tabba genom interaktiva komponenter och verifiera att kontroller som är alternativ till gester är fokuserbara, korrekt etiketterade och funktionella.
7. Utvärdera undantaget för väsentliga gester: För varje gestberoende funktion som saknar ett alternativ med en enda pekare, avgör om gesten verkligen är väsentlig för innehållet eller funktionaliteten. Om du inte kan motivera undantaget, registrera det som ett fel. Dokumentera dina fynd med skärmdumpar och steg för reproduktion.

Hur man åtgärdar

Bildkarusell med endast svepnavigering — felaktig

<!-- Carousel that only listens for touch swipe events, no button controls -->
<div id='carousel' class='carousel'>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
</div>
<!-- JavaScript only adds touchstart/touchend swipe detection -->
<script>
  // Only gesture-based: no keyboard or click alternative
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
</script>

Bildkarusell med endast svepnavigering — korrekt

<!-- Carousel with both swipe gesture support AND visible single-pointer button controls -->
<div id='carousel' class='carousel' role='region' aria-label='Product images'>
  <button id='prev-btn' aria-label='Previous image' onclick='prevSlide()'>
    &lsaquo; Previous
  </button>
  <div class='slides'>
    <img src='product-1.jpg' alt='Product view 1'>
    <img src='product-2.jpg' alt='Product view 2'>
    <img src='product-3.jpg' alt='Product view 3'>
  </div>
  <button id='next-btn' aria-label='Next image' onclick='nextSlide()'>
    Next &rsaquo;
  </button>
</div>
<!-- Swipe is retained as an enhancement; buttons provide the single-pointer alternative -->
<script>
  carousel.addEventListener('touchstart', handleSwipeStart);
  carousel.addEventListener('touchend', handleSwipeEnd);
  function prevSlide() { /* move to previous slide */ }
  function nextSlide() { /* move to next slide */ }
</script>

Karta med endast nyp-för-att-zooma — felaktig

<!-- Map widget that only responds to two-finger pinch gestures for zoom -->
<div id='map' class='map-widget'></div>
<script>
  // Only multipoint pinch gesture is wired up; no zoom buttons provided
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
</script>

Karta med endast nyp-för-att-zooma — korrekt

<!-- Map widget with pinch-to-zoom PLUS visible zoom controls for single-pointer access -->
<div class='map-container' role='application' aria-label='Interactive map'>
  <div id='map' class='map-widget'></div>
  <div class='map-controls'>
    <!-- Single-pointer alternatives for zoom in and out -->
    <button type='button' aria-label='Zoom in' onclick='mapZoomIn()'>+</button>
    <button type='button' aria-label='Zoom out' onclick='mapZoomOut()'>&minus;</button>
  </div>
</div>
<script>
  map.addEventListener('touchstart', detectPinch);
  map.addEventListener('touchmove', handlePinchZoom);
  function mapZoomIn() { /* increase zoom level by one step */ }
  function mapZoomOut() { /* decrease zoom level by one step */ }
</script>

Intervallreglage med endast dragbana-gest — felaktig

<!-- Custom price range slider that only works by dragging a thumb along a track -->
<div class='price-slider' id='priceSlider'>
  <div class='track'>
    <div class='thumb' id='sliderThumb'></div>
  </div>
</div>
<!-- No keyboard support, no input field, no increment/decrement buttons -->

Intervallreglage med endast dragbana-gest — korrekt

<!-- Use the native <input type='range'> which provides built-in keyboard and single-pointer support -->
<label for='priceRange'>Maximum price: <span id='priceValue'>500</span> TL</label>
<input
  type='range'
  id='priceRange'
  name='priceRange'
  min='0'
  max='1000'
  value='500'
  step='10'
  aria-valuemin='0'
  aria-valuemax='1000'
  aria-valuenow='500'
  aria-label='Maximum price in Turkish lira'
  oninput='document.getElementById("priceValue").textContent = this.value'
>
<!-- Native range input supports click, tap, keyboard arrow keys, and touch drag --
     covering all single-pointer and path-based interaction needs natively -->

Vanliga misstag

• Att tillhandahålla karuseller med endast svep utan några föregående/nästa-knappar: Många karusellbibliotek levereras endast med geststöd; utvecklare måste uttryckligen konfigurera och rendera navigationsknappar för att tillhandahålla ett alternativ med en enda pekare.
• Att dölja navigationsknappar på touchenheter via CSS media queries: Ett vanligt mönster döljer pilknappar på skärmar som antas vara touchenheter (t.ex. @media (pointer: coarse)), vilket tar bort alternativet med en enda pekare för motoriskt funktionsnedsatta användare som är beroende av det även på pekskärmar.
• Att enbart förlita sig på en nypgest med två fingrar för kartzoom utan att erbjuda zoomknappar: Inbäddade tredjepartskartor (anpassade implementationer) utelämnar ofta zoomkontroller, vilket gör nyp till den enda zoommekanismen.
• Att använda svep-för-att-radera eller svep-för-att-avslöja-mönster utan alternativ åtgärdsknapp: Listelement i webbappar som visar radera- eller åtgärdsalternativ endast via ett horisontellt svep har ingen likvärdig mekanism baserad på tryckning för användare som inte kan svepa på ett tillförlitligt sätt.
• Anpassade dra-och-släpp-gränssnitt som saknar alternativ för omordning med tangentbord eller klick: Draginteraktioner är i sin natur banbaserade; att inte tillhandahålla en alternativ mekanism (såsom upp-/ned-knappar eller en klipp-och-klistra-modell) bryter mot detta kriterium.
• Rit- eller signaturwidgets som utgår från att den ritade banan i sig inte är resultatet: Utvecklare åberopar ibland felaktigt undantaget ”väsentlig” för widgets som i själva verket bara är UI-kontroller (t.ex. ett gestupplåsningsmönster för att visa innehåll) snarare än genuina frihandsinmatningsverktyg.
• Att placera alternativa kontroller med en enda pekare utanför den synliga vyn eller i ett kollapsat läge som standard: Om de likvärdiga knapparna finns i DOM:en men är visuellt dolda eller kräver en extra interaktion för att visas, uppfyller de inte fullt ut kravet på ett uppfattbart och användbart alternativ med en enda pekare.
• Att implementera gestbibliotek som fångar upp pekarhändelser och förhindrar standardbeteende: Bibliotek som anropar event.preventDefault() på touchhändelser kan oavsiktligt blockera webbläsarens egna interaktioner med en enda pekare och rullning, vilket skapar oavsiktliga fel utöver själva gestkriteriet.
• Att anta att det räcker att lägga till aria-label på en zon med endast gester: Att märka ett svepområde tillhandahåller inte ett alternativ med en enda pekare — det beskriver bara området för skärmläsaranvändare som fortfarande inte kan använda det utan geststöd.
• Att inte testa på riktiga enheter eller med touchsimulering: Utvecklare som bara testar på stationär dator med mus kan aldrig upptäcka att en funktion uteslutande styrs med gester på mobila enheter, eftersom musklicks-fallbacken råkar fungera på stationär dator men kodvägen som bara gäller touch saknar en klickmotsvarighet.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i den officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webb- och mobiltillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret antar WCAG 2.2 som sin normativa tekniska standard, vilket gör alla framgångskriterier på nivå A — inklusive WCAG 2.5.1 Pointer Gestures — till lagstadgade grundkrav.

Tidslinjen för efterlevnad enligt cirkuläret är uppdelad i nivåer: offentliga institutioner och organ måste uppnå överensstämmelse inom ett år från det att cirkuläret trätt i kraft, medan privata aktörer som omfattas av regleringen har två år på sig att uppnå full efterlevnad. Underlåtenhet att följa reglerna utsätter berörda aktörer för tillsyn och verkställighetsåtgärder från relevanta tillsynsmyndigheter.

De aktörer som omfattas av cirkuläret inkluderar ett brett tvärsnitt av turkiska digitala tjänsteleverantörer. Offentliga institutioner på alla förvaltningsnivåer och deras anslutna organ omfattas. Inom den privata sektorn gäller cirkuläret för e-handelsplattformar och marknadsplatser, banker och finansiella institutioner, privata sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata persontransportföretag och privatskolor som verkar med tillstånd från Ministry of National Education (MoNE).

För dessa organisationer har WCAG 2.5.1 direkta och praktiska konsekvenser. Turkiska e-handelssajter använder ofta geststyrda produktbildgallerier, svepbaserad kategorinavigering och nyp-för-att-zooma-produktvisare — alla dessa måste nu ha alternativ med en enda pekare. Bank- och finansapplikationer som använder gestbaserade autentiseringsmönster eller dragbaserade transaktionsgränssnitt måste granskas och åtgärdas. Vårdsajter med kartbaserade kliniksökare som använder nyp-zoom måste tillhandahålla zoomknappar. Självbetjäningsportaler hos telekombolag med svepdrivna abonnemangsval måste lägga till tryckbaserade kontroller.

Organisationer som är verksamma i Turkiet rekommenderas starkt att omedelbart inkludera WCAG 2.5.1 i sina checklistor för tillgänglighetsgranskning, eftersom de gestinteraktionsmönster som påverkas av detta kriterium är genomgripande i modern responsiv webbdesign och mobil-först-utveckling — men ändå ofta förbises eftersom de verkar fungera korrekt för majoriteten av användare. Att hantera detta kriterium proaktivt som en del av ett WCAG 2.2 nivå A-efterlevnadsprogram är både en rättslig skyldighet enligt presidentdekret 2025/10 och en meningsfull förbättring av digital inkludering för turkiska användare med motoriska funktionsnedsättningar.