WCAG 2.1.1: Tangentbord

Vad Denna Regel Innebär

WCAG 2.1.1 (Tangentbord) kräver att varje funktion på en webbsida eller i en applikation ska kunna användas via ett tangentbordsgränssnitt. Detta innebär att om en användare kan klicka på en knapp, dra ett objekt, hovra för att visa en meny eller interagera med något annat element med en mus, måste de kunna utföra exakt samma åtgärd enbart med tangentbordsinmatning — vanligtvis med tangenterna Tabb, Skift+Tabb, Enter, Mellanslag och piltangenterna.

Kriteriet gäller alla interaktiva element: länkar, knappar, formulärkontroller, anpassade widgets, modala dialoger, rullgardinsmenyer, dragspel, karuseller, datumväljare, dra-och-släpp-gränssnitt, canvas-baserade interaktioner och alla andra komponenter som svarar på användarinmatning. Om innehåll kräver att en användare utför en ritbana (där själva banan är inmatningen, inte bara slutpunkten), är det det enda formellt erkända undantaget i WCAG. Utanför detta snäva undantag måste all annan funktionalitet vara tangentbordsåtkomlig.

Ett godkänt resultat innebär att en användare som endast använder tangentbord kan nå varje interaktivt element via Tabb- eller piltangentsnavigering, aktivera det med Enter eller Mellanslag och slutföra den avsedda åtgärden utan att behöva en mus i något steg. Ett underkänt resultat uppstår när något av följande gäller: ett interaktivt element får ingen fokus alls; fokus erhålls men elementet kan inte aktiveras; en funktion utlöses uteslutande av en mushändelse som onmouseover eller ondblclick utan tangentbordsekvivalent; eller en rullningsbar behållare inte kan nås med tangentbord, vilket fångar innehåll inuti den.

Det är viktigt att skilja WCAG 2.1.1 från WCAG 2.1.2 (Ingen tangentbordsfälla). Kriterium 2.1.1 säkerställer att tangentbordsanvändare kan komma åt och använda allt; kriterium 2.1.2 säkerställer att tangentbordsanvändare aldrig blir fast i en komponent. Båda måste uppfyllas för full överensstämmelse på nivå A.

Varför Det Är Viktigt

Tangentbordsåtkomlighet är inte en nischfråga. Uppskattningsvis 1 av 4 vuxna i USA lever med någon form av funktionsnedsättning, och motoriska funktionsnedsättningar — inklusive tillstånd som Parkinsons sjukdom, multipel skleros, ryggmärgsskador, belastningsskador (RSI), extremitetsskillnader och skakningar — hindrar ofta användare från att använda en standardmus eller pekskärm. Dessa användare är helt beroende av tangentbord, switchkontroller, sug-och-blås-enheter, huvudpekare eller andra hjälpmedel som i slutändan emulerar tangentbordsinmatning på operativsystemnivå.

Blinda och synsvaga användare som förlitar sig på skärmläsare som NVDA, JAWS eller VoiceOver navigerar helt via tangentbordet. Om ett element inte kan nås med tangentbord kommer skärmläsaren aldrig att annonsera det, vilket gör innehållet fullständigt osynligt för den användaren. Enligt Världshälsoorganisationen har minst 2,2 miljarder människor världen över någon form av synnedsättning på nära eller långt håll.

Överväg ett konkret scenario: en användare med avancerad reumatoid artrit i båda händerna besöker en e-handels kassasida. Webbplatsens specialbyggda väljare för betalningsmetod är implementerad som en serie stylade <div>-element som endast svarar på musklick. Användaren kan tabba till behållaren, men inget enskilt alternativ får fokus och att trycka på Enter gör ingenting. De kan inte slutföra köpet. Detta är inte en mindre olägenhet — det är ett fullständigt utestängande från en kommersiell transaktion, och det innebär både en juridisk risk och ett betydande intäktsbortfall för företaget.

