WCAG 3.2.5: Ändring på begäran

Vad denna regel innebär

WCAG 3.2.5 Change on Request är ett kriterium på nivå AAA under principen Begriplig. Det anger att kontextförändringar endast får initieras av användaren, inte utlösas automatiskt av systemet. En ”kontextförändring” definieras i WCAG som en större förändring av innehållet på webbsidan som, utan att användaren är medveten om det, kan desorientera användare som inte kan se hela sidan på en gång. Detta inkluderar förändringar av användaragenten (webbläsaren), visningsområdet (viewport), fokus eller innehåll som väsentligt ändrar sidans betydelse.

Specifikt förbjuder kriteriet alla mekanismer som orsakar en kontextförändring utan en uttrycklig begäran från användaren. Detta utökar kraven i 3.2.1 (On Focus) och 3.2.2 (On Input) genom att ta upp alla återstående scenarier där automatiska kontextförändringar kan inträffa — inklusive men inte begränsat till: sidor som auto-uppdateras, karuseller som auto-avancerar och navigerar bort, meta-redirect-taggar med korta fördröjningar, JavaScript-utlöst navigering vid ifyllnad av formulärfält samt öppning av nya fönster eller flikar utan att användaren initierat det.

För att klara detta kriterium krävs ett av två villkor: antingen utlöses kontextförändringar endast av uttryckliga, avsiktliga användaråtgärder (som att aktivera en knapp eller länk), eller så tillhandahålls en mekanism som gör det möjligt för användaren att stänga av automatiska kontextförändringar innan de inträffar. Om en sida till exempel auto-uppdateras var 30:e sekund och navigerar till nytt innehåll, underkänns den — om det inte finns en tydligt märkt kontroll för att inaktivera detta beteende innan den första uppdateringen sker. Att enbart ge en varning i efterhand är inte tillräckligt.

Kriteriet gäller brett för allt interaktivt och dynamiskt webbinnehåll. Vanliga berörda element och beteenden inkluderar: <meta http-equiv='refresh'>-omdirigeringar, JavaScripts window.location- eller history.pushState-anrop som triggas av timers, onchange-händelsehanterare på <select>-element som navigerar till en ny URL, auto-inskickande formulär, fokusutlöst navigering och alla komponenter som automatiskt rullar, avancerar bilder eller ändrar den synliga innehållsmängden utan användarinmatning.

Ett viktigt officiellt undantag: om kontextförändringen sker som svar på en inställning som användaren uttryckligen och medvetet har konfigurerat — till exempel en användarinställningspanel där användaren väljer ”auto-uppdatera varje minut” — är det automatiska beteendet tillåtet eftersom användaren har begärt det. Den avgörande skillnaden är om användaren gjort ett informerat, avsiktligt val att aktivera det automatiska beteendet, jämfört med att möta det oväntat.

Varför det är viktigt

Oväntade kontextförändringar är bland de mest desorienterande upplevelserna på webben, och deras påverkan varierar avsevärt mellan olika grupper av användare med funktionsnedsättningar.

För blinda användare som förlitar sig på skärmläsare kan en plötslig sidnavigering eller innehållsuppdatering göra att läsmarkören hoppar till en helt annan position på sidan — eller återställs till toppen — utan någon avisering. Om en användare är mitt i en mening i en lång artikel och sidan auto-omdirigeras till en ny URL, tappar hen helt bort sig och kanske inte förstår vad som hände eller hur hen ska återhämta sig. Skärmläsare som NVDA, JAWS och VoiceOver aviserar inte alltid navigeringshändelser på sidnivå på ett konsekvent eller snabbt sätt, så användare kan bli osäkra på var de befinner sig och vad som har ändrats.

För användare med motoriska funktionsnedsättningar som navigerar med tangentbord, huvudpekare, switch-enhet eller ögonstyrning kan oväntade fokusförändringar vara katastrofala. Om fokus flyttas programmatiskt utan användaråtgärd — till exempel när ett formulär auto-avancerar till nästa fält när det föregående fyllts i — kan användaren tappa bort sin position och tvingas mödosamt navigera om för att hitta var systemet har placerat dem. För användare vars inmatningsenheter kräver betydande fysisk ansträngning per tangenttryckning utgör denna om-navigering ett verkligt tillgänglighetshinder.

Användare med kognitiva funktionsnedsättningar, inklusive de med uppmärksamhetsstörningar, minnesnedsättningar eller ångesttillstånd, är särskilt sårbara för oväntade förändringar. Automatiska sidförändringar bryter deras mentala modell av gränssnittet. En användare som pausar för att läsa instruktioner och sedan upptäcker att sidan har laddats om kommer sannolikt att känna sig förvirrad eller stressad. Denna störning kan göra det omöjligt att slutföra transaktioner eller ta till sig information självständigt.

