WCAG 2.5.7: Dragrörelser

Vad den här regeln innebär

WCAG 2.5.7 — Dragging Movements (nivå AA, introducerad i WCAG 2.2) anger att all funktionalitet som använder en drag-rörelse för att fungera måste kunna utföras genom en enda pekaråtgärd utan dragning, utom när drag-rörelsen är väsentlig för funktionaliteten och ingen alternativ mekanism finns.

En drag-rörelse definieras som en interaktion där pekaren trycks ned, hålls kvar och flyttas till en ny position innan den släpps. Vanliga exempel är: att sortera listobjekt med drag-and-drop, ändra storlek på paneler genom att dra i ett delningshandtag, använda en slider genom att greppa och dra tummen, rita på en canvas och ändra ordning på kanban-kort. Alla dessa mönster måste ha en likvärdig alternativ lösning med en enda pekare — en mekanism som användaren kan aktivera utan att behöva hålla ner pekarknappen medan hen rör sig.

Begränsningen till en enda pekare är viktig. Alternativet behöver inte vara en tangentbordsgenväg; det kan vara ett musklick, en tryckning eller någon annan åtgärd som bara involverar en kontaktpunkt och inte kräver en ihållande rörelse medan den är nedtryckt. Till exempel uppfyller en slider som låter användare klicka direkt på spåret för att hoppa till ett värde kriteriet, eftersom klick på spåret är en åtgärd med en enda pekare utan dragning.

Vad som räknas som godkänt: En dragbar lista som också erbjuder upp-/nedpilar eller en dialog för att flytta till position; en intervall-slider som accepterar klick var som helst på spåret; en panel med ändringsbar storlek som också har ett numeriskt fält eller en dubbelklicka-för-att-kollapsa-funktion; en karta som kan panorera genom att klicka på navigationspilar såväl som genom att dra.

Vad som räknas som underkänt: En sorterbar lista där det enda sättet att ändra ordning på objekt är att dra dem; en delad panel-resizer utan alternativ funktion; en filuppladdning som bara accepterar drag-and-drop utan knapp som reserv; en färgväljare där det enda sättet att välja en nyans är att dra över en gradientremsa utan numeriskt eller textbaserat alternativ.

Officiellt undantag: Kriteriet tillåter uttryckligen gränssnitt som enbart bygger på dragning när dragning är väsentlig — vilket betyder att om man tar bort den skulle aktiviteten fundamentalt förändras eller bli ogiltig. En gest-ritapplikation eller en widget för att fånga signaturer är ett typiskt exempel. Detta undantag är dock avsiktligt snävt; de flesta vardagliga UI-mönster (sliders, sorterbara listor, kolumner med ändringsbar storlek) betraktas inte som scenarier där dragning är väsentlig.

Varför det är viktigt

Motoriska funktionsnedsättningar påverkar en betydande del av världens befolkning. Enligt Världshälsoorganisationen lever över 1,3 miljarder människor världen över — ungefär 16 % av den globala befolkningen — med någon form av funktionsnedsättning, och motoriska eller fysiska funktionsnedsättningar är bland de vanligaste kategorierna. Tillstånd som essentiell tremor, Parkinsons sjukdom, belastningsskador, hemiplegi, ryggmärgsskador och skillnader i extremiteter gör det alla svårt eller omöjligt att hålla en pekarknapp nedtryckt samtidigt som pekaren flyttas med precision.

För en användare med handtremor är det inte bara obekvämt att dra en slider-tumme från ena änden av spåret till den andra — det kan vara helt opålitligt. Pekaren kan glida, dragningen kan avbrytas mitt i, eller den precision som krävs kan helt enkelt överstiga vad händer med tremor kan åstadkomma. Dessa användare förlitar sig ofta på klickbaserade alternativ, tangentbordsnavigering eller switch-styrda hjälpmedel. Om den enda vägen till en funktion är en draggest är hela funktionen i praktiken otillgänglig för dem.

Konkret scenario: Tänk dig en produktsida för e-handel med ett prisintervallfilter implementerat som en dubbelhandtags-intervallslider. En användare med begränsad finmotorik försöker snäva in prisintervallet men kan inte pålitligt dra något av handtagen till målpositionen — pekaren driver iväg, handtaget hoppar till fel värden och frustrationen gör att användaren överger uppgiften. Om samma filter exponerade ett par numeriska textfält bredvid slidern skulle användaren helt enkelt kunna skriva in önskat minimi- och maxpris och skicka. Den enda tillägget förvandlar en otillgänglig funktion till en fullt tillgänglig, till minimal utvecklingskostnad.

