WCAG 2.3.3: Animation från interaktioner

Vad den här regeln innebär

WCAG 2.3.3 — Animation från interaktioner är ett kriterium på nivå AAA under principen Hanterbar (Operable). Det kräver att all rörelseanimation som triggas av interaktion kan inaktiveras av användaren, om inte animationen är avgörande för funktionaliteten eller informationen som förmedlas. Kriteriet gäller animationer som initieras av användaråtgärder som att klicka, skrolla, hovra, fokusera eller någon annan form av interaktion — inte animationer som spelas upp automatiskt vid sidladdning (som kan omfattas av andra kriterier såsom 2.2.2 Pause, Stop, Hide).

Nyckelbegreppet här är rörelseanimation. Detta inkluderar parallaxskrollningseffekter, sidövergångsanimationer, element som glider eller zoomar, snurrande indikatorer och all annan rörelse som uppstår som en direkt konsekvens av en användares handling. Det omfattar inte enkla opacitetsövergångar eller färgändringar, eftersom dessa inte innebär rumslig rörelse som kan trigga vestibulära reaktioner. Skillnaden är mellan rörelse genom rummet (som kan orsaka skada) och förändringar i utseende utan rumslig förflyttning (som i allmänhet inte kan det).

För att klara kriteriet krävs att användare har en tillförlitlig mekanism för att stänga av sådana animationer utan att förlora tillgång till samma innehåll eller funktionalitet. Den mest allmänt accepterade tekniken är att respektera operativsystemets prefers-reduced-motion-mediafråga, som återspeglar användarens systeminställning att minska rörelse. Alternativt kan en webbplatsnivå-omkopplare som är tydligt placerad i gränssnittet — till exempel i en inställningspanel eller en tillgänglighetswidget — uppfylla kriteriet, förutsatt att den består mellan sessioner och är lätt att hitta.

Ett väsentligt undantag är snävt: en animation är endast väsentlig om borttagning skulle förändra informationen eller funktionaliteten i grunden, och ingen likvärdig icke-animerad alternativlösning finns. En snurrande laddningsindikator som är den enda visuella signalen om att innehåll hämtas kan kvalificera; en dekorativ parallaxbakgrundsbild som rör sig när användaren skrollar kvalificerar inte, även om den är estetiskt central för designen.

Kriteriet kräver inte att animationer tas bort helt — bara att det finns en mekanism för att inaktivera dem. När mekanismen är aktiverad måste innehållet fortfarande vara fullt tillgängligt, vilket innebär att ett icke-animerat alternativ måste förmedla samma information eller uppnå samma funktion.

Varför det är viktigt

Vestibulära störningar — tillstånd som påverkar innerörat och hjärnan som styr balans och ögonrörelser — påverkar en betydande del av världens befolkning. Enligt Vestibular Disorders Association har cirka 35% av vuxna 40 år och äldre i USA upplevt någon form av vestibulär dysfunktion. Globalt påverkar tillstånd som benign paroxysmal lägesyrsel (BPPV), Ménières sjukdom och vestibulär migrän tiotals miljoner människor. För dessa personer kan rörelse på en skärm utlösa omedelbara fysiska symtom, inklusive yrsel, vertigo, illamående, huvudvärk och i svåra fall tillfällig oförmåga.

Föreställ dig en användare med vestibulär migrän som besöker en webbplats för resebokning. Webbplatsen använder en helsides parallaxskrollningseffekt där hero-bilden rör sig i en annan hastighet än sidans innehåll när användaren skrollar. Inom några sekunder efter att ha börjat skrolla upplever användaren intensiv yrsel och illamående. Hen kan inte slutföra bokningen och måste överge webbplatsen helt — inte på grund av en kognitiv barriär eller en motorisk funktionsnedsättning, utan på grund av en fysisk reaktion på rörelse på skärmen. Detta är den verkliga skada som WCAG 2.3.3 är utformat för att förhindra.

