WCAG 2.1.3: Tangentbord (utan undantag)

Vad den här regeln innebär

WCAG 2.1.3 — Keyboard (No Exception) är ett framgångskriterium på nivå AAA enligt WCAG 2.1 och 2.2 som utökar WCAG 2.1.1 (Keyboard, nivå A) genom att ta bort alla undantag. Mer specifikt säger den: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes. Den avgörande skillnaden från 2.1.1 är avsaknaden av undantagsklausulen som undantar funktionalitet där den underliggande funktionen kräver inmatning som beror på användarens rörelsebana, inte bara slutpunkterna.

Enligt 2.1.1 kan utvecklare legitimt undanta funktioner som frihandsritningsytor, gestbaserade målarverktyg eller draggränssnitt som är känsliga för rörelsebanor från tangentbordsstöd, eftersom användarens exakta pekarbana avgör resultatet. WCAG 2.1.3 eliminerar detta undantag helt. Enligt detta kriterium måste varenda funktion—inklusive ritning, dragning, banberoende gester och alla interaktioner som historiskt har förlitat sig på pekarrörelser—vara tillgänglig via tangentbord. Detta innebär att utvecklare måste tillhandahålla alternativa tangentbordsmekanismer (till exempel ett tillgängligt verktygsfält med formverktyg, tangentbordsstyrda ritlägen eller formulärbaserade inmatningsalternativ) även för frihands- eller banberoende uppgifter.

Ett godkänt resultat kräver att varje åtgärd på sidan kan initieras, navigeras och slutföras med enbart tangentbordet. Detta inkluderar fokus­hantering, modala dialoger, drag-och-släpp-omordning, anpassade reglage, ritverktyg på canvas, kartinteraktioner, karusellnavigering och videouppspelningskontroller. Det får inte finnas någon tangentbordsfälla (också täckt av 2.1.2), ingen funktion som endast kan triggas genom att klicka, hovra eller använda touchbaserade gester utan en motsvarande tangentbordsväg, och inget beroende av muspekarens rörelsebanor.

Ett underkänt resultat uppstår när någon funktionalitet—oavsett hur nischad eller sekundär den kan verka—inte kan nås eller slutföras enbart via tangentbord. Eftersom detta kriterium inte har några undantag innebär även en enda funktion som inte är tangentbordstillgänglig ett fullständigt misslyckande, vilket gör det till en av de mest krävande standarderna i WCAG.

Varför det är viktigt

Tangentbordstillgänglighet är grundläggande för användare med motoriska funktionsnedsättningar som inte kan använda en pek­enhet. Personer med tillstånd som Parkinsons sjukdom, tetraplegi, cerebral pares, belastningsskador eller skillnader i extremiteter förlitar sig ofta uteslutande på ett fysiskt tangentbord, en switch-enhet, en sip-and-puff-kontroll eller ögonstyrningsteknik som emulerar tangentbordsinmatning. Enligt Världshälsoorganisationen lever cirka 1,3 miljarder människor världen över med någon form av betydande funktionsnedsättning, och motoriska eller fysiska funktionsnedsättningar utgör en betydande del av den populationen. Enbart i Turkiet visar data från Turkish Statistical Institute (TÜİK) att över 8,5 miljoner människor rapporterar minst en form av funktionsbegränsning.

Utöver motoriska funktionsnedsättningar gynnas blinda och synsvaga användare av tangentbordstillgänglighet, eftersom de navigerar med skärmläsare som NVDA, JAWS eller VoiceOver—som alla förlitar sig på tangentbordskommandon för att ta sig igenom och interagera med webbinnehåll. Användare med ljuskänsliga tillstånd kan undvika pekskärmar, och användare med kognitiva funktionsnedsättningar drar ofta nytta av den förutsägbara, linjära navigering som tangentbordsinteraktion ger.

Överväg ett konkret scenario i verkligheten: en grafisk designplattform som erbjuder ett frihands vektorritverktyg. Enligt WCAG 2.1.1 skulle detta kunna undantas eftersom pekarens bana definierar formen. Enligt WCAG 2.1.3 måste plattformen tillhandahålla ett alternativ—kanske ett formbibliotek, en serie tangentbordsstyrda ankarpunkter eller en textbaserad SVG-path-editor—så att en användare med motorisk funktionsnedsättning fortfarande kan skapa vektorgrafik utan mus. Att inte göra detta stänger ute en betydande grupp kreativa yrkespersoner som är beroende av tangentbords­åtkomst.

