WCAG 2.5.4: Rörelseaktivering

Vad den här regeln innebär

WCAG 2.5.4 — Motion Actuation behandlar ett specifikt men allt vanligare scenario i moderna webbapplikationer: funktionalitet som utlöses av fysisk enhetsrörelse, såsom att skaka en smartphone, luta en enhet eller göra gester framför en kamera. Kriteriet fastställer två parallella krav som båda måste uppfyllas för överensstämmelse.

För det första måste all funktionalitet som kan styras genom enhetsrörelse eller användarrörelse också kunna styras via en komponent i användargränssnittet — vilket innebär en knapp, länk, formulärkontroll eller liknande interaktivt element som inte är beroende av rörelse. Detta säkerställer att personer som inte kan utföra eller inte pålitligt kan utföra fysiska rörelsegester inte utestängs helt från att få tillgång till den funktionaliteten.

För det andra måste användare kunna inaktivera rörelsesvaret så att oavsiktlig eller ofrivillig rörelse inte utlöser oönskade åtgärder. Detta skyddar användare som har skakningar eller andra motoriska tillstånd som orsakar oavsiktliga enhetsrörelser från att ständigt störas av oväntat beteende i applikationen.

Kriteriet gäller två olika typer av rörelse: enhetsrörelse, som upptäcks genom sensorer såsom accelerometrar och gyroskop inbyggda i smartphones och surfplattor (åtkomliga via API:er som DeviceMotionEvent och DeviceOrientationEvent), och användarrörelse, som upptäcks genom kameror eller andra inmatningssensorer som spårar kroppsrörelser eller gester snarare än själva enheten.

En godkänd implementation tillhandahåller all rörelseutlöst funktionalitet via en standardkontroll i användargränssnittet (en knapp, länk eller motsvarande) OCH låter användaren stänga av rörelsedetekteringen om de så önskar. En underkänd implementation ger antingen endast rörelsebaserad åtkomst till en funktion utan alternativ UI-kontroll, eller tillhandahåller ett alternativ men erbjuder inget sätt att inaktivera rörelseutlösaren så att ofrivillig rörelse inte orsakar problem.

WCAG 2.5.4 definierar två viktiga undantag. Rörelsestyrning är undantagen om rörelsen är väsentlig för funktionen och att inaktivera den skulle förändra aktiviteten i grunden — till exempel en stegräknande träningsapplikation där rörelsespårning är det centrala syftet, eller ett spel som uttryckligen är utformat kring lutningsmekanik. Det andra undantaget gäller när rörelsen används för att styra funktionalitet via ett stödd tillgänglighetsgränssnitt, vilket innebär att plattformens egna tillgänglighetsfunktioner hanterar rörelseinteraktionen på ett sätt som användaren självständigt kontrollerar.

Varför det är viktigt

Hinder kopplade till rörelsestyrning påverkar i oproportionerligt hög grad personer med motoriska och rörlighetsnedsättningar, men effekten är bredare än många utvecklare initialt antar. Att förstå vem som påverkas — och hur — hjälper team att prioritera detta kriterium på rätt sätt.

Personer med skakningstillstånd — inklusive essentiell tremor, Parkinsons sjukdom och multipel skleros — kan uppleva konstant eller intermittent ofrivillig rörelse i händer och armar. När de håller en smartphone är deras naturliga skakningar tillräckliga för att upprepade gånger och oväntat utlösa dialogrutor för skaka-för-att-ångra, uppdateringsåtgärder eller andra rörelseaktiverade funktioner. Världshälsoorganisationen uppskattar att cirka 1,3 miljarder människor världen över lever med någon form av betydande funktionsnedsättning, och tillstånd som påverkar finmotoriken är bland de vanligaste i alla åldersgrupper.

Personer med förlamning eller extremitetsskillnader kan använda sina enheter monterade på rullstolar eller stativ, eller använda huvudpekare, ögonstyrning eller brytare för att interagera med sina enheter. Dessa användare kan ofta inte skaka eller luta en enhet alls, vilket gör funktioner som endast bygger på rörelse helt otillgängliga. Om det enda sättet att ångra en textinmatning i en mobil webbapplikation är att skaka enheten, kan en rullstolsanvändare med en monterad telefon helt enkelt inte komma åt den funktionen.