För användare med vestibulära störningar kan snabba och oväntade visuella förändringar — som en auto-avancerande karusell som också triggar navigering — orsaka fysiska symtom som yrsel och illamående. Även seende användare utan diagnostiserad funktionsnedsättning gynnas av förutsägbara gränssnitt: forskning visar konsekvent att oväntade navigeringar ökar felfrekvensen och avhopp från uppgifter i alla användargrupper.

Ett konkret scenario från verkligheten: en turkisk e-handelssajt auto-skickar ett produktfilterformulär i samma ögonblick som en användare väljer ett värde i en dropdown — och navigerar till en ny URL med sökresultat. En användare som endast använder tangentbord och tabbar sig genom filtren för att välja flera kriterier upptäcker att valet av det första alternativet omedelbart laddar om sidan och fäller ihop filterpanelen. Hen måste öppna panelen igen, navigera tillbaka till sin startposition och försöka på nytt — potentiellt i en loop som gör funktionen helt oanvändbar. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor världen över med någon form av funktionsnedsättning, och mönster som detta utestänger dem i oproportionerligt hög grad från digitala tjänster.

Ur ett användbarhets- och SEO-perspektiv tenderar sidor som auto-omdirigerar eller auto-uppdateras också att ha högre avvisningsfrekvens (bounce rate), eftersom användare som möter oväntat beteende ofta lämnar sidan. Sökmotorer kan också bestraffa oväntade omdirigeringar som skiljer sig mellan crawler- och användarsessioner, vilket gör efterlevnad av 3.2.5 förenlig med god teknisk SEO-hygien.

Relaterade Axe-core-regler

WCAG 3.2.5 kräver manuell testning eftersom automatiserade verktyg inte pålitligt kan avgöra om en kontextförändring initierades av användaren eller triggades automatiskt. Skillnaden beror på förståelse av användarens avsikt och interaktionsflöde, vilket kräver mänsklig bedömning. Ingen axe-core-regel motsvarar direkt hela omfattningen av detta kriterium. Följande överväganden gäller dock för automatiserad och semi-automatiserad testning:

• Ingen direkt axe-core-regel (manuell testning krävs): Axe-core och Lighthouse kan inte upptäcka JavaScript-utlösta navigeringar, auto-uppdaterande sidor eller auto-inskickande formulär eftersom dessa beteenden beror på runtime-förhållanden, timing och användarens interaktionstillstånd som statiska eller skriptade skanningar inte kan återskapa. En skanner som observerar DOM vid en enskild tidpunkt kan inte avgöra om window.location.href sätts som svar på en timer eller på ett användarklick.
• Upptäckt av meta refresh (delvis automatisering möjlig): Vissa automatiserade verktyg, inklusive äldre axe-regler och webbläsartillägg, kan flagga förekomsten av <meta http-equiv='refresh' content='0; url=...'> i dokumenthuvudet. Axe-core har dock ingen dedikerad produktionsregel för detta i version 4.10. Manuell inspektion av sidans källkod och HTTP-rubriker krävs för att verifiera att ingen automatisk omdirigering sker.
• Analys av event-lyssnare (manuell): Att upptäcka onchange-hanterare på <select>-element som triggar navigering kräver manuell kodgranskning eller användning av webbläsarens utvecklarverktyg för att inspektera kopplade event-lyssnare. Automatiska skanningar observerar den renderade DOM:en men inte de beteendemässiga konsekvenserna av att interagera med varje element.
• Verifiering av fokus-hantering (manuell): Huruvida fokus flyttas oväntat till följd av en systeminitierad kontextförändring — snarare än en användaråtgärd — kräver att en testare faktiskt interagerar med sidan och observerar fokusbeteendet i realtid, med tangentbord och eventuellt en skärmläsare.

Hur man testar