Ur ett användbarhets- och SEO-perspektiv har gränssnitt som är korrekt tangentbordstillgängliga vanligtvis renare fokushantering, mer logisk tabb-ordning och välstrukturerade DOM-hierarkier—allt detta bidrar till bättre crawlbarhet och en högre kvalitet på användarupplevelsen för alla, inklusive avancerade användare som föredrar tangentbordsgenvägar för snabbhet.

Relaterade Axe-core-regler

WCAG 2.1.3 kräver manuell testning. Till skillnad från många WCAG-kriterier kan automatiserade verktyg inte pålitligt upptäcka överträdelser av detta kriterium eftersom:

• Detektering av banberoende funktionalitet ligger bortom statisk analys: Axe-core och Lighthouse inspekterar DOM:en efter strukturella mönster—saknad tabindex, frånvarande role-attribut eller bruten fokushantering—men de kan inte simulera en användare som försöker utföra varje funktion på en sida och avgöra om ett tangentbordsalternativ finns. Ett canvas-element kan finnas i DOM:en utan ARIA-attribut, men ett tillgängligt tangentbordsverktygsfält i närheten kan ändå helt uppfylla 2.1.3. Omvänt kan en till synes normal knapp trigga en JavaScript-åtgärd som i sig startar en widget som endast fungerar med mus, vilket automatiserade verktyg aldrig skulle flagga. Den logiska likvärdigheten mellan tangentbordsalternativ och musdrivna vägar kräver mänsklig bedömning.
• Ingen dedikerad axe-core-regel motsvarar 2.1.3: De närmaste axe-reglerna—såsom scrollable-region-focusable (som kontrollerar om rullningsbara innehållsregioner kan få tangentbordsfokus) och tabindex (som flaggar positiva tabindex-värden som stör den naturliga fokusordningen)—tar upp relaterade men snävare frågor under 2.1.1 och 2.4.3. De utvärderar inte och kan inte utvärdera om all funktionalitet, inklusive ban-känsliga operationer, har en tangentbordsekvivalent.
• Granskning av interaktiva widgets kräver interaktion i runtime: Anpassade drag-och-släpp-komponenter, canvas-baserade editorer och geststyrda karuseller avslöjar bara sin bristande tangentbordstillgänglighet när en testare faktiskt försöker använda dem utan mus. Axe-cores statiska DOM-skanning kan inte trigga event-lyssnare, observera fokusförlust under asynkrona operationer eller utvärdera om en drag-åtgärd kan slutföras via tangentbordets piltangenter och Enter/Space.
• Vad man ska leta efter under manuell granskning: Testare bör specifikt leta efter canvas-element som används för ritning eller interaktion, drag-och-släpp-listor eller områden för filuppladdning, anpassade kart- eller datavisualiseringskontroller, tidsbaserade reglage och alla komponenter som svarar på mousemove, pointermove eller touch-gester utan motsvarande tangentbordshändelsehanterare.

Hur man testar

