WCAG 2.5.6: Samtidiga inmatningsmekanismer

Vad den här regeln innebär

\n

WCAG 2.5.6 — Concurrent Input Mechanisms är ett framgångskriterium på nivå AAA enligt WCAG 2.2. Dess kärnkrav är enkelt: webbinnehåll får inte begränsa eller störa användarens möjlighet att använda flera inmatningsmekanismer samtidigt eller omväxlande. I praktiken betyder detta att en webbsida eller applikation inte får programmässigt upptäcka vilken inmatningsenhet användaren för närvarande använder och sedan låsa dem till just den modaliteten, och därmed neka dem tillgång till andra tillgängliga inmatningsmetoder.

\n

Moderna enheter stöder en rik variation av inmatningsmekanismer: fysiska tangentbord, möss och styrplattor, pekskärmar, stylusar, switchkontroller, röstinmatning, ögonspårning och mer. Många användare förlitar sig på mer än en av dessa samtidigt — till exempel kan en bärbar dator med pekskärm låta användaren växla smidigt mellan styrplatta och pekgränssnitt med fingret. En avancerad användare kan navigera i ett formulär med tangentbordet samtidigt som hen använder en mus för att rulla. En person med motorisk funktionsnedsättning kan använda en kombination av ett huvudpekarverktyg och en switch-enhet. Kriteriet skyddar alla dessa arbetsflöden.

\n

Ett fel uppstår när en webbplats använder JavaScript för att upptäcka vilken typ av inmatning som används och sedan tar bort eller inaktiverar funktionalitet för andra inmatningstyper. Om en webbplats till exempel upptäcker en touch-händelse och därefter tar bort fokusindikatorer för tangentbord eller inaktiverar tangentbordsnavigering, är det ett direkt brott. På samma sätt utgör det fel att blockera pekarinmatning efter att ha upptäckt tangentbordsanvändning, eller att använda plattforms-API:er för att artificiellt begränsa inmatning till en enda modalitet.

\n

Ett godkänt resultat uppstår när användare kan använda alla tillgängliga inmatningsmekanismer när som helst under sin interaktion. Innehållet ska svara korrekt på vilken inmatningsmekanism användaren än väljer att använda vid varje givet tillfälle utan att kräva en sidomladdning, ett lägesbyte eller någon ytterligare användaråtgärd för att återaktivera en inmatningstyp.

\n

Kriteriet innehåller ett officiellt undantag definierat i WCAG: begränsningen är tillåten när den är väsentlig — det vill säga när en specifik inmatningsmodalitet är inneboende nödvändig. Ett klassiskt exempel är en handskriftsigenkänningsapplikation där touch- eller stylusinmatning är själva poängen med funktionaliteten. Ett annat exempel kan vara ett fält för digital signatur som kräver en specifik pekarinmatning. Även i dessa fall bör undantaget tolkas snävt och författaren bör tillhandahålla alternativa sätt att utföra uppgiften där det är möjligt.

\n

Det är viktigt att notera att detta kriterium inte kräver att författare lägger till stöd för inmatningsmekanismer som enheten inte har. Det reglerar begränsningar som läggs på mekanismer som enheten och plattformen redan stöder. Om en enhet saknar pekskärm finns det inget att begränsa.

\n\n

Varför det är viktigt

\n

Friheten att använda samtidiga eller utbytbara inmatningsmekanismer är inte en bekvämlighetsfunktion — det är ett kritiskt tillgänglighetskrav som direkt påverkar flera olika grupper av användare.

\n

Användare med motoriska funktionsnedsättningar förlitar sig ofta på hjälpmedel som kombinerar flera inmatningsmekanismer. En person med begränsad handrörlighet kan använda en sip-and-puff-switch-enhet tillsammans med ett skärmtangentbord. Någon med tremor kan börja navigera på en sida med tangentbordet men växla till mus eller pekgränssnitt när en tangentbordsgenväg misslyckas. Om en webbplats upptäcker en inmatningstyp och inaktiverar andra kan dessa användare bli helt utestängda från innehåll eller funktionalitet.

\n

Användare med kognitiva eller inlärningssvårigheter drar ofta nytta av möjligheten att välja den inmatningsmetod som känns mest bekväm eller naturlig för en given uppgift. Att tvinga fram en enda modalitet tar bort det valet och kan skapa onödig kognitiv belastning, särskilt när en användare inte är skicklig med enhetens primära inmatningsmetod.

\n

Äldre vuxna, som kan ha åldersrelaterade motoriska utmaningar, använder i allt högre grad enheter som stöder både touch- och tangentbordsinmatning. Möjligheten att växla mellan dessa mekanismer när finmotoriken varierar under dagen är viktig för att kunna använda webben självständigt över tid.

\n

Avancerade användare och multimodala enhetsanvändare — såsom Surface Pro- eller iPad Pro-användare — använder regelbundet tangentbord, stylus och pekgränssnitt på samma enhet i samma session. En webbplats som upptäcker touch-inmatning och tar bort tangentbordsgenvägar, eller tvärtom, försämrar upplevelsen för en enorm användarbas som kanske inte identifierar sig som personer med funktionsnedsättning.