1. Automatisk skanning (basnivå): Kör axe DevTools eller Lighthouse mot sidan för att fånga eventuella flaggade problem relaterade till omdirigeringar eller fokus-hantering. I Chrome DevTools, öppna Lighthouse-panelen och kör en Accessibility-granskning. I tillägget axe DevTools, klicka på ”Analyze” och granska resultaten. Observera att ett rent automatiskt resultat inte bekräftar efterlevnad av 3.2.5 — manuell testning är avgörande.
2. Inspektera efter meta refresh: Öppna sidan i en webbläsare, högerklicka och välj ”Visa sidkälla” och sök (Ctrl+F / Cmd+F) efter http-equiv eller refresh. Alla <meta http-equiv='refresh'>-taggar med en URL eller med en fördröjning på mer än 72 timmar utan en mekanism för att inaktivera den utgör ett fel.
3. Observera sidans beteende över tid: Ladda sidan och vänta utan att interagera i 2–5 minuter. Titta efter automatiska innehållsförändringar, sidomladdningar, navigeringshändelser eller nya fönster som öppnas. Kontrollera webbläsarens adressfält och flikens titel efter förändringar. Om något inträffar utan din inmatning, misslyckas kriteriet sannolikt.
4. Testa formulärkontroller och dropdowns: Använd endast tangentbordet (Tab, piltangenter, Enter, mellanslag) för att navigera till varje <select>, radioknappsgrupp eller kryssruta. Ändra värden och observera om en navigering eller större innehållsförändring sker omedelbart vid valet — innan du aktiverar en skicka-knapp. Om det gör det är detta ett fel, om inte en kontroll för att inaktivera detta beteende tillhandahölls innan du nådde elementet.
5. Testa med NVDA + Firefox: Aktivera NVDA (Insert+Space för läsläge), navigera på sidan med piltangenter och Tab. Slutför formulärinteraktioner och notera om fokus eller läsposition oväntat flyttas. Lyssna efter aviseringar om sidförändringar. Om skärmläsaren aviserar en ny sida eller om den virtuella markören återställs utan din uttryckliga åtgärd, indikerar detta en kontextförändring.
6. Testa med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver (Cmd+F5 på Mac), navigera med VO+piltangenter. Interagera med kontroller och lyssna efter oväntade sidaviseringar eller marköråterställningar. På iOS, svep genom elementen och notera eventuella plötsliga förändringar i tillgänglighetsträdets struktur som du inte initierat.
7. Testa med JAWS + Chrome: Aktivera JAWS och navigera med Tab och piltangenter. Skicka formulär och interagera med dynamiska komponenter. Verifiera att fokus och den virtuella markörens position förblir förutsägbara och under din kontroll hela tiden.
8. Granska JavaScript-källkod: Använd panelen Sources i Chrome DevTools eller sök (Ctrl+Shift+F) efter mönster som window.location, location.href, history.pushState, setTimeout i kombination med navigeringsanrop och onchange-attribut. Bedöm om något av detta triggas av timers eller systemhändelser snarare än uttryckliga användaråtgärder.
9. Kontrollera auto-avancerande karuseller och sliders: Identifiera eventuella karuseller, bildspel eller roterande banners på sidan. Verifiera om de avancerar automatiskt. Om de gör det, kontrollera om de också triggar navigering (t.ex. länkar till nya sidor) vid auto-avancemang. Auto-avancerande karuseller som endast ändrar synligt innehåll kan omfattas av 2.2.2, men om de också orsakar navigering faller de under 3.2.5.

Hur man åtgärdar

Meta refresh-omdirigering — Felaktig

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Meta refresh-omdirigering — Korrekt

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Select-element som auto-navigerar vid ändring — Felaktig

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Select-element som auto-navigerar vid ändring — Korrekt

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Auto-avancerande karusell som triggar navigering — Felaktig

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Auto-avancerande karusell som triggar navigering — Korrekt

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Vanliga misstag