Utöver funktionsnedsättning gynnar tangentbordsåtkomlighet avancerade användare som föredrar tangentbordskommandon för snabbhet, användare i företags- eller myndighetsmiljöer där musanvändning är begränsad av policy, och användare med icke-standardiserade inmatningsenheter. Det korrelerar också positivt med rena, semantiska HTML-strukturer som sökmotorer tolkar mer tillförlitligt, vilket bidrar till bättre SEO-prestanda och långsiktig underhållbarhet i kodbasen.

Relaterade Axe-core-regler

• scrollable-region-focusable: Denna regel kontrollerar om ett element som har överflödigt innehåll (dvs. är rullningsbart) kan nås via tangentbord. När en behållare har CSS-egenskaper som overflow: auto eller overflow: scroll kan seende musanvändare rulla den med mushjul eller styrplatta. Tangentbordsanvändare måste däremot kunna tabba in i behållaren eller använda piltangenterna för att rulla den. Regeln flaggar rullningsbara regioner som saknar tabindex-attribut och saknar naturligt fokuserbart barnelement, vilket innebär att en användare som endast använder tangentbord inte skulle ha något sätt att komma åt det överflödiga innehållet. Automatisk detektering är tillförlitlig här eftersom axe kan inspektera de beräknade stilarna och DOM-trädet för att identifiera element med rullningsbart overflow som saknar tangentbordsfokusförmåga.
• server-side-image-map: Denna regel flaggar användningen av serverbaserade bildkartor — HTML-<img>-element med attributet ismap. Serverbaserade bildkartor skickar de råa pixelkoordinaterna för ett musklick till servern för att avgöra vilken länk som aktiverades. Eftersom åtgärden helt beror på pixelkoordinater från en pekarenhet finns det ingen tangentbordsekvivalent mekanism. Till skillnad från klientbaserade bildkartor (som använder <map>- och <area>-element och kan göras tangentbordsåtkomliga) är serverbaserade bildkartor i grunden oförenliga med navigering enbart med tangentbord. Axe flaggar alla <img ismap>-element som ett fel i tangentbordsåtkomlighet. Manuell verifiering bör bekräfta om bildkartan är det enda sättet att komma åt den underliggande navigeringen eller funktionaliteten.

Det är avgörande att förstå att automatiska verktyg som axe-core bara kan fånga en delmängd av fel i tangentbordsåtkomlighet. Många överträdelser kräver manuell testning eftersom de involverar anpassade JavaScript-händelselyssnare, dynamisk fokus­hantering eller komplexa interaktionsmönster som statisk analys inte fullt ut kan utvärdera. Till exempel kan en knapp som implementeras som en <div> med en click-händelselyssnare få fokus via tabindex='0' men misslyckas med att svara på Enter- eller Mellanslagstryckningar — ett fel som axe inte alltid kan upptäcka utan att utföra interaktionen.

Hur Man Testar