1. Kör en automatiserad grundskanning: Använd axe DevTools (webbläsartillägg eller CLI) eller Google Lighthouse mot din sida för att identifiera lättupptäckta brister i tangentbordstillgänglighet—saknade fokuserbara element, tangentbordsfällor eller element med pointer-events: none som borde vara interaktiva. Även om dessa verktyg inte fångar överträdelser av 2.1.3 direkt, lyfter de fram relaterade problem och etablerar en ren grund innan manuell testning påbörjas.
2. Kartlägg all interaktiv funktionalitet: Skapa innan testning en fullständig inventering av varje interaktiv komponent på sidan: knappar, länkar, formulär, modaler, dragspel, karuseller, kartor, canvas-verktyg, drag-och-släpp-områden, anpassade dropdowns, datumväljare, videospelare och alla widgets som svarar på mus- eller touchhändelser. Denna inventering blir din testchecklista.
3. Test av navigation med enbart tangentbord: Koppla bort eller inaktivera din mus. Använd Tab och Shift+Tab för att flytta fokus, Enter och Space för att aktivera kontroller, Piltangenter för sammansatta widgets (menyer, reglage, flikar, radiogrupper) och Escape för att stänga dialoger. Försök att slutföra varje funktion på din inventeringslista. Notera alla funktioner som du inte kan initiera, slutföra eller lämna med enbart tangentbord.
4. Skärmläsartestning med NVDA + Firefox: Starta NVDA (Windows) med Firefox. Navigera med den virtuella markören (H för rubriker, B för knappar, F för formulärfält, Tab för interaktiva element). Försök med varje funktion. Lyssna efter annonserad roll, namn och tillstånd. Identifiera alla interaktiva regioner som är onåbara eller inte ger någon hörbar återkoppling.
5. Skärmläsartestning med JAWS + Chrome: Använd JAWS på Windows med Chrome. Använd JAWS virtuella markör och Forms Mode (växla med Enter). Verifiera att all funktionalitet kan användas och att fokus hanteras korrekt efter varje interaktion—särskilt efter att modala dialoger öppnas eller AJAX-innehåll laddas.
6. Skärmläsartestning med VoiceOver + Safari (macOS/iOS): Aktivera VoiceOver (Command + F5 på macOS). Använd Control + Option + Piltangenter för att navigera. På iOS använder du svepgester. Bekräfta att alla funktioner är nåbara och användbara. Var särskilt uppmärksam på anpassade touch-baserade widgets som kan sakna tangentbordsekvivalenter på skrivbordsversionen.
7. Granskning av banberoende funktionalitet: För alla rit-canvas, kartinteraktioner eller geststyrda komponenter, verifiera om en alternativ tangentbordsmekanism finns. Försök att skapa en form, ändra ordning på ett listelement eller panorera en karta med enbart tangentbordskontroller. Om ingen tangentbordsväg finns är detta ett direkt fel mot 2.1.3.
8. Kontroll av fokus­synlighet: När du navigerar enbart med tangentbord, bekräfta att fokus alltid är synligt på skärmen och logiskt ordnat. Osynligt fokus eller fokus som hoppar till oväntade platser är ett användbarhetsfel och bryter sannolikt också mot 2.4.7 och 2.4.3.

Hur man åtgärdar

Canvas-ritverktyg — felaktigt

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Canvas-ritverktyg — korrekt

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Drag-och-släpp-listomordning — felaktigt

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Drag-och-släpp-listomordning — korrekt

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Interaktiva kartkontroller — felaktigt

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Interaktiva kartkontroller — korrekt

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Vanliga misstag

• Att anta att undantaget för banberoende funktionalitet i WCAG 2.1.1 fortfarande gäller: Utvecklare som är bekanta med nivå A bygger ibland frihandsritnings- eller gestverktyg utan tangentbordsalternativ, utan att inse att 2.1.3 uttryckligen tar bort detta undantag. Varje funktion, inklusive ban-känsliga, måste ha en tangentbordsekvivalent på denna nivå.
• Att bara koppla onclick- och onmousedown-hanterare till anpassade interaktiva element: Anpassade widgets byggda med <div>- eller <span>-element som bara lyssnar på mushändelser är helt onåbara via tangentbord. Lägg alltid till onkeydown- eller onkeyup-hanterare tillsammans med mus-händelselyssnare, och säkerställ att elementet har tabindex='0' och en lämplig ARIA-roll.
• Att använda tabindex='-1' på element som ska ingå i tabb-ordningen: Att sätta tabindex='-1' tar bort ett element från den sekventiella tabb-ordningen. Detta är endast lämpligt för element som hanteras programmatiskt (t.ex. inom en sammansatt widget med roterande tabindex). Att tillämpa det på fristående interaktiva kontroller gör dem otillgängliga via tangentbord.
• Att implementera drag-och-släpp utan en tangentbordsbaserad omordningsmekanism: Bibliotek som SortableJS eller anpassade drag-implementationer tillhandahåller ofta inget tangentbordsalternativ direkt. Utvecklare måste implementera ARIA-mönstret för drag-och-släpp eller tillhandahålla omordning med Upp/Ner-piltangenter så att listomordning är fullt tangentbordsopererbar.
• Att förlita sig på :hover-CSS för att visa interaktiva kontroller: Dropdown-undermenyer, verktygstipsbaserade åtgärdsknappar eller kontroller som bara visas vid hover är otillgängliga för tangentbordsanvändare om inte :focus- och :focus-within-tillstånd också hanteras. En tangentbordsanvändare kan aldrig hovra, så innehåll som endast visas vid hover är i praktiken dolt för dem.
• Att inte hantera fokus efter dynamiska innehållsändringar: När en modal öppnas, en inline-varning visas eller en AJAX-laddad widget ersätter befintligt innehåll måste fokus programmatiskt flyttas till det nya innehållet med element.focus(). Att inte göra detta lämnar tangentbordsanvändare kvar på den position där de utlöste ändringen, utan medvetenhet om att nytt innehåll finns.
• Att bygga anpassade reglage med enbart onmousemove: Reglage av range-typ byggda av <div>-element som spårar musposition för värdeförändringar måste också implementera ArrowLeft, ArrowRight, Home och End-hantering enligt ARIA-reglagemönstret, och exponera det aktuella värdet via aria-valuenow, aria-valuemin och aria-valuemax.
• Att placera tangentbordsfokus inuti iframes utan att tillhandahålla en väg ut: Inbäddade iframes—särskilt de som innehåller tredjepartswidgets som kartor, betalningsformulär eller chattverktyg—kan fånga tangentbordsfokus om det inbäddade innehållet i sig inte är tangentbordstillgängligt och inte stöder Escape-tangenten för att återföra fokus till det överordnade dokumentet.
• Att utelämna tangentbordsstöd från canvas-baserade datavisualiseringar: Diagram och grafer som renderas på <canvas> är osynliga för tangentbordet och skärmläsare om inte ett tillgängligt alternativ (en datatabell, en SVG-ekvivalent med ARIA eller tangentbordsnavigerbara datapunkter) tillhandahålls tillsammans med canvas-elementet.
• Att testa tangentbordstillgänglighet endast med Tab och Enter, och ignorera tangentmönster för sammansatta widgets: Många ARIA-widgetmönster—menyer, träd, rutnät, flikpaneler, listboxar—kräver piltangentsnavigering inom widgeten, med endast ett enda tabb-stopp för hela komponenten (roterande tabindex). Att bara testa Tab och Enter kommer inte att avslöja brister i dessa sammansatta mönster och ger en falsk känsla av efterlevnad.