Utöver vestibulära störningar kan rörelseanimationer påverka användare med uppmärksamhetsstörningar negativt, eftersom de upplever ihållande eller utlösta rörelser som distraherande och svåra att ignorera, liksom användare med ångestsyndrom, för vilka oväntad rörelse kan orsaka stress. Personer som återhämtar sig från hjärnskakningar eller traumatiska hjärnskador är också mycket känsliga för visuell rörelse. Även användare utan någon diagnostiserad åkomma kan uppleva tung animation som tröttande under längre sessioner.

Ur ett användbarhets- och affärsperspektiv korrelerar respekterande av preferenser för minskad rörelse med förbättrade uppgiftsavslutningsgrader och sessionslängd bland känsliga användare. Att respektera systemnivåinställningar signalerar också att en produkt är välkonstruerad och lyhörd för användarnas behov, vilket bygger förtroende. För e-handel, där övergivna varukorgar på grund av dålig upplevelse direkt påverkar intäkterna, är borttagning av onödiga animationsbarriärer en konkret kommersiell fördel.

Relaterade Axe-core-regler

WCAG 2.3.3 kräver manuell testning. Ingen axe-core-automatiserad regel motsvarar detta kriterium direkt, och detta är avsiktligt snarare än en förbiseende. Skälen till att automatiserade verktyg inte pålitligt kan upptäcka överträdelser är väsentliga:

• Varför automation inte kan fånga detta: Att upptäcka rörelseanimation kräver förståelse för en sidas visuella rendering över tid som svar på användarinteraktion. Automatiska tillgänglighetsskannrar analyserar statiska eller lätt renderade DOM-ögonblicksbilder; de simulerar inte användarinteraktioner som skrollning eller klick och observerar sedan om CSS-övergångar eller JavaScript-drivna animationer skapar rumslig rörelse. Även om en skanner skulle kunna upptäcka förekomsten av CSS-egenskaper för animation eller transition, kan den inte avgöra om den animationen innebär rumslig förflyttning (som kan trigga vestibulära reaktioner) eller en enkel opacitetsövergång (som inte gör det). Vidare kan skannern inte avgöra om en prefers-reduced-motion-mediafråga är korrekt kopplad för att undertrycka animationen, om en webbplatsnivå-omkopplare finns eller om animationen verkligen är väsentlig. Alla dessa bedömningar kräver en mänsklig testare som kan observera den renderade upplevelsen, interagera med sidan och utvärdera resultatet.
• Vad manuell inspektion ska rikta in sig på: Testare måste identifiera varje CSS-egenskap som skapar rumslig rörelse — inklusive transform: translateX/Y/Z, transform: scale, transform: rotate, top/left/margin-övergångar, animation-keyframes som flyttar element genom rummet — och verifiera att varje sådan är kopplad till en prefers-reduced-motion: reduce-mediafråga eller en användarkontrollerad omkopplare. JavaScript-drivna animationer som använder bibliotek som GSAP, Framer Motion eller anpassade requestAnimationFrame-loopar måste granskas med samma noggrannhet.

Hur man testar