1. Automatisk skanning med axe DevTools eller Lighthouse: Installera webbläsartillägget axe DevTools för Chrome eller Firefox. Navigera till sidan som ska testas och kör en fullständig sidskanning. Filtrera resultaten för regler taggade med wcag2a och keyboard. Leta specifikt efter överträdelser av scrollable-region-focusable och server-side-image-map. I Lighthouse (Chrome DevTools) kör du en Accessibility-granskning och går igenom kategorin ”Keyboard”. Observera att dessa verktyg kommer att lyfta fram uppenbara strukturella fel men inte fånga alla problem med anpassade widgets.
2. Manuellt test av tangentbordsnavigering: Koppla bort eller lägg undan musen helt. Börja från webbläsarens adressfält och tryck upprepade gånger på Tabb för att gå framåt genom alla fokuserbara element på sidan. Tryck på Skift+Tabb för att gå bakåt. För varje interaktivt element — länkar, knappar, inmatningsfält, anpassade rullgardinsmenyer, modaler, reglage — verifiera att: (a) det får en synlig fokusindikator; (b) att trycka på Enter eller Mellanslag aktiverar det som förväntat; (c) alla resulterande dialoger eller paneler också kan navigeras och stängas med tangentbord. Använd piltangenterna inuti widgets som implementerar sammansatta mönster (menyer, fliklistor, radiogrupper, listboxar).
3. Skärmläsare + tangentbordstest med NVDA och Firefox: Starta NVDA (gratis, Windows) och öppna Firefox. Använd NVDAs bläddringsläge (piltangenterna) för att läsa igenom sidan och identifiera alla interaktiva element. Växla till fokusläge (Insert+Mellanslag eller automatiskt på formulärfält) för att interagera med kontroller. Verifiera att anpassade widgets annonserar sin roll, sitt tillstånd och sitt namn, och att all funktionalitet kan utföras utan mus. Testa alla rullningsbara behållare genom att försöka tabba in i dem och använda piltangenterna för att rulla.
4. Skärmläsartest med VoiceOver och Safari (macOS/iOS): Aktivera VoiceOver (Kommando+F5 på macOS). Använd VO+Högerpil för att navigera linjärt genom sidan. Använd Tabb för att flytta mellan interaktiva element. Bekräfta att rullningsbara regioner kan nås och att ingen funktionalitet kräver en svepgest eller pekarinteraktion utan ett tangentbordsåtkomligt alternativ.
5. JAWS- och Chrome-test: Med JAWS igång, öppna Chrome och navigera till sidan. Använd JAWS Virtual Cursor för att bläddra i innehållet och Tabb-tangenten för att flytta mellan interaktiva element. Testa särskilt alla anpassade JavaScript-widgets — dragspel, karuseller, modala dialoger, anpassade select-rutor — genom att tabba till dem och försöka använda dem fullt ut via tangentbord. Logga alla element som får fokus men inte kan aktiveras, eller all funktionalitet som endast kan nås via mushovring.
6. Specifikt test för rullningsbara regioner: Identifiera alla behållare på sidan med synliga rullningslister eller som innehåller mer innehåll än deras synliga yta. Försök att tabba in i varje behållare. Om Tabb inte flyttar fokus in i behållaren och det inte finns några fokuserbara barnelement är behållaren sannolikt ett fel i tangentbordsåtkomlighet. Försök att trycka på piltangenterna medan behållaren eller ett närliggande element har fokus för att se om rullning är möjlig.

Hur Man Åtgärdar

Scenario 1: Rullningsbar behållare — Felaktig

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 1: Rullningsbar behållare — Korrekt

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 2: Serverbaserad bildkarta — Felaktig

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Scenario 2: Serverbaserad bildkarta — Korrekt

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Scenario 3: Anpassad widget som endast använder mushändelser — Felaktig

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Scenario 3: Anpassad widget som endast använder mushändelser — Korrekt

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Scenario 4: Endast-hover-rullgardinsmeny — Felaktig

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Scenario 4: Endast-hover-rullgardinsmeny — Korrekt

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Vanliga Misstag