• Att använda onchange på <select>-element för att omedelbart trigga navigering med window.location.href utan att tillhandahålla en separat skicka-knapp, vilket tvingar tangentbordsanvändare in i en omedelbar sidförändring innan de kan bekräfta sitt val.
• Att implementera <meta http-equiv='refresh' content='30; url=...'> för hantering av sessionstimeout utan att ge användare en mekanism för att förlänga sin session eller inaktivera den automatiska omdirigeringen innan den utlöses.
• Att använda setTimeout eller setInterval för att anropa location.replace() eller history.pushState() för ”bekvämlighetsfunktioner” som auto-sparande med URL-uppdateringar, vilket oväntat flyttar användare till nya historiklägen i webbläsaren.
• Att öppna nya webbläsarfönster eller flikar med window.open() triggat av en timer eller en automatiserad process i stället för av en användargest som ett klick eller en tangenttryckning, vilket många webbläsare kan blockera som popup-fönster och som alltid utgör en oombedd kontextförändring.
• Att auto-skicka ett sök- eller filterformulär med form.submit() inuti en debounce-funktion triggat av oninput på ett textfält — även med en fördröjning — utan att tillhandahålla en synlig skicka-knapp som alternativ kontrollmekanism.
• Att tillhandahålla en kontroll för att ”stänga av auto-avancemang” som bara visas efter att den första automatiska navigeringen redan har inträffat, i stället för före. Opt-out-mekanismen måste vara tillgänglig för användare innan den första kontextförändringen sker.
• Att förväxla innehållsuppdateringar med kontextförändringar: liveområden som uppdaterar text på plats (t.ex. en börsticker) är inte kontextförändringar och är acceptabla, men att automatiskt ersätta hela den synliga sidan eller navigera till en ny URL är en kontextförändring och omfattas av detta kriterium.
• Att anta att det räcker att visa en varningsdialog före automatisk navigering när dialogen i sig triggas automatiskt och fångar tangentbordsfokus. Användaren måste kunna inaktivera beteendet, inte bara bli varnad om det.
• Att använda onblur- eller onfocusout-händelsehanterare för att trigga formulärvalidering och auto-omdirigering till en felsida eller ett annat steg i ett flerstegsformulär, utan att användaren uttryckligen begärt att gå vidare.
• Att implementera routing i single-page-applikationer (SPA) som uppdaterar history.pushState baserat på rullningsdjup eller tid spenderad på en sektion — ett mönster som ibland används för analys — vilket utgör en oinitierad kontextförändring och kan förvirra skärmläsaranvändare vars virtuella buffer är knuten till URL-tillståndet.

Relation till Turkiets tillgänglighetsreglering

Turkiets presidentdekret 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.2 för ett brett spektrum av aktörer verksamma i Turkiet. Dekretet omfattar offentliga institutioner och myndigheter, e-handelsplattformar, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE).

Dekretet föreskriver efterlevnad av WCAG 2.2 nivå AA som basstandard för berörda aktörer. WCAG 3.2.5 Change on Request är ett kriterium på nivå AAA och krävs därför inte direkt enligt dekretets minimikrav i lag. Detta innebär dock inte att det bör avfärdas som irrelevant i turkiskt sammanhang.

Flera kategorier av berörda aktörer har starka praktiska skäl att sträva efter AAA-efterlevnad av 3.2.5. E-handelsplattformar och resebyråer med stora användarbaser implementerar ofta dynamisk filtrering, auto-förslagsnavigering och kampanjkaruseller — just de mönster som mest sannolikt bryter mot detta kriterium. Banker och finansiella tjänsteleverantörer, som hanterar känsliga transaktioner där oväntad navigering kan orsaka fel eller säkerhetsproblem, gynnas i hög grad av att säkerställa att alla kontextförändringar är uttryckligen användarkontrollerade. Vårdsajter, där användare kan befinna sig i utsatta situationer och behöver förutsägbara, lugna gränssnitt, utgör en annan kategori där det är både etiskt och praktiskt motiverat att gå utöver AA-baslinjen med AAA-kriterier som 3.2.5.

Offentliga institutioner som omfattas av gransknings- och rapporteringskrav enligt dekretet bör dokumentera sin efterlevnadsnivå. Även om nivå AAA inte är lagstadgad, ger det att uppnå den — och dokumentera det — ett försvarbart underlag för ett förstklassigt tillgänglighetsåtagande. För aktörer som har användare med funktionsnedsättning som primär eller betydande målgrupp, såsom socialförsäkringsmyndigheten (SGK) eller stödverksamheter för personer med funktionsnedsättning, är strävan efter nivå AAA särskilt förenlig med regleringens anda.

Organisationer som frivilligt uppfyller WCAG 3.2.5 positionerar sig också gynnsamt i sammanhanget av anpassning till Europeiska unionens tillgänglighetskrav, eftersom Turkiets digitala handelsrelationer med EU-medlemsstater i allt högre grad innefattar tillgänglighet som ett kriterium vid upphandling och partnerskap. European Accessibility Act (EAA), som trädde i kraft i juni 2025, gäller produkter och tjänster som erbjuds på EU-marknader — inklusive sådana som tillhandahålls av turkiska företag till europeiska användare — och uppmuntrar starkt användarkontrollerade interaktionsmönster i linje med 3.2.5.

I praktiken bör turkiska utvecklingsteam som implementerar Accsibles overlay-SDK säkerställa att eventuella dynamiskt injicerade widgets, inställningspaneler eller hjälpmedelskontroller inte själva introducerar oinitierade kontextförändringar. SDK:ns verktygsfält och inställningspanel måste öppnas och stängas endast som svar på uttryckliga användaråtgärder, och all navigering eller innehållsuppdatering som triggas via overlayen måste vara användarinitierad. Detta säkerställer att själva tillgänglighetslösningen inte skapar just de hinder den är avsedd att undanröja.