Äldre vuxna är en annan grupp som påverkas i hög grad. Åldersrelaterade tillstånd, inklusive minskad greppstyrka, artrit och essentiell tremor, blir allt vanligare med stigande ålder, vilket innebär att en växande del av befolkningen — som också är alltmer aktiva digitala användare — kan ha svårt med precisa eller avsiktliga rörelsegester.

Överväg ett konkret scenario i verkligheten: en turkisk e-handelssajt lägger till en funktion "skaka för att blanda" som visar användare en slumpmässig produktrekommendation när de skakar sin telefon, vilket gör surfandet mer engagerande. Funktionen är rolig och nyskapande, men det finns ingen motsvarande knapp för att utlösa blandningen och inget sätt att stänga av skakdetekteringen. En användare med Parkinsons sjukdom som besöker den sajten upplever ständiga, okontrollerade blandningsaktiveringar när deras naturliga skakningar utlöser gesten. De kan inte surfa i lugn och ro eftersom sidan hela tiden hoppar till slumpmässiga produkter. Den här användaren är i praktiken utestängd från en normal shoppingupplevelse — och enligt Turkiets tillgänglighetsregler är detta inte bara ett UX-problem utan ett juridiskt efterlevnadsfel.

Utöver tillgång för personer med funktionsnedsättning förbättrar möjligheten att inaktivera eller tillhandahålla alternativ till rörelsefunktioner också upplevelsen för användare i miljöer där enhetsrörelse är opålitlig — i kollektivtrafiken, på kontor eller i vilken miljö som helst där en användare inte fritt kan röra sin enhet.

Relaterade Axe-core-regler

WCAG 2.5.4 kräver manuell testning eftersom automatiserade verktyg inte på ett tillförlitligt sätt kan upptäcka förekomst eller avsaknad av rörelsebaserad funktionalitet genom att enbart analysera statisk HTML och CSS. Rörelsestyrning beror på JavaScript-händelselyssnare och beteende vid körning som automatiska skannrar inte kan inspektera fullt ut. Följande förklarar varför automatisering inte räcker och vad manuell utvärdering måste omfatta.

• Ingen direkt axe-core-automatiserad regel finns för 2.5.4. Axe-core och liknande automatiserade motorer fungerar genom att inspektera DOM, ARIA-attribut och beräknade stilar. De kan inte observera om en sida har registrerat en devicemotion- eller deviceorientation-händelselyssnare, och de kan inte avgöra om en motsvarande UI-kontroll finns för någon rörelseutlöst funktionalitet. En sida kan ha omfattande rörelsebaserad interaktivitet utan några synliga indikatorer i DOM, vilket gör automatiserad upptäckt i grunden opålitlig. Axe-core markerar därför detta kriterium som kräver manuell granskning istället för att försöka med automatiserad upptäckt som skulle ge hög andel falska negativa.
• Manuell inspektion av JavaScript-händelselyssnare krävs. Testare måste använda webbläsarens utvecklarverktyg för att söka efter registreringar av DeviceMotionEvent, DeviceOrientationEvent och kamera-/visions-API:er såsom Shape Detection API. Webbläsarens panel Event Listeners i DevTools kan visa om dessa händelser är kopplade till window- eller document-objektet.
• Funktionell ekvivalens kan inte automatiseras. Även om ett verktyg skulle kunna upptäcka en rörelselyssnare, skulle det inte kunna avgöra om en knapp eller länk någon annanstans i gränssnittet tillhandahåller samma funktionalitet. Bedömning av funktionell ekvivalens kräver en mänsklig testare som förstår applikationens funktioner och kan verifiera att varje rörelseutlöst åtgärd har ett nåbart, fungerande UI-alternativ.
• Möjligheten att inaktivera kan inte automatiseras. Att avgöra om en användare kan stänga av rörelsesvar kräver interaktion med applikationens inställningar eller preferenser — ett beteendetest som automatiserade verktyg inte är utformade för att utföra heltäckande.

Hur man testar