Utöver motoriska funktionsnedsättningar gynnas användare på pekskärmar i utmanande miljöer — som håller i ett räcke i kollektivtrafiken, bär handskar eller använder en stylus — av alternativ med en enda pekare. Kognitiv tillgänglighet spelar också en roll: enklare, klickbaserade interaktioner minskar den kognitiva belastningen jämfört med drag-and-drop-operationer som kräver att man förstår en rumslig metafor samtidigt som man upprätthåller fysisk precision.

Ur ett användbarhets- och SEO-perspektiv tenderar det att säkerställa att interaktiva kontroller kan nås via enkla pekaråtgärder att leda till renare komponentarkitektur med bättre semantisk markup, vilket i sin tur förbättrar upptäckbarheten för hjälpmedelstekniker och sökmotorers crawlers.

Relaterade Axe-core-regler

WCAG 2.5.7 är ett kriterium för manuell testning. Vid tidpunkten för detta skrivande innehåller axe-core ingen automatiserad regel som definitivt kan flagga överträdelser av detta kriterium. Anledningen är grundläggande för hur kriteriet fungerar: automatiserade verktyg kan upptäcka att en drag-händelselyssnare finns på ett element, men de kan inte med säkerhet avgöra om ett alternativ utan dragning finns, om det alternativet täcker samma funktionalitet eller om dragningen är väsentlig. Den bedömningen kräver mänsklig utvärdering av interaktionsdesignen.

• Manuell granskning — drag-and-drop-funktioner: Testare måste identifiera varje komponent på sidan som svarar på mousedown/mousemove/mouseup-sekvenser eller motsvarande för touch (touchstart/touchmove/touchend) och verifiera att var och en exponerar en alternativ mekanism som kan användas via en enda pekartryckning utan dragning. Testare bör också kontrollera HTML5-attributet draggable och associerade dragstart/drop-händelselyssnare som signaler på dragberoende funktionalitet.
• Manuell granskning — inspektion av pekarhändelser: Genom att använda webbläsarens DevTools för inspektion av händelselyssnare eller tillgänglighetsgranskningsverktyg som Accessibility Insights for Web (som inkluderar en manuell checklista för 2.5.7) bör testare inspektera komponenter efter pekarhändelsehanterare och bekräfta att komponentens fulla värdeintervall eller möjlighet till ompositionering kan nås utan ihållande pekarrörelse.
• Varför automatisering inte kan fånga detta: En automatiserad skanner kan flagga att ett <div> har en dragstart-lyssnare, men den kan inte veta om ett klick på en närliggande knapp med etiketten "Move up" ger ett alternativ som uppfyller kraven. Detta kräver förståelse av relationen mellan UI-element och deras funktionella likvärdighet — en uppgift som för närvarande ligger bortom kapaciteten hos verktyg för statisk eller runtime-DOM-analys.

Hur man testar

