WCAG 3.2.2: Vid inmatning

Vad den här regeln innebär

WCAG 3.2.2 On Input är en del av principen Förståelig och faller under riktlinje 3.2 Förutsägbar. Den anger att ändring av inställningen för en komponent i användargränssnittet inte får orsaka en automatisk kontextförändring, om inte användaren i förväg har informerats om att ett sådant beteende kommer att inträffa.

En kontextförändring är en större förändring i innehållet på en webbsida som kan desorientera användare som inte kan se hela sidan på en gång. Enligt WCAG-specifikationen inkluderar kontextförändringar: byte av användaragent (webbläsare), ändringar av visningsfönster (viewport), ändringar av fokus och innehållsförändringar som väsentligt ändrar sidans betydelse. Att skicka in ett formulär, öppna ett nytt fönster eller navigera till en annan sida är alla exempel på kontextförändringar. Att enbart visa mer innehåll, till exempel genom att expandera en dragspelssektion (accordion), är det inte.

Kriteriet gäller specifikt ändring av inställningen för en UI-komponent — till exempel att välja en alternativknapp (radio button), kryssa i en kryssruta eller välja ett alternativ i en <select>-rullgardinsmeny — till skillnad från att aktivera en kontroll (som att klicka på en knapp). Om en åtgärd kräver ett uttryckligt aktiveringssteg (trycka på Enter, klicka på Skicka) omfattas den i allmänhet inte av detta kriterium. Det problematiska mönstret är när själva handlingen att välja ett värde omedelbart utlöser navigation eller en betydande omladdning av sidan utan någon varning.

Vad som räknas som godkänt: Ett formulär som använder en skicka-knapp för att bearbeta användarens val, även om dessa val inkluderar rullgardinsmenyer eller kryssrutor, uppfyller kriteriet. En rullgardinsmeny som filtrerar resultat på samma sida utan att ladda om eller flytta fokus avsevärt är godkänd. En sida som i förväg informerar användare — till exempel med en synlig notis som "Att välja ett språk kommer att ladda om sidan" — om att en viss inmatning kommer att utlösa en kontextförändring är också godkänd.

Vad som räknas som underkänt: En lands- eller språkväljare som automatiskt omdirigerar användaren till en ny URL i samma ögonblick som ett alternativ väljs är underkänd. Ett formulär som automatiskt skickas in och navigerar bort när en alternativknapp väljs, utan någon skicka-knapp, är underkänt. En autokompletteringskomponent som flyttar tangentbordsfokus till en ny region på sidan utan varning vid val är också underkänd.

Officiella undantag: WCAG-specifikationen anger att om användaren informeras om beteendet innan komponenten används, är den automatiska kontextförändringen acceptabel. Denna information måste finnas innan interaktionen sker, inte efteråt.

Varför det är viktigt

Oväntade kontextförändringar är en av de mest desorienterande upplevelserna på webben, och effekten förstärks dramatiskt för användare med funktionsnedsättningar. När en sida plötsligt navigerar, laddas om eller flyttar fokus utan varning, tappar användare som inte kan se sidans fullständiga visuella layout helt orienteringen.

Skärmläsaranvändare är särskilt utsatta. När en blind användare som använder NVDA eller JAWS väljer ett alternativ i en rullgardinsmeny och sidan omedelbart laddas om eller navigerar, meddelar skärmläsaren den nya sidkontexten från början. Användaren tappar bort var hen var, vad hen gjorde, och måste navigera om hela sidan för att återfå orienteringen. Detta är inte en mindre olägenhet — det kan göra uppgiften helt omöjlig att genomföra självständigt.

Enbart tangentbordsanvändare, inklusive personer med motoriska funktionsnedsättningar som inte kan använda mus, står inför ett liknande problem. De kan navigera i ett formulär med Tab- och piltangenter och av misstag utlösa en kontextförändring som de inte avsåg. Utan finmotorisk kontroll kan det krävas betydande ansträngning att återhämta sig från en oavsiktlig sidnavigering.

Kognitiva funktionsnedsättningar förvärrar problemet ytterligare. Användare med uppmärksamhetsstörningar, inlärningssvårigheter eller minnesnedsättningar är beroende av förutsägbara, stabila gränssnitt för att förstå vad som händer. Plötsliga kontextförändringar bryter den mentala modell de byggt upp under sessionen, vilket ofta tvingar dem att börja om eller överge uppgiften.