1. Automatiserad skanning som startpunkt: Kör axe DevTools, Lighthouse eller Accsible accessibility checker på sidan. Dessa verktyg kommer inte att automatiskt flagga överträdelser av 2.5.4, men de kan lyfta fram relaterade problem. Notera alla flaggade punkter och gå sedan vidare till manuella steg. Avsaknad av automatiska flaggor betyder inte att sidan klarar 2.5.4.
2. Identifiera rörelseutlöst funktionalitet: Öppna Chrome DevTools och gå till panelen Elements. Sök i sidans JavaScript-källfiler (med fliken Sources och global sökning med Ctrl+Shift+F) efter strängarna devicemotion, deviceorientation, accelerat, gyro och shake. Dokumentera varje hittad förekomst och den associerade funktionaliteten.
3. Verifiera att UI-alternativ finns: För varje del av rörelseutlöst funktionalitet som upptäcktes i föregående steg, försök att utföra samma åtgärd med enbart tangentbordsnavigering och musklick — ingen enhetsrörelse. Navigera genom gränssnittet med Tab, Enter, mellanslag och piltangenter. Om du inte kan hitta en fungerande UI-kontroll som uppnår samma resultat, underkänns kriteriet.
4. Verifiera att rörelse kan inaktiveras: Leta efter en inställningsmeny, preferenspanel, tillgänglighetsinställningar eller en växlingskontroll specifikt för rörelsefunktioner. Försök att inaktivera rörelsestyrning. Om ingen sådan kontroll finns, eller om inaktivering av rörelse också inaktiverar UI-alternativet, underkänns kriteriet.
5. Testning på fysisk enhet: Ladda sidan på en faktisk smartphone eller surfplatta. Rör enheten avsiktligt försiktigt (simulera ofrivillig tremor — små, kontinuerliga rörelser) och observera om funktionalitet utlöses oavsiktligt. Försök sedan samma test efter att ha inaktiverat rörelse via tillgängliga inställningar.
6. Testning med skärmläsare och tangentbord: Använd NVDA med Firefox, VoiceOver med Safari på iOS eller JAWS med Chrome, och navigera på sidan enbart med tangentbordet och skärmläsarkommandon. Bekräfta att all funktionalitet som kan nås via rörelse också kan nås via skärmläsarnavigering, och att kontrollen för att inaktivera rörelse (om den finns) i sig är tangentbordsåtkomlig och korrekt märkt.
7. Enhetssimulering i webbläsarens DevTools: Öppna panelen Sensors i Chrome DevTools (More Tools > Sensors) och använd simuleringskontrollerna för enhetsorientering och accelerometer för att programmässigt utlösa rörelsehändelser. Detta möjliggör testning av rörelseutlöst beteende på skrivbord utan fysisk enhet.

Hur man åtgärdar

Skaka-för-att-uppdatera utan alternativ — felaktigt