1. Automatiserad skanningsbaslinje: Kör axe DevTools eller Lighthouse mot sidan för att identifiera relaterade problem med pekare eller inmatningssätt. Även om ingen axe-regel mappar direkt till 2.5.7 ger en genomgång av flaggade problem under 2.5.x-regler användbar kontext. Notera alla komponenter som axe flaggar som having otillräckligt tangentbordsstöd, eftersom dessa ofta överlappar med mönster som enbart bygger på dragning.
2. Identifiera alla dragbara komponenter: Öppna Chrome DevTools, gå till panelen Elements och använd fliken Event Listeners för att leta efter dragstart, drag, drop, pointermove, mousemove och touchmove-hanterare. Alternativt kan du söka i sidans källkod efter attributet draggable och efter JavaScript-mönster som .addEventListener('dragstart'. Lista varje komponent som kräver dragning.
3. Testa varje dragbar komponent för alternativ: För varje identifierad komponent, försök att uppnå samma resultat med enbart klick eller tryck med en enda pekare — ingen dragning. För en slider, klicka direkt på spåret vid önskad position. För en sorterbar lista, leta efter flytta-knappar eller alternativ i snabbmenyn. För en panel med ändringsbar storlek, leta efter dubbelklick eller klickbaserade kontroller. Om inget alternativ finns misslyckas kriteriet.
4. Kontroll av tangentbordsnavigering (sekundär signal): Testa alla dragbara komponenter enbart med tangentbord (Tab för att fokusera, piltangenter, Enter/Space). Även om tangentbordsstöd täcks av WCAG 2.1.1 korrelerar förekomsten av robust tangentbordsstöd ofta med existensen av alternativ utan dragning, vilket gör detta till ett användbart bekräftande steg. Använd NVDA + Firefox, VoiceOver + Safari (macOS/iOS) eller JAWS + Chrome och verifiera att komponentens fulla funktionalitet kan användas utan pekdon.
5. Verifiering på pekskärm: På en mobil enhet eller med Chrome DevTools enhetsemulering i touch-läge, försök att utföra samma uppgifter med tryckgester (ingen svep-och-håll). Bekräfta att enstaka tryckningar eller tryck-på-mål-interaktioner är tillräckliga för all funktionalitet.
6. Dokumentera resultat: För varje testad komponent, dokumentera om ett alternativ med en enda pekare som uppfyller kraven finns, om det täcker hela funktionaliteten och om dragoperationen kan anses vara väsentlig. Använd den manuella testlistan i Accessibility Insights for Web för WCAG 2.5.7 som en strukturerad guide.

Hur man åtgärdar

Intervall-slider utan stöd för klick på spår — Felaktig

<!-- Slider that only responds to drag on the thumb;
     clicking the track does nothing -->
<div class='slider-container'>
  <div class='slider-track'>
    <div class='slider-thumb'
         id='priceSlider'
         onmousedown='startDrag(event)'>
    </div>
  </div>
</div>

Intervall-slider med klick på spår och numeriskt fält — Korrekt

<!-- Native <input type='range'> provides drag, click-on-track,
     and keyboard support natively. A numeric input offers an
     additional single-pointer alternative. -->
<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'
       oninput='document.getElementById("priceValue").textContent = this.value;
                document.getElementById("priceNumber").value = this.value;'>
<label for='priceNumber'>Or enter a value:</label>
<input type='number'
       id='priceNumber'
       name='priceNumber'
       min='0'
       max='1000'
       value='500'>

Drag-and-drop-sorterbar lista utan alternativ — Felaktig

<!-- Items can only be reordered by dragging.
     No move buttons or keyboard reordering exist. -->
<ul id='taskList'>
  <li draggable='true' ondragstart='handleDrag(event)' id='item1'>Task One</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item2'>Task Two</li>
  <li draggable='true' ondragstart='handleDrag(event)' id='item3'>Task Three</li>
</ul>

Drag-and-drop-sorterbar lista med flytta-knappar — Korrekt

<!-- Drag-and-drop is preserved for users who can use it.
     Move Up / Move Down buttons provide a single-pointer
     (and keyboard-accessible) alternative for every item. -->
<ul id='taskList' aria-label='Sortable task list'>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item1'>
    <span>Task One</span>
    <button type='button'
            onclick='moveItem("item1", -1)'
            aria-label='Move Task One up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item1", 1)'
            aria-label='Move Task One down'>
      &darr; Move Down
    </button>
  </li>
  <li draggable='true'
      ondragstart='handleDrag(event)'
      id='item2'>
    <span>Task Two</span>
    <button type='button'
            onclick='moveItem("item2", -1)'
            aria-label='Move Task Two up'>
      &uarr; Move Up
    </button>
    <button type='button'
            onclick='moveItem("item2", 1)'
            aria-label='Move Task Two down'>
      &darr; Move Down
    </button>
  </li>
</ul>

Delad panel med ändringsbar storlek utan alternativ — Felaktig

<!-- The divider can only be repositioned by dragging.
     No percentage input or preset-size buttons exist. -->
<div class='split-pane'>
  <div class='pane pane-left' id='leftPane'>Content A</div>
  <div class='divider'
       onmousedown='startResize(event)'
       aria-hidden='true'></div>
  <div class='pane pane-right' id='rightPane'>Content B</div>
</div>

Delad panel med ändringsbar storlek och förvalsknappar — Korrekt

<!-- The divider still supports dragging, but preset-layout
     buttons allow single-pointer repositioning. The divider
     is also keyboard-focusable with arrow-key support. -->
<div class='split-pane-wrapper'>
  <div class='split-controls' role='group' aria-label='Panel size presets'>
    <button type='button' onclick='setSplit(25)'>25 / 75</button>
    <button type='button' onclick='setsplit(50)'>50 / 50</button>
    <button type='button' onclick='setSplit(75)'>75 / 25</button>
  </div>
  <div class='split-pane'>
    <div class='pane pane-left' id='leftPane'>Content A</div>
    <div class='divider'
         role='separator'
         tabindex='0'
         aria-label='Resize panels'
         aria-valuenow='50'
         aria-valuemin='10'
         aria-valuemax='90'
         onmousedown='startResize(event)'
         onkeydown='resizeWithKeys(event)'>
    </div>
    <div class='pane pane-right' id='rightPane'>Content B</div>
  </div>
</div>

Vanliga misstag

• Att implementera sliders som anpassade <div>-baserade komponenter utan stöd för klick på spår, som helt förlitar sig på att dra tum-elementet och inte hanterar click-händelser på själva spårelementet för att hoppa till den klickade positionen.
• Att anta att drag-and-drop-filuppladdning är den enda uppladdningsmekanism som behövs, utan att tillhandahålla en synlig, klickbar filbläddringsknapp (<input type='file'>) som obligatorisk reserv bredvid släppzonen.
• Att tillämpa undantaget för väsentlighet alltför brett — till exempel att behandla en sorterbar att-göra-lista eller en kanban-tavla som "väsentlig dragning" när knappar för Flytta upp/ner fullt ut skulle tillgodose användarnas behov utan någon funktionsförlust.
• Att tillhandahålla tangentbordsalternativ men inte alternativ med en enda pekare, genom att misstolka WCAG 2.5.7 som uppfyllt enbart genom tangentbordsstöd. Kriteriet kräver specifikt en väg med en enda pekare; lösningar enbart med tangentbord adresserar 2.1.1, inte 2.5.7.
• Att gömma flytta-knappar eller numeriska fält bakom hover-tillstånd eller sekundära menyer som i sig kräver draginteraktioner eller komplexa pekarsekvenser för att visas, vilket i praktiken upphäver tillgängligheten hos alternativet.
• Att bortse från pekskärmsenheter genom att bara testa alternativ till dragning med en stationär mus och sedan distribuera till användare på pekskärmar där beteendet för draggester och dess alternativ kan skilja sig avsevärt från desktop-implementationen.
• Att använda pointer-events: none på slider-spåret i CSS för att förhindra oavsiktliga klick under dragning, vilket oavsiktligt blockerar alternativet med klick på spår som 2.5.7 kräver.
• Att inte tillhandahålla ett alternativ för panorerings-/draginteraktioner på kartor i inbäddade kartor eller anpassade canvas-baserade visualiseringar, där klick på riktningspilar eller inmatning av koordinater skulle vara ett tillräckligt alternativ med en enda pekare.
• Att implementera alternativet med en enda pekare som ett drag-and-drop-mål i sig — till exempel att skapa en "släpp här"-zon som fortfarande kräver en dragning för att användas — i stället för en genuint annorlunda interaktionsmodell som en knapp eller ett textfält.
• Att glömma att testa alternativ över hela värdeintervallet för en dragbar komponent. En slider som låter användare klicka på endast några förvalda positioner på spåret, men inte på någon godtycklig position, erbjuder inte ett fullständigt alternativ om dragversionen stöder kontinuerliga värden.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Officiella tidningen nr 32933 den 21 juni 2025, etablerar ett omfattande nationellt ramverk för tillgänglighet för digitala tjänster. Cirkuläret kräver att berörda aktörer följer Web Content Accessibility Guidelines och hänvisar specifikt till nivå AA-konformitet som standard för att erhålla Erişilebilirlik Logosu (Tillgänglighetslogotypen), det officiella certifieringsmärket som utfärdas av Ministeriet för familje- och socialtjänster (Aile ve Sosyal Hizmetler Bakanlığı).

WCAG 2.5.7, som ett kriterium på nivå AA introducerat i WCAG 2.2, faller inom ramen för de krav som är nödvändiga för att erhålla och behålla Tillgänglighetslogotypen. För organisationer som förlitar sig på drag-and-drop-interaktioner — såsom e-handelsplattformar med produktfiltreringssliders eller sorterbara önskelistor, bankapplikationer med portföljhanteringspaneler eller resebyråers bokningsverktyg med datumintervallväljare — skulle bristande efterlevnad av 2.5.7 utgöra ett direkt hinder för certifiering.

De aktörer som omfattas av Presidential Circular 2025/10 inkluderar ett brett tvärsnitt av den turkiska digitala ekonomin: offentliga institutioner och statliga organ på central och lokal nivå; banker och finansiella tjänsteleverantörer som regleras av Banktillsyns- och regleringsmyndigheten (BDDK); e-handelsplattformar som är verksamma i Turkiet; sjukhus och privata vårdgivare; teleoperatörer med 200,000 eller fler abonnenter; resebyråer och privata transportföretag; och privatskolor auktoriserade av Ministeriet för nationell utbildning (Milli Eğitim Bakanlığı — MoNE).

För dessa organisationer är det inte bara en teknisk brist att inte tillhandahålla alternativ med en enda pekare till draginteraktioner — det är ett efterlevnadsgap som kan hindra certifiering, utsätta organisationen för tillsynsgranskning och utestänga en betydande grupp användare med motoriska funktionsnedsättningar. Turkiets funktionshinderstatistik speglar globala trender: miljontals invånare lever med tillstånd som påverkar finmotoriken, och digitala tjänster som enbart förlitar sig på draggester skapar onödiga barriärer för denna befolkning.

I praktiken bör organisationer som eftersträvar Erişilebilirlik Logosu inkludera WCAG 2.5.7 i sina tillgänglighetsgranskningslistor, säkerställa att alla interaktiva komponenter som byggts med dragfunktionalitet granskas för alternativ som uppfyller kraven och dokumentera sina konformitetsbeslut — inklusive eventuella anspråk på undantaget för väsentlighet — som en del av sin Tillgänglighetsförklaring (Erişilebilirlik Beyanı), som cirkuläret kräver att berörda aktörer publicerar och håller aktuell.