Relation till Turkiets tillgänglighetsreglering

Turkiets Presidential Circular 2025/10, publicerad i den officiella tidningen med nummer 32933 den 21 juni 2025, etablerar ett omfattande ramverk för webb- och mobiltillgänglighet för ett brett spektrum av offentliga och privata aktörer som är verksamma i Turkiet. Cirkuläret kräver överensstämmelse med standarder som är anpassade till WCAG 2.1 och 2.2, och ålägger berörda organisationer att säkerställa att deras digitala tjänster är uppfattningsbara, hanterbara, begripliga och robusta för alla användare, inklusive personer med funktionsnedsättning.

De aktörer som omfattas av denna reglering inkluderar offentliga institutioner och myndigheter på alla förvaltningsnivåer, e-handelsplattformar, banker och finansiella tjänsteleverantörer, sjukhus och vårdinrättningar, telekommunikationsföretag med 200,000 eller fler abonnenter, resebyråer, privata transportföretag och privatskolor som verkar med tillstånd från Ministry of National Education (MoNE). För dessa organisationer är efterlevnad av framgångskriterier på nivå A och nivå AA den minsta juridiska baslinjen.

WCAG 2.1.3 — Keyboard (No Exception) är ett kriterium på nivå AAA och är därför inte uttryckligen föreskrivet som ett grundläggande juridiskt krav enligt cirkuläret. Men regleringens anda—att säkerställa likvärdig digital åtkomst för Turkiets miljoner användare med funktionsnedsättning—stämmer starkt överens med avsikten med detta kriterium. Organisationer i berörda sektorer som erbjuder specialiserade tjänster till användare med motoriska funktionsnedsättningar, eller som driver myndighetsportaler som används av medborgare som är beroende av hjälpmedelsteknik, gör klokt i att sträva efter AAA-överensstämmelse för tangentbordsåtkomst.

Att uppnå efterlevnad av WCAG 2.1.3 signalerar ett förstklassigt tillgänglighetsåtagande som går bortom de regulatoriska minimikraven. För turkiska organisationer som vill betjäna den bredast möjliga användarbasen, demonstrera socialt ansvar eller delta i EU:s digitala marknader där högre tillgänglighetsstandarder kan gälla, är implementering av full tangentbordsopererbarhet utan undantag både en konkurrensfördel och en etisk fördel. I takt med att Turkiets regulatoriska landskap utvecklas och tillsynsmekanismerna mognar kommer tidiga användare av kriterier på AAA-nivå som 2.1.3 att vara väl positionerade för att möta framtida skärpningar av regleringen utan kostsam efterhandsanpassning.