Användare med vestibulära störningar kan uppleva fysisk obehagskänsla eller desorientering när sidor ändras oväntat, särskilt om förändringen innebär animation eller skift i rullningsposition.

Ett konkret scenario från verkligheten: tänk på en e-handelskassasida i Turkiet där en användare väljer sin provins från en rullgardinsmeny. Om det valet omedelbart laddar om sidan för att uppdatera fraktalternativ, kan en skärmläsaranvändare plötsligt befinna sig högst upp på sidan utan någon indikation på vad som hände. Hen måste navigera tillbaka genom alla formulärfält för att hitta var hen var, utan att veta om tidigare inmatningar har sparats. Den här typen av friktion kan få användare att helt avbryta köpet.

Ur ett användbarhets- och SEO-perspektiv har sidor som beter sig förutsägbart lägre avvisningsfrekvens (bounce rate). Användare är mindre benägna att lämna i frustration, och sökmotorers crawlers kan mer tillförlitligt indexera innehållet utan att oväntade omdirigeringar stör genomsökningsvägarna.

Relaterade Axe-core-regler

WCAG 3.2.2 On Input kräver manuell testning. Automatiserade verktyg som axe-core kan inte pålitligt upptäcka överträdelser av detta kriterium eftersom det problematiska beteendet är kontextuellt och beror på avsikten bakom en interaktion, inte enbart på förekomsten eller avsaknaden av ett specifikt HTML-attribut eller en viss struktur. Ett verktyg kan identifiera att ett <select>-element har en onchange-händelsehanterare, men det kan inte avgöra om den hanteraren utlöser en kontextförändring, om användaren har varnats om detta eller om det resulterande beteendet i praktiken är desorienterande.

• Manuell testning krävs — onchange-navigationsmönster: Automatiska skannrar kan flagga <select>-, <input type='radio'>- och <input type='checkbox'>-element som har JavaScript-händelsehanterare (särskilt onchange), men de kan inte avgöra om dessa hanterare orsakar en kontextförändring. En mänsklig testare måste interagera med varje sådan kontroll och observera om sidan navigerar, laddas om, flyttar fokus till en dramatiskt annorlunda region eller öppnar ett nytt fönster utan ett uttryckligt aktiveringssteg från användaren.
• Manuell testning krävs — förekomst och tillräcklighet av förhandsvarning: Även om en kontextförändring upptäcks kan ett automatiserat verktyg inte avgöra om användaren var tillräckligt förvarnad om den innan interaktion med kontrollen. En människa måste verifiera att eventuell förhandsinformation är synlig innan komponenten nås, tydligt formulerad och faktiskt beskriver det beteende som kommer att inträffa.
• Manuell testning krävs — fokus­hantering efter inmatning: Vissa överträdelser visar sig som att fokus flyttas till en oväntad plats vid ändring av inmatning snarare än genom ren navigation. Automatiserade verktyg kan inte pålitligt spåra fokusdestinationer som utlöses av onchange-händelser och bekräfta om den resulterande fokusplaceringen utgör en desorienterande kontextförändring.

Hur man testar