1. Aktivera minskad rörelse på OS-nivå: På macOS, gå till System Settings > Accessibility > Display och aktivera "Reduce Motion". På Windows 11, gå till Settings > Accessibility > Visual Effects och stäng av "Animation effects". På iOS, gå till Settings > Accessibility > Motion och aktivera "Reduce Motion". På Android, gå till Settings > Accessibility > Remove Animations. Detta gör mediafrågan prefers-reduced-motion: reduce aktiv.
2. Kör en automatiserad skanning som baslinje: Öppna axe DevTools eller Lighthouse i Chrome DevTools mot målsidan. Även om inget av verktygen direkt kommer att flagga en WCAG 2.3.3-överträdelse, kan skanningen lyfta fram relaterade problem och bekräftar att testmiljön fungerar. Notera eventuella animationsrelaterade fynd som kontext.
3. Interagera med sidan medan OS Reduce Motion är aktivt: Skrolla sidan långsamt, klicka på interaktiva element som knappar, navigationsomkopplare, dropdowns, karuseller och modaler. Hovra över element. Tabba genom sidan med tangentbordet. Observera om några rumsliga rörelseanimationer fortfarande spelas upp. Om animationer undertrycks är detta ett godkänt resultat för OS-preferensvägen.
4. Inaktivera OS Reduce Motion och testa igen: Med OS Reduce Motion avstängt, upprepa alla interaktioner. Identifiera varje rörelseanimation som triggas av användarinteraktion. Dokumentera var och en med en beskrivning av den utlösande åtgärden och den observerade animationen.
5. Kontrollera om det finns en webbplatsnivå-omkopplare för animation: Om OS Reduce Motion inte respekteras, leta efter en kontroll på webbplatsnivå — vanligtvis i en tillgänglighetswidget, inställningsmeny eller sidfot. Aktivera den och upprepa alla interaktionstester för att bekräfta att rörelse undertrycks.
6. Inspektera CSS och JavaScript för implementering av prefers-reduced-motion: Öppna DevTools, gå till panelen Sources eller Elements och sök efter prefers-reduced-motion i stilmallsfiler. Verifiera att alla identifierade rörelseanimationer är kopplade till denna mediafråga. I Chrome DevTools kan du emulera mediafrågan: öppna fliken Rendering (More Tools > Rendering) och ställ in "Emulate CSS media feature prefers-reduced-motion" på "reduce". Bekräfta att animationer undertrycks utan att starta om webbläsaren.
7. Utvärdera väsentliga undantag: För varje kvarvarande animation när minskad rörelse är aktiv, bedöm om den verkligen är väsentlig — innebär borttagning att information eller funktionalitet som saknar icke-animerad motsvarighet försvinner? Dokumentera din motivering för varje bedömning.
8. Verifiering med skärmläsare (NVDA + Firefox, JAWS + Chrome, VoiceOver + Safari): Skärmläsaranvändare är inte immuna mot vestibulära effekter om de också har delvis syn. Navigera på sidan med enbart tangentbord medan en skärmläsare är aktiv och OS Reduce Motion är aktiverat. Bekräfta att inga animationer triggas av fokus-händelser eller tangentbordsstyrda interaktioner som saknar stöd för minskad rörelse.

Hur man åtgärdar

Parallaxskrollningseffekt — Felaktig

<!-- Background moves at a different rate than content on scroll -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* Creates parallax on scroll */
    height: 100vh;
  }
</style>
<div class='hero'></div>

Parallaxskrollningseffekt — Korrekt

<!-- Parallax is disabled when the user prefers reduced motion -->
<style>
  .hero {
    background-image: url('hero.jpg');
    background-attachment: fixed; /* Parallax by default */
    height: 100vh;
  }

  @media (prefers-reduced-motion: reduce) {
    .hero {
      background-attachment: scroll; /* Static background; no spatial movement */
    }
  }
</style>
<div class='hero'></div>

CSS-transition på interaktivt element — Felaktig

<!-- Button slides and scales on click with no reduced-motion accommodation -->
<style>
  .btn {
    transition: transform 0.4s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }
</style>
<button class='btn'>Submit</button>

CSS-transition på interaktivt element — Korrekt

<!-- Spatial transform is suppressed; a simple opacity shift conveys state without motion -->
<style>
  .btn {
    transition: transform 0.4s ease, opacity 0.2s ease;
  }
  .btn:active {
    transform: scale(0.9) translateY(4px);
  }

  @media (prefers-reduced-motion: reduce) {
    .btn {
      transition: opacity 0.2s ease; /* Only non-spatial change retained */
    }
    .btn:active {
      transform: none; /* No movement */
      opacity: 0.75;   /* State still communicated visually */
    }
  }
</style>
<button class='btn'>Submit</button>

JavaScript-animationsbibliotek (GSAP) — Felaktig

<!-- GSAP tween fires on button click regardless of user motion preference -->
<script>
  document.querySelector('#open-modal').addEventListener('click', () => {
    gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
  });
</script>

JavaScript-animationsbibliotek (GSAP) — Korrekt