\n

Fundera på detta verkliga scenario: En turkisk banks onlineportal upptäcker att en kund använder en pekskärmsplatta och växlar till ett ”mobil-läge” som inaktiverar tangentbordsnavigering. En kund med motorisk funktionsnedsättning som använder plattan med ett Bluetooth-tangentbord kan nu inte tabba genom formulärfält, navigera i menyer med piltangenter eller använda tangentbordsgenvägar. Hen kan inte utföra sina bankärenden självständigt. Detta är inte bara ett tillgänglighetsfel utan också en potentiell juridisk risk enligt turkiska tillgänglighetsregler.

\n

Ur ett användbarhets- och SEO-perspektiv korrelerar respekt för samtidiga inmatningsmekanismer med bättre Core Web Vitals-poäng, lägre avvisningsfrekvens och högre användarnöjdhet över olika enhetskategorier — alla signaler som sökmotorer belönar.

\n\n

Relaterade Axe-core-regler

\n

WCAG 2.5.6 kräver manuell testning — det finns ingen automatiserad axe-core-regel som pålitligt kan upptäcka alla överträdelser av detta kriterium. Anledningen är grundläggande: automatiserade verktyg kan inspektera den statiska DOM:en och CSS, och de kan upptäcka vissa JavaScript-mönster, men de kan inte fullt ut observera körningstiden för händelselyssnare när de svarar på olika inmatningsmodaliteter under en faktisk användarsession. Beslutet att begränsa en inmatningsmekanism är ofta inbäddat i applikationslogik som bara körs som svar på specifika händelser, vilket gör statisk analys otillräcklig.

\n

\n
• Ingen dedikerad automatiserad axe-core-regel finns för 2.5.6. Axe-core levererar ingen regel som specifikt kontrollerar begränsningar av samtidiga inmatningsmekanismer, eftersom överträdelsen visar sig som dynamiskt JavaScript-beteende snarare än ett strukturellt HTML- eller ARIA-problem. En sida kan klara alla automatiserade axe-kontroller och ändå bryta mot 2.5.6 om dess händelsehanterare programmässigt tar bort eller inaktiverar inmatningsmodaliteter vid körning.
\n
• Pekarhändelser och upptäckt av touch-händelser: Även om axe-core inte kan fånga själva begränsningen bör manuella granskare leta efter JavaScript som lyssnar på touchstart- eller pointerdown-händelser och sedan modifierar DOM:en, tar bort fokus­hantering eller sätter flaggor som ändrar tangentbordsbeteende. På samma sätt är keydown-lyssnare som utlöser CSS-klassändringar som döljer touch-mål varningssignaler att granska manuellt.
\n
• Varför automatisering inte räcker: Automatiska skannrar analyserar dokumentet vid en viss tidpunkt. Begränsningar av inmatningsmekanismer är villkorliga — de aktiveras först efter att en specifik inmatningshändelse har inträffat. En skanner som körs före användarinteraktion kan inte se att en touchstart-hanterare senare kommer att anropa document.querySelectorAll('[tabindex]').forEach(el => el.setAttribute('tabindex', '-1')) och i praktiken förstöra tangentbordsnavigeringen. Endast en mänsklig testare som använder båda inmatningsmodaliteterna i följd kan upptäcka detta fel.
\n

\n\n

Hur man testar

\n

\n
1. Automatiserad grundskanning: Kör axe DevTools eller Lighthouse på sidan för att etablera en baslinje och fånga eventuella samtidigt förekommande problem. Även om inget av verktygen har en dedikerad 2.5.6-regel kan axe DevTools best practice-kontroller flagga tangentbordsfällor eller fokus­hanteringsproblem som är symtom på inmatningsbegränsning. Notera alla fel för åtgärd tillsammans med de manuella kontrollerna nedan.
\n
2. Inspektera JavaScript-källkod och händelselyssnare: Öppna Chrome DevTools, gå till fliken Elements och använd panelen Event Listeners för att inspektera om touchstart-, pointerdown-, pointermove- eller MSPointerDown-lyssnare är kopplade till dokumentet eller body. Sök i sidans JavaScript-källkod i Console efter mönster som ontouchstart in window, navigator.maxTouchPoints eller 'pointer' in navigator i kombination med DOM-modifieringar. Detta är vanliga tekniker som används för att upptäcka inmatningsmodalitet och styra funktionalitet.
\n
3. Test av multimodal interaktion (tangentbord + touch): På en enhet som stöder både touch- och tangentbordsinmatning (t.ex. en Surface, en iPad med tangentbord eller en bärbar dator med pekskärm), börja med att navigera på sidan enbart med tangentbordet (Tab, Shift+Tab, Enter, Space, piltangenter). Notera vilka interaktiva element som är nåbara och fungerar. Växla sedan, utan att ladda om sidan, till touch-navigering — tryck på länkar, knappar och formulärkontroller. Verifiera att all funktionalitet som är tillgänglig via tangentbordet förblir tillgänglig via touch och vice versa. Dokumentera alla element som blir onåbara eller slutar fungera efter växling.
\n
4. Test av kombinerad inmatning med skärmläsare: Använd NVDA med Firefox och navigera på sidan med tangentbordet för att aktivera skärmläsarläge. Använd sedan pekskärmen (om tillgänglig) för att försöka interagera med samma element. Bekräfta att skärmläsaren och sidan svarar korrekt på båda inmatningarna. Upprepa med VoiceOver i Safari på en iPad, med både touch-gester och ett parkopplat Bluetooth-tangentbord. Med JAWS i Chrome, verifiera att växling mellan tangentbord och mus inte bryter fokus­hanteringen eller gör interaktiva element obrukbara.
\n
5. Kodgranskning för mönster som låser modalitet: Granska manuellt alla JavaScript-bibliotek eller ramverk som används på sidan för inbyggd modalitetsdetektion. Vissa UI-bibliotek, särskilt äldre mobil-först-ramverk, innehåller kod som inaktiverar mus- eller tangentbordshändelser på enheter där touch upptäcks. Kontrollera bibliotekets dokumentation och källkod för sådant beteende och verifiera att det har åsidosatts eller inaktiverats.
\n
6. Testa om efter dynamiska interaktioner: Utför åtgärder som utlöser betydande DOM-förändringar — öppna modaler, navigera mellan rutter i single-page-appar, skicka formulär — och kör om multimodalitetstestet efter varje övergång. Begränsningar införs ibland endast i specifika applikationstillstånd.
\n