• Att använda onclick som den enda händelsehanteraren på ett icke-nativt element utan att lägga till en motsvarande onkeydown- eller onkeyup-hanterare — musklick utlöser onclick men tangentbordsaktivering på en <div> eller <span> gör det inte.
• Att lägga till tabindex='0' på ett anpassat interaktivt element men glömma att lägga till role='button' (eller lämplig roll), vilket innebär att skärmläsare inte förmedlar elementets syfte till användaren.
• Att bygga rullgardinsnavigering som uteslutande förlitar sig på CSS-pseduklassen :hover utan en JavaScript-styrd tangentbordsväxel, vilket gör undermenyer osynliga och onåbara för tangentbordsanvändare.
• Att implementera dra-och-släpp-gränssnitt — sorteringslistor, kanban-tavlor, zoner för filuppladdning — utan en tangentbordsåtkomlig alternativ mekanism, såsom tangentbordsutlösta flyttkommandon eller en separat omordningskontroll.
• Att skapa rullningsbara behållare (såsom användarvillkorsrutor, chattfönster eller datatabeller inuti behållare med fast höjd) utan tabindex='0', vilket hindrar tangentbordsanvändare från att rulla för att se allt innehåll.
• Att använda <img ismap> för navigationskomponenter som ärvts från äldre kodbaser utan att ersätta dem med klientbaserade bildkartor eller standardnavigeringslänkar.
• Att tillämpa tabindex='-1' på interaktiva element för att ta bort dem från den naturliga tabb-ordningen utan att tillhandahålla en programmatisk fokushanteringsstrategi, vilket resulterar i kontroller som permanent inte kan nås med tangentbord.
• Att utlösa funktionalitet uteslutande på mouseenter-, mouseleave- eller mousemove-händelser (verktygstips, förhandsvisningar, snabbmenyer) utan motsvarande focus-, blur- eller tangentbordshändelsealternativ.
• Att anta att en modal dialog hanterar fokus automatiskt — att inte flytta fokus in i dialogen när den öppnas och att inte återföra fokus till det utlösande elementet när den stängs, vilket lämnar tangentbordsanvändare desorienterade på sidan.
• Att sätta pointer-events: none i CSS på ett element som ska vara tangentbordsåtkomligt, vilket, även om det inte direkt påverkar tangentbordsbeteende, ofta kombineras med JavaScript-mönster som också blockerar tangentbordsinteraktion.

Relation till Turkiets Tillgänglighetsföreskrifter

Turkiets presidentcirkulär 2025/10, publicerat i Officiella tidningen nr 32933 den 21 juni 2025, fastställer obligatoriska krav på webbtillgänglighet i linje med WCAG 2.1 nivå AA. WCAG 2.1.1 (Tangentbord) är ett kriterium på nivå A, vilket placerar det i den högst prioriterade kategorin av krav på efterlevnad. Överensstämmelse på nivå A är den absoluta minimibaslinjen — om en webbplats inte uppfyller kriterierna på nivå A anses den otillgänglig oavsett andra förbättringar som gjorts.

Enligt cirkuläret differentieras tidslinjerna för efterlevnad efter enhetstyp: offentliga institutioner och statliga myndigheter måste uppnå överensstämmelse inom ett år från cirkulärets publiceringsdatum, medan privata sektorsaktörer som omfattas av regleringen har två år på sig att uppfylla kraven.

De enheter som omfattas av presidentcirkulär 2025/10 inkluderar ett brett tvärsnitt av turkiska digitala tjänster: e-handelsplattformar, offentliga institutioner och ministerier, banker och finansiella institutioner, sjukhus och vårdgivare, telekomföretag med 200,000 eller fler abonnenter, licensierade resebyråer, privata transportföretag och privatskolor auktoriserade av Ministry of National Education (MoNE).

För alla dessa enheter innebär underlåtenhet att uppfylla WCAG 2.1.1 att användare som är beroende av tangentbord — inklusive medborgare med motoriska funktionsnedsättningar, äldre användare och skärmläsaranvändare — inte kan komma åt deras centrala digitala tjänster. Detta är en direkt överträdelse av föreskrifterna. I praktiken skulle en e-handelssajt där kassaflödet inte kan slutföras med tangentbord, eller en sjukhusportal för patienter där tidsbokning kräver musinteraktion, stå i strid med cirkulärets krav.

Organisationer som omfattas av cirkuläret bör genomföra en granskning av tangentbordsåtkomlighet som ett första steg i sitt program för tillgänglighetsåtgärder. Eftersom fel enligt WCAG 2.1.1 ofta är arkitektoniska — rotade i valet av HTML-element, mönster för händelsebindning och standardinställningar i komponentramverk — kan åtgärdandet kräva ändringar på kodnivå snarare än enbart konfigurationsjusteringar. Accsible:s overlay-SDK kan hjälpa till att identifiera och åtgärda vanliga brister i tangentbordsåtkomlighet i JavaScript-lagret, men team bör också genomföra strukturella korrigeringar i sin källkod för att uppnå robust, reviderbar överensstämmelse som kommer att uppfylla regulatorisk granskning.