<!-- Check matchMedia before triggering spatial animation; fall back to instant display -->
<script>
  const prefersReducedMotion = window.matchMedia('(prefers-reduced-motion: reduce)').matches;

  document.querySelector('#open-modal').addEventListener('click', () => {
    if (prefersReducedMotion) {
      /* Skip spatial movement; just make the modal visible immediately */
      gsap.set('#modal', { opacity: 1, y: 0 });
    } else {
      gsap.fromTo('#modal', { y: 80, opacity: 0 }, { y: 0, opacity: 1, duration: 0.5 });
    }
  });
</script>

Omkopplare för animation på webbplatsnivå (tillgänglighetswidget) — Korrekt mönster

<!-- Persist user preference in localStorage and apply a class to <html> -->
<button id='toggle-motion' aria-pressed='false'>Reduce Motion</button>

<style>
  /* Default: animations active */
  .card { transition: transform 0.3s ease; }
  .card:hover { transform: translateY(-8px); }

  /* When user opts out via widget */
  html.reduce-motion .card {
    transition: none;
  }
  html.reduce-motion .card:hover {
    transform: none;
  }
</style>

<script>
  const btn = document.getElementById('toggle-motion');
  const stored = localStorage.getItem('reduceMotion') === 'true';

  if (stored) {
    document.documentElement.classList.add('reduce-motion');
    btn.setAttribute('aria-pressed', 'true');
  }

  btn.addEventListener('click', () => {
    const isActive = document.documentElement.classList.toggle('reduce-motion');
    btn.setAttribute('aria-pressed', String(isActive));
    localStorage.setItem('reduceMotion', String(isActive));
  });
</script>

Vanliga misstag

• Att bara tillämpa prefers-reduced-motion på CSS-animationer men inte på CSS-transitioner: Både animation-shorthand och transition-egenskapen kan skapa rumslig rörelse. Team skriver ofta en mediafråga för keyframe-animationer och glömmer att transition: transform 0.3s vid hover eller fokus också triggar rörelse som måste kopplas till mediafrågan.
• Att använda prefers-reduced-motion: no-preference som villkor i mediafrågan istället för reduce: Det korrekta mönstret omsluter stilar för minskad upplevelse i @media (prefers-reduced-motion: reduce), inte det omvända. Att kapsla in animationsstilar i @media (prefers-reduced-motion: no-preference) kan fungera men är mer felbenäget och tillämpas ofta felaktigt, vilket lämnar animationer aktiva för användare som inte uttryckligen har ställt in en preferens.
• Att cachelagra resultatet av matchMedia en gång och aldrig kontrollera igen: En användare kan ändra sin OS-inställning medan sidan är öppen. Prenumerera på matchMedia(...).addEventListener('change', handler) så att JavaScript-drivna animationer reagerar på levande ändringar av preferenser utan att kräva omladdning av sidan.
• Att behandla enbart opacitetsövergångar som rörelseanimationer som måste undertryckas: Kriteriet riktar sig specifikt mot rumslig rörelse. Att ta bort opacitetsövergångar när minskad rörelse är aktiv är alltför aggressivt och försämrar användbarheten. Fades som inte flyttar element genom rummet är i allmänhet acceptabla att behålla.
• Att placera animationsomkopplaren djupt i en otillgänglig inställningsmeny: Om en kontroll på webbplatsnivå används istället för (eller utöver) OS-mediafrågan måste den vara lätt att hitta — helst i webbplatsens permanenta sidhuvud, sidfot eller en tillgänglig överläggswidget — inte begravd tre nivåer ner i en användarkontosida som kräver inloggning.
• Att anta att alla animationsbibliotek automatiskt respekterar prefers-reduced-motion: De flesta JavaScript-animationsbibliotek, inklusive GSAP, Anime.js och anpassade requestAnimationFrame-implementationer, respekterar inte mediafrågan automatiskt. Varje programmatisk animation måste individuellt skyddas med en matchMedia-kontroll i JavaScript-lagret.
• Att deklarera en animation som väsentlig utan tillräcklig motivering: Team markerar ibland komplexa dekorativa animationer som väsentliga för att undvika åtgärdsarbete. Det väsentliga undantaget är snävt; en animation är väsentlig endast om den information den förmedlar inte kan uttryckas genom någon statisk eller icke-animerad metod. Laddningssnurror, dekorativ parallax och sidinträdesanimationer kvalificerar nästan aldrig som väsentliga.
• Att inte testa interaktioner utöver klick — särskilt skrollning och hover: Parallaxskrollningseffekter och hover-utlösta transformeringar är bland de vanligaste vestibulära bovarna, men testning begränsas ofta till klickinteraktioner. Omfattande testning måste täcka alla interaktionssätt, inklusive skrollning, hover, fokus, drag och tangentbordsnavigering.
• Att inte bevara webbplatsnivå-omkopplarens inställning mellan sessioner: Om en användare ställer in en webbplatsomkopplare för att minska rörelse och sedan navigerar till en annan sida eller återvänder till webbplatsen nästa dag och inställningen är återställd, har anpassningen i praktiken misslyckats. Preferenser måste lagras i localStorage eller en användarprofil och tillämpas på varje sidladdning.
• Att glömma tredjepartsinbäddningar och widgets: Inbäddade sociala flöden, chattwidgets, kartinbäddningar och annons-skript kan introducera egna rörelseanimationer helt utanför värdwebbplatsens CSS-kontroll. Tredjepartsinnehåll måste granskas och leverantörer måste engageras för att tillhandahålla stöd för minskad rörelse, eller så måste inbäddningarna kapslas in i behållare som undertrycker rörelse via CSS-inneslutningsstrategier där det är möjligt.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i den officiella tidningen (Resmî Gazete) nr 32933 den 21 juni 2025, fastställer bindande krav på digital tillgänglighet för en definierad uppsättning aktörstyper som är verksamma i Turkiet. De omfattade aktörerna inkluderar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och privata vårdinrättningar, telekomoperatörer med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE).