\n\n

Hur man åtgärdar

\n

Upptäcka touch för att inaktivera tangentbordsnavigering — Felaktigt

\n

<!-- JavaScript upptäcker touch och tar bort alla tabindex-värden,\n     vilket bryter tangentbordsnavigering för användare som växlar inmatningsläge -->\n<script>\n  window.addEventListener('touchstart', function() {\n    document.querySelectorAll('a, button, input, [tabindex]').forEach(function(el) {\n      el.setAttribute('tabindex', '-1');\n    });\n  }, { once: true });\n</script>

\n

Upptäcka touch för att inaktivera tangentbordsnavigering — Korrekt

\n

<!-- Begränsa inte tangentbordstillgänglighet baserat på touch-detektering.\n     Tillåt båda inmatningsmodaliteterna att fungera samtidigt.\n     Om du behöver hantera fokusstilar av estetiska skäl, använd\n     :focus-visible CSS-pseudoklassen istället för att ta bort tabindex. -->\n<style>\n  /* Visa fokusramar endast för tangentbordsnavigering, inte musklick,\n     utan att ta bort tangentbordstillgång helt */\n  :focus:not(:focus-visible) {\n    outline: none;\n  }\n  :focus-visible {\n    outline: 3px solid #005fcc;\n    outline-offset: 2px;\n  }\n</style>\n<!-- Ingen JavaScript-detektering av modalitet behövs -->

\n\n

Pekarhändelse används för att undertrycka tangentbordshändelser — Felaktigt

\n

<!-- En anpassad slider som, efter att ha fått pekarinmatning, slutar\n     svara på piltangenter på tangentbordet och låser användaren till\n     enbart pekarinteraktion -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var pointerUsed = false;\n  slider.addEventListener('pointerdown', function() {\n    pointerUsed = true;\n  });\n  slider.addEventListener('keydown', function(e) {\n    if (pointerUsed) return; // tangentbord inaktiverat efter pekarinteraktion\n    if (e.key === 'ArrowRight') { /* öka */ }\n    if (e.key === 'ArrowLeft') { /* minska */ }\n  });\n</script>

\n

Pekarhändelse används för att undertrycka tangentbordshändelser — Korrekt

\n

<!-- Både pekar- och tangentbordsinteraktioner hanteras oberoende.\n     Ingen flagga sätts som hindrar en modalitet från att fungera efter\n     att den andra har använts. -->\n<div id='slider' role='slider' aria-valuenow='50' aria-valuemin='0'\n     aria-valuemax='100' tabindex='0'></div>\n<script>\n  var slider = document.getElementById('slider');\n  var value = 50;\n\n  function updateSlider(newValue) {\n    value = Math.max(0, Math.min(100, newValue));\n    slider.setAttribute('aria-valuenow', value);\n  }\n\n  // Pekarhanterare — alltid aktiv\n  slider.addEventListener('pointermove', function(e) {\n    if (e.buttons === 1) {\n      // beräkna nytt värde från pekarens position\n    }\n  });\n\n  // Tangentbordshanterare — alltid aktiv, inaktiveras inte av pekaranvändning\n  slider.addEventListener('keydown', function(e) {\n    if (e.key === 'ArrowRight') updateSlider(value + 1);\n    if (e.key === 'ArrowLeft') updateSlider(value - 1);\n  });\n</script>

\n\n

Mobilt ramverk som automatiskt inaktiverar mushändelser — Felaktigt

\n\n

(Content truncated due to token limit — please retry this article.)