Hvem er afhængige af tastaturnavigation?
Tastaturnavigation handler ikke kun om brugere, der foretrækker genvejstaster. Det er en grundlæggende forudsætning for adgang for tre overlappende grupper:
Brugere med motoriske funktionsnedsættelser kan ikke bruge en mus pga. nedsat finmotorik, lammelse eller skælvinger. De navigerer udelukkende via tastaturet — eller via alternative inputenheder som styre-pinde, øjensporing eller sip-and-puff-enheder, der alle sender tastatur-events til browseren.
Skærmlæserbrugere — blinde og stærkt svagsynede brugere — bruger programmer som NVDA, JAWS eller VoiceOver, der udelukkende kommunikerer via tastatur-kommandoer. Er et element ikke tilgængeligt med tastaturet, eksisterer det ikke for en skærmlæser.
Brugere med midlertidige begrænsninger — gebrækket håndled, betændt sene eller en ødelagt mus — ender i samme situation: afhængige af tastaturet for at komme videre.
Tastaturnavigation er med andre ord ikke et edge case. Det er forudsætningen for, at hjælpemidler overhovedet kan fungere.
De fire WCAG 2.1-succeskriterier for tastatur
WCAG 2.1 indeholder fire succeskriterier, der specifikt adresserer tastaturnavigation. To er niveau A (absolut minimum), ét er niveau AA (lovkravet), og ét er niveau A men introduceret i WCAG 2.1 — og dermed nyt for mange organisationer.
2.1.1 Tastatur (niveau A): Al funktionalitet, der er tilgængelig med mus eller pegeenhed, skal også kunne betjenes udelukkende via tastaturet — uden krav om specifikke timing-mønstre ved tastetryk. Eneste undtagelse er funktioner, der grundlæggende afhænger af bevægelses-stier og ikke blot start- og slutpunkter — eksempelvis frihånds-tegning. Tekstinput via håndskrift er ikke undtaget: det er tekstinput, der kræves, ikke stien.
2.1.2 Ingen tastatur-fælde (niveau A): Hvis fokus kan flyttes til en komponent via tastaturet, skal det også kunne flyttes væk igen — udelukkende ved hjælp af standard tastatur-kommandoer. Kræver en komponent ikke-standard taster for at forlade den, skal brugeren informeres om dette. Cookie-bannere, modale dialoger og indlejrede kortapplikationer er hyppige problemer her.
2.1.4 Enkelt-tegn genveje (niveau A, ny i WCAG 2.1): Webapplikationer, der anvender enkelt-tegn tastatur-genveje — eksempelvis at trykke “S” for søgning — skal give brugeren mulighed for enten at deaktivere genvejen, ændre den til at kræve en modifikator-tast (Ctrl, Alt, Shift), eller gøre den inaktiv, medmindre et relevant komponent har fokus. Baggrunden er, at skærmlæsere og stemme-styringssoftware selv anvender enkelt-taster som kommandoer, og konflikter skaber uforudsigelig adfærd.
2.4.7 Synligt fokus (niveau AA): Enhver komponent, der kan betjenes via tastaturet, skal have en synlig fokus-indikator — den visuelle markering der viser, hvor tastatur-fokus befinder sig. Det er dette niveau, der er lovpligtigt for offentlige myndigheder i Danmark. Et typisk problem er CSS-regler som outline: none eller *:focus { outline: none }, der fjerner browserens standard fokus-indikator uden at erstatte den med et alternativ. Fokus-indikatoren behøver ikke have en bestemt form, men skal være synlig og konsistent.
Hertil kommer 2.4.3 Fokus-rækkefølge (niveau A), som kræver, at tastatur-fokus følger en logisk og meningsfuld rækkefølge — typisk top til bund, venstre til højre. En side, der er visuelt korrekt opbygget, men har rod i DOM-strukturen eller anvender positive tabindex-værdier, kan fejle dette krav.
De vigtigste tastatur-kommandoer
For at forstå tastaturnavigation i praksis er det nyttigt at kende de standardiserede kommandoer, brugerne er vant til at anvende:
- Tab: Flytt fokus fremad til næste interaktive element
- Shift+Tab: Flytt fokus tilbage til forrige element
- Enter: Aktiverer links og knapper
- Mellemrumstast: Aktiverer knapper, markerer checkboxe og radioknapper
- Piletaster: Navigerer inden for dropdown-menuer, radioknapper, sliders og faner
- Escape: Lukker modale dialoger, overlay-elementer og udfoldet navigationsmenuer
- Home/End: Navigerer til starten eller slutningen af lister
Disse kommandoer er en del af den forventede adfærd for velstruktureret HTML. Native HTML-elementer som <button>, <a>, <input> og <select> understøtter dem automatisk. Det er primært brugerdefinerede komponenter bygget på <div> eller <span> med JavaScript-hændelseshåndterer, der hyppigst fejler.
Hyppige fejl i praksis
En gennemgang af tilgængeligheds-erklæringer og tilsynsrapporter viser, at de samme typer fejl går igen på offentlige websteder:
Fokus-indikatoren er fjernet eller usynlig — Mange designsystemer og CSS-nulstillinger fjerner outline-stilen globalt for at undgå visuel “støj”. Resultatet er, at tastaturbrugere ikke kan se, hvilket element der er aktivt.
Tastatur-fælder i modale dialoger — En modal åbnes, men fokus fanges ikke korrekt inde i den. Brugeren kan tab’e ud af dialogen, klikke på baggrunden og miste kontekst — eller er omvendt låst fast og kan ikke lukke dialogen med Escape.
Brugerdefinerede komponenter uden tastatur-understøttelse — Et accordeon-menu, en fane-navigation eller en dropdown bygget på <div>-elementer med kun onclick-hændelser vil fungere med mus, men er usynlig for tastaturnavigation. Elementet modtager ikke fokus og kan ikke aktiveres.
Spring-over-navigation mangler — Brugere, der navigerer med tastatur, skal igennem samtlige navigationselementer på en side, for de når til hovedindholdet. Et “Spring til indhold”-link, placeret som første element i koden og synligt ved fokus, løser dette — men det mangler på mange offentlige websteder.
Sådan tester du tastaturnavigation
Automatiserede testværktøjer kan identificere nogle tastaturnavigations-fejl — eksempelvis interaktive elementer uden tabindex eller fokus-indikatorer med for lav kontrast. Men de kan ikke simulere reel tastaturnavigation eller verificere, at komplekse interaktions-mønstre fungerer. Manuel test er nødvendig.
Den grundlæggende manuelle test udføres ved at lægge musen til side og gennemgå webstedet udelukkende med tastaturet:
- Tryk Tab igennem alle sider og verificer, at alle interaktive elementer er tilgængelige og at fokus er synligt
- Brug Shift+Tab til at navigere baglæns og kontroller, at rækkefølgen er sammenhængende
- Test, at Enter og Mellemrumstast aktiverer alle knapper og links som forventet
- Åbn og luk alle modale dialoger, dropdown-menuer og accordeons — og kontroller, at fokus håndteres korrekt når de åbnes og lukkes
- Udfyld og indsend alle formularer udelukkende med tastatur
- Verificer, at fokus returnerer til et logisk sted efter en dialogboks lukkes
Supplér den manuelle test med automatiserede scannere som axe DevTools eller WAVE, der kan identificere strukturelle fejl som manglende fokus-stile og forkerte tabindex-værdier.
Tastaturnavigation i PDF-dokumenter
Et særligt problem opstår med PDF-dokumenter, der er det eneste alternativ til information. En tagget PDF kan principielt navigeres med tastaturet i Adobe Acrobat Reader — men navigationsoplevelsen er langt mere kompleks og uforudsigelig end i velstruktureret HTML.
Konverteres et PDF-dokument til semantisk HTML, arver det alle de native tastaturnavigations-egenskaber, som browseren tilbyder: logisk tab-rækkefølge, synlige fokus-indikatorer og standard tastatur-kommandoer. Det er en af grundene til, at HTML-konvertering af PDF-dokumenter — eksempelvis via PDFAccess — giver en markant bedre tastaturnavigations-oplevelse end selv et veltagget PDF/UA-dokument.
Tjekliste: Tastaturnavigation
- Alle interaktive elementer er tilgængelige med Tab-tasten
- Fokus-indikatoren er synlig på alle interaktive elementer —
outline: noneer ikke anvendt uden et alternativ - Tab-rækkefølgen følger en logisk visuel rækkefølge
- Ingen tastatur-fælder: fokus kan altid flyttes væk fra ethvert element
- Modale dialoger fanger fokus korrekt og kan lukkes med Escape
- Fokus returnerer til et logisk element efter en dialog lukkes
- Et “Spring til indhold”-link er tilgængeligt som første fokuserbare element
- Enkelt-tegn genveje kan deaktiveres eller ændres (WCAG 2.1.4)
- Alle formularer kan udfyldes og indsendes udelukkende med tastatur