Cirkuläret föreskriver överensstämmelse med WCAG 2.1 på nivå AA som basstandard för digitala tjänster som produceras eller väsentligt uppdateras efter ikraftträdandet. WCAG 2.3.3 — Animation från interaktioner är ett kriterium på nivå AAA och är därför inte ett obligatoriskt krav enligt Presidential Circular 2025/10. Omfattade aktörer är inte juridiskt skyldiga att implementera detta kriterium för att uppnå efterlevnadsstatus enligt turkisk lag.

Att uppnå överensstämmelse på nivå AAA för kriterier som 2.3.3 har dock betydande praktiskt och reputationsmässigt värde för turkiska organisationer. Vestibulära och rörelsekänsliga tillstånd är osynliga funktionsnedsättningar som ofta förbises i tillgänglighetsgranskningar som fokuserar snävt på kompatibilitet med skärmläsare. För sektorer som hälso- och sjukvård (sjukhus och privata hälso-plattformar), där användare kan inkludera patienter med neurologiska tillstånd som ökar rörelsekänsligheten, och för e-handel och resebyråer, där skrollning med hög interaktion och animerade UI-mönster är vanliga, visar implementering av 2.3.3 ett moget, användarcentrerat förhållningssätt till tillgänglighet.

Organisationer som strävar efter frivillig AAA-överensstämmelse — såsom de som söker fördelar i offentliga upphandlingar, inträde på internationella marknader eller branschcertifiering — bör behandla 2.3.3 som ett prioriterat kriterium med tanke på den relativt låga åtgärdskostnaden (en välstrukturerad strategi för prefers-reduced-motion-mediafrågor kan tillämpas systematiskt i ett designsystem) och den direkta fysiska skada som dess frånvaro kan orsaka. Att inkludera en animationskontroll i en tillgänglighetsöverläggswidget, såsom Accsible, gör det möjligt för turkiska organisationer att erbjuda denna anpassning utan att användare behöver hitta sina operativsysteminställningar — vilket gör vägen till minskad rörelse upptäckbar och användbar för den bredast möjliga målgruppen.