<!-- Motion listener attached, but no UI button provided to refresh -->
<script>
  window.addEventListener('devicemotion', function(event) {
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
</script>
<div id='content'>...page content...</div>

Skaka-för-att-uppdatera utan alternativ — korrekt

<!-- Motion alternative: a visible button provides the same refresh action.
     A settings toggle lets users disable the motion trigger entirely. -->
<div id='motion-controls'>
  <button type='button' id='refresh-btn' onclick='refreshContent()'>
    Refresh Content
  </button>
  <label>
    <input type='checkbox' id='disable-motion' onchange='toggleMotion(this.checked)' />
    Disable shake-to-refresh
  </label>
</div>
<div id='content'>...page content...</div>
<script>
  var motionEnabled = true;
  function toggleMotion(disabled) {
    motionEnabled = !disabled;
  }
  window.addEventListener('devicemotion', function(event) {
    if (!motionEnabled) return;
    var acceleration = event.accelerationIncludingGravity;
    if (Math.abs(acceleration.x) > 15 || Math.abs(acceleration.y) > 15) {
      refreshContent();
    }
  });
  function refreshContent() {
    // fetch and update content
  }
</script>

Luta-för-att-rulla-karusell utan möjlighet att inaktivera — felaktigt

<!-- Carousel advances on device tilt; no way to turn this off -->
<div id='carousel'>
  <div class='slide'>Slide 1</div>
  <div class='slide'>Slide 2</div>
  <div class='slide'>Slide 3</div>
</div>
<script>
  window.addEventListener('deviceorientation', function(event) {
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Luta-för-att-rulla-karusell utan möjlighet att inaktivera — korrekt

<!-- Previous/Next buttons provide UI alternatives.
     A settings checkbox lets users opt out of tilt control.
     The carousel is also keyboard accessible via arrow keys. -->
<div id='carousel-wrapper'>
  <button type='button' aria-label='Previous slide' onclick='retreatCarousel()'>&laquo;</button>
  <div id='carousel' role='region' aria-label='Image carousel' aria-live='polite'>
    <div class='slide' aria-hidden='false'>Slide 1</div>
    <div class='slide' aria-hidden='true'>Slide 2</div>
    <div class='slide' aria-hidden='true'>Slide 3</div>
  </div>
  <button type='button' aria-label='Next slide' onclick='advanceCarousel()'>&raquo;</button>
</div>
<label>
  <input type='checkbox' id='disable-tilt' onchange='tiltEnabled = !this.checked' />
  Disable tilt navigation
</label>
<script>
  var tiltEnabled = true;
  window.addEventListener('deviceorientation', function(event) {
    if (!tiltEnabled) return;
    if (event.gamma > 30) advanceCarousel();
    if (event.gamma < -30) retreatCarousel();
  });
</script>

Kameragest-funktion utan alternativ — felaktigt

<!-- User waves hand in front of camera to dismiss a modal;
     no button or keyboard method exists to dismiss it otherwise -->
<div id='modal' role='dialog' aria-modal='true' aria-label='Notification'>
  <p>Wave your hand to dismiss this message.</p>
</div>
<script>
  startCameraGestureDetection(function onWave() {
    document.getElementById('modal').hidden = true;
  });
</script>

Kameragest-funktion utan alternativ — korrekt

<!-- A clearly labeled close button provides the UI alternative.
     The modal is fully keyboard operable and focus is managed correctly. -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Notification</h2>
  <p>Wave your hand or press the button below to dismiss this message.</p>
  <button type='button' id='dismiss-btn' onclick='dismissModal()'>Dismiss</button>
</div>
<script>
  function dismissModal() {
    document.getElementById('modal').hidden = true;
    // return focus to triggering element
  }
  startCameraGestureDetection(dismissModal);
  // Allow Escape key to also dismiss
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') dismissModal();
  });
</script>

Vanliga misstag

• Att tillhandahålla en alternativ knapp i UI men glömma växlingen för att inaktivera rörelse: Många utvecklare lägger till en motsvarande knapp men implementerar aldrig ett sätt att stänga av rörelselyssnaren, vilket gör att användare med skakningar fortfarande upplever oönskade aktiveringar även om funktionen tekniskt sett kan användas på andra sätt.
• Att gömma alternativet för att inaktivera rörelse i en hamburgermeny eller djupt i inställningar: Kontrollen för att inaktivera rörelse måste i sig vara lätt att nå. Om en användare med tremor upprepade gånger utlöser skaka-för-att-uppdatera innan de kan navigera fem menynivåer ner för att inaktivera det, är inaktiveringsalternativet inte praktiskt tillgängligt.
• Att anta att operativsystemets inställning "reduce motion" uppfyller 2.5.4: Mediefrågan prefers-reduced-motion och operativsystemets tillgänglighetsinställningar hanterar animation och vestibulära frågor, men de inaktiverar inte automatiskt enhetsrörelsehändelselyssnare i webbapplikationer. Du måste hantera detta i din egen kod.
• Att sätta rörelsetrösklarna för lågt: Att använda mycket känsliga trösklar för DeviceMotionEvent-accelerationsvärden innebär att små, ofrivilliga skakningar kan passera tröskeln. Trösklar bör kräva avsiktlig rörelse med hög magnitud, och även då krävs ett alternativ för att inaktivera.
• Att registrera rörelselyssnare globalt på window utan att någonsin ta bort dem: Att koppla en lyssnare och aldrig tillhandahålla en kodväg för att ta bort den med removeEventListener innebär att växlingen för att inaktivera bara kan undertrycka beteendet villkorligt — om växlingen i sig misslyckas eller återställs vid sidomladdning förblir rörelsen aktiv.
• Att göra kryssrutan för att inaktivera rörelse otillgänglig: Att implementera växlingen för att inaktivera som ett stylat <div> eller <span> med en klicklyssnare istället för en korrekt <input type='checkbox'> eller ARIA-förbättrad kontroll innebär att tangentbords- och skärmläsaranvändare inte kan nå eller använda just den kontroll som är avsedd att hjälpa dem.
• Att inte spara användarens rörelsepreferenser mellan sessioner: Om en användare inaktiverar rörelsestyrning men preferensen inte sparas (t.ex. via localStorage eller en användarkontoinställning), måste de inaktivera den på nytt vid varje besök, vilket skapar en återkommande börda för de användare som påverkas mest.
• Att tillämpa undantaget för väsentlig funktion alltför brett: Undantaget "väsentlig" är snävt. Ett produktgalleri som använder skaka-för-att-blanda är inte väsentligt — blandningsfunktionen är inte kärnfunktionen på en shoppingsajt. Team missbrukar ibland detta undantag för att undvika implementationsarbete.
• Att inte testa på en verklig fysisk enhet med faktisk rörelse: Att enbart förlita sig på simuleringsverktyg på skrivbord eller automatiska skanningar innebär att verkliga problem med rörelsekänslighet — inklusive hur funktionen beter sig när en användare har en naturlig tremor — aldrig upptäcks förrän användare rapporterar dem.
• Att glömma att rörelsefunktioner som läggs till av tredjeparts-SDK:er eller analysbibliotek också måste följa reglerna: Rörelselyssnare inbäddade i tredjeparts chattwidgetar, spelifierings-SDK:er eller A/B-testverktyg är fortfarande en del av sidans ansvar för överensstämmelse. Om ett tredjepartsskript registrerar en devicemotion-lyssnare utan att tillhandahålla ett alternativ, underkänns sidan enligt 2.5.4.

Relation till Turkiets tillgänglighetsregler

Turkiets Presidential Circular No. 2025/10, publicerad i Official Gazette (nr 32933) den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.2. WCAG 2.5.4 Motion Actuation är ett kriterium på nivå A, vilket innebär att det ligger på den högsta prioritetsnivån för obligatorisk efterlevnad enligt detta cirkulär.

Cirkuläret omfattar ett brett spektrum av offentliga och privata aktörer. Offentliga institutioner — inklusive alla centrala och lokala myndigheter, ministerier och offentliga organ — måste uppnå full överensstämmelse med nivå A inom ett år från cirkulärets publicering. Privata aktörer i omfattade kategorier måste uppnå samma standard inom två år. De omfattade privata kategorierna inkluderar e-handelsplattformar och marknadsplatser, banker och finansiella institutioner, sjukhus och privata vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor som verkar med tillstånd från Ministry of National Education (MoNE).

Rörelsestyrning är särskilt relevant för turkiska digitala tjänster eftersom mobil internetanvändning i Turkiet är mycket hög, med majoriteten av webbtrafiken från smartphones. Mobil-först- och mobil-endast-webbapplikationer är därför mycket vanliga i alla omfattade sektorer. Varje turkisk e-handelssajt, bankapplikation eller myndighetsportal som har implementerat skaka-för-att-uppdatera, lutningsnavigering, gestbaserade interaktioner eller liknande rörelsefunktioner utan att tillhandahålla UI-alternativ och kontroller för att inaktivera dem står i direkt strid med ett obligatoriskt krav på nivå A enligt Presidential Circular 2025/10.

För omfattade aktörer som förbereder efterlevnadsplaner bör rörelsestyrning bedömas som en del av en bredare mobil tillgänglighetsgranskning. Eftersom automatiserade verktyg inte kan upptäcka överträdelser av 2.5.4 bör organisationer inkludera manuell testning av kvalificerade tillgänglighetsspecialister som en del av sin process för att verifiera överensstämmelse. Eftersom cirkuläret inte innehåller någon övergångsperiod för funktioner som implementerades före dess publicering — endast en tidsram för att uppnå överensstämmelse — måste all rörelsebaserad funktionalitet som för närvarande är driftsatt på omfattade sajter åtgärdas inom den tillämpliga tidsfristen.

Aktörer som inte följer cirkulärets krav kan drabbas av administrativa sanktioner och omfattas av tillsyn från relevanta tillsynsmyndigheter för sin sektor. Utöver regulatorisk risk innebär bristande efterlevnad av 2.5.4 på en turkisk mobilsajt med hög trafik ett verkligt användbarhetsfel för miljontals användare som kan ha motoriska funktionsnedsättningar, tremor eller använda hjälpmedel — en befolkning vars behov uttryckligen erkänns och skyddas genom cirkulärets antagande av WCAG 2.2 nivå A som grundläggande standard.