1. Automatiserad skanningsbaslinje: Kör axe DevTools eller Lighthouse mot sidan för att identifiera eventuella flaggade problem under WCAG 3.2. Även om 3.2.2 i sig kräver manuell testning kan axe lyfta fram relaterade problem (som saknade etiketter eller fokusproblem) som ger en startpunkt. Notera alla formulärkontroller — särskilt <select>-rullgardinsmenyer, radiogrupper och kryssrutor — för manuell uppföljning.
2. Identifiera alla inmatningskontroller med change-hanterare: Inspektera sidans JavaScript i webbläsarens DevTools eller använd panelen Event Listeners för att identifiera alla <select>-, <input type='radio'>-, <input type='checkbox'>- eller anpassade komponenter som har en onchange-, oninput- eller motsvarande händelselyssnare kopplad.
3. Manuellt tangentbordstest: Använd endast tangentbordet (Tab för att navigera, piltangenter för radio-/select-alternativ) för att interagera med varje identifierad kontroll. Observera om val av ett alternativ får sidan att navigera, laddas om, öppna ett nytt fönster eller flytta fokus till en avsevärt annorlunda del av sidan. Om ja, kontrollera om en synlig varning visades innan kontrollen nåddes.
4. NVDA + Firefox-test: Starta Firefox med NVDA aktivt. Navigera till varje formulärkontroll med NVDA:s virtuella markör (piltangenter) och interagera sedan med formulärläget (Enter eller mellanslag). Välj alternativ i rullgardinsmenyer och radiogrupper och lyssna efter oväntade meddelanden som indikerar sidladdning, navigation eller större kontextförändring. Notera om NVDA läser upp en ny sidtitel eller en dramatiskt annorlunda region.
5. VoiceOver + Safari-test (macOS/iOS): Aktivera VoiceOver och navigera till varje kontroll med VO+högerpil. Interagera med rullgardinsmenyer och kryssrutor. Om en kontextförändring inträffar meddelar VoiceOver vanligtvis den nya sidan eller fokusförflyttningen. Avgör om användaren var förvarnad.
6. JAWS + Chrome-test: Använd JAWS i virtuellt markörläge för att navigera på sidan. Interagera med formulärkontroller och övervaka om JAWS meddelar en kontextförändring (ändrad sidtitel, ny URL, ändrad läsposition) omedelbart vid inmatning — utan att en skicka-knapp aktiverats.
7. Visuell observation: För seende användare utan hjälpmedel, välj alternativ i varje rullgardinsmeny och radiogrupp och observera om sidan navigerar eller laddas om oväntat. Om den gör det, kontrollera om någon instruktionstext som var synlig före kontrollen varnade för detta beteende.

Hur man åtgärdar

Automatiskt inskickande rullgardinsmeny — Felaktig

<!-- BAD: Selecting a country immediately redirects the page -->
<label for='country'>Select Country</label>
<select id='country' name='country' onchange='window.location.href="/region/" + this.value'>
  <option value='tr'>Turkey</option>
  <option value='de'>Germany</option>
  <option value='us'>United States</option>
</select>

Automatiskt inskickande rullgardinsmeny — Korrekt

<!-- GOOD: Selection is confirmed via a submit button; no automatic navigation -->
<form action='/region/' method='get'>
  <label for='country'>Select Country</label>
  <select id='country' name='country'>
    <option value='tr'>Turkey</option>
    <option value='de'>Germany</option>
    <option value='us'>United States</option>
  </select>
  <!-- Explicit submit button gives the user control over when navigation occurs -->
  <button type='submit'>Go</button>
</form>

Automatiskt inskickande radioknappar — Felaktigt

<!-- BAD: Selecting a payment method immediately submits the form -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='this.form.submit()'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='this.form.submit()'>
    Bank Transfer
  </label>
</fieldset>

Automatiskt inskickande radioknappar — Korrekt

<!-- GOOD: onchange can update UI state without navigating; submit requires user action -->
<fieldset>
  <legend>Payment Method</legend>
  <label>
    <input type='radio' name='payment' value='card' onchange='showPaymentDetails(this.value)'>
    Credit Card
  </label>
  <label>
    <input type='radio' name='payment' value='bank' onchange='showPaymentDetails(this.value)'>
    Bank Transfer
  </label>
</fieldset>
<!-- showPaymentDetails() reveals additional fields inline — no context change -->
<div id='payment-details' aria-live='polite'></div>
<button type='submit'>Confirm Payment</button>

Språkväxlare med förhandsvarning — Korrekt

<!-- ACCEPTABLE: User is warned before interacting that selecting will reload the page -->
<p id='lang-notice'>Selecting a language will immediately reload the page.</p>
<label for='lang-select'>Language</label>
<select
  id='lang-select'
  name='lang'
  aria-describedby='lang-notice'
  onchange='window.location.href="/" + this.value + "/"'
>
  <option value='en'>English</option>
  <option value='tr'>Türkçe</option>
  <option value='de'>Deutsch</option>
</select>
<!-- The aria-describedby links the warning to the control for screen reader users -->

Vanliga misstag

• Att koppla window.location.href-tilldelningar direkt till ett <select>-elements onchange-attribut utan en skicka-knapp, vilket orsakar omedelbar sidnavigering i samma ögonblick som användaren väljer ett alternativ.
• Att använda this.form.submit() i en radioknapps onchange-hanterare, vilket skickar in hela formuläret och navigerar bort i samma ögonblick som ett radioalternativ väljs — innan användaren kan granska sina val.
• Att placera förhandsvarningen efter kontrollen i DOM:en så att skärmläsaranvändare och tangentbordsnavigatörer når kontrollen innan de hör eller läser varningen om beteendet den utlöser.
• Att visa förhandsvarningen endast som en tooltip eller platshållartext som inte pålitligt exponeras för hjälpmedel, vilket lämnar skärmläsaranvändare utan någon indikation på att en kontextförändring kommer att följa på deras inmatning.
• Att bygga anpassade rullgardinskomponenter med <div>- och <ul>-element som utlöser navigation vid val via JavaScript men saknar den semantiska struktur som skulle göra det möjligt för testare eller tillgänglighetsöverlägg att identifiera dem som interaktiva kontroller som måste granskas enligt 3.2.2.
• Att utlösa en automatisk formulärinskickning på det sista fältet i ett formulär (till exempel ett PIN- eller engångslösenordsfält) när det erforderliga antalet tecken har uppnåtts, utan att informera användaren om att detta kommer att ske.
• Att öppna en modaldialog eller ett nytt webbläsarfönster som svar på att en kryssruta kryssas i, utan någon förhandsinformation — detta utgör en kontextförändring eftersom det flyttar användarens visningsfönster och fokus avsevärt.
• Att förväxla förutsägbara uppdateringar av innehåll på sidan med kontextförändringar och lägga till onödiga skicka-knappar runt interaktioner som redan är acceptabla (som ett live-sökfilter), vilket kan göra gränssnittet rörigt — team bör förstå att inline-uppdateringar som inte desorienterar inte kräver ett skicka-steg.
• Att enbart förlita sig på automatiska tillgänglighetsskanningar och markera 3.2.2 som godkänd eftersom ingen automatisk regel flaggade den, utan att genomföra den obligatoriska manuella tangentbords- och skärmläsartestning som detta kriterium kräver.
• Att tillämpa en kontextförändrande onchange-hanterare på en <select> som används för sortering eller filtrering i en resultatlista, vilket orsakar en fullständig sidomladdning i stället för en AJAX-uppdatering, och att inte varna användare om att denna omladdning kommer att ske vid val.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet baserade på WCAG 2.2. WCAG 3.2.2 On Input är ett kriterium på Nivå A, vilket representerar den lägsta grundnivån för överensstämmelse enligt cirkuläret — vilket innebär att efterlevnad inte är valfri utan juridiskt krävs för alla berörda aktörer.

Cirkuläret definierar en tvåstegs tidsplan för införande. Offentliga institutioner — inklusive ministerier, kommuner, statliga universitet och myndigheter — måste uppnå full överensstämmelse med Nivå A inom ett år från cirkulärets publicering. Privata aktörer som omfattas av regleringen har ett tvåårigt tidsfönster för att uppfylla kraven.

Följande aktörstyper omfattas uttryckligen av cirkuläret och måste därför säkerställa att deras digitala tjänster följer WCAG 3.2.2: e-handelsplattformar, offentliga institutioner på alla förvaltningsnivåer, banker och finansiella institutioner, sjukhus och vårdgivare, telekommunikationsföretag med 200,000 eller fler abonnenter, auktoriserade resebyråer, privata transportföretag och privatskolor som godkänts av Ministry of National Education (MoNE).

För dessa aktörer utgör en överträdelse av WCAG 3.2.2 — såsom en språkväljare på en bankportal som automatiskt omdirigerar vid val, eller ett sjukhus bokningsformulär som skickas in automatiskt när en avdelningsradioknapp väljs — en direkt regulatorisk bristande efterlevnad. Med tanke på att Turkiet har en betydande befolkning av användare med funktionsnedsättningar, och att offentliga digitala tjänster i allt högre grad är den primära kanalen för medborgare att få tillgång till offentliga tjänster, är de praktiska konsekvenserna av att ignorera detta kriterium betydande.

Organisationer som omfattas av cirkuläret bör behandla testning av WCAG 3.2.2 som ett obligatoriskt revisionssteg under QA. Eftersom automatiska verktyg inte kan upptäcka överträdelser av detta kriterium måste manuell testning av utbildade tillgänglighetsspecialister — som täcker tangentbordsinteraktion, skärmläsarbeteende med NVDA och JAWS samt uttrycklig granskning av alla onchange-styrda interaktioner — byggas in i efterlevnadsprocessen. Det är lämpligt att dokumentera testresultat och eventuella accepterade undantag (med förhandsvarningar på plats) för att visa aktsamhet gentemot tillsynsmyndigheter.