Ingen tastaturblokering
Hvis tastaturfokus kan flyttes til en komponent, skal fokus også kunne flyttes væk fra den udelukkende med tastatur. Modalvinduer, indlejret indhold og brugerdefinerede widgets er de sædvanlige syndere.
Hvad det kræver
Hvis en bruger kan Tab-navigere ind i en komponent, skal de kunne Tab-navigere (eller Shift+Tab, eller bruge en anden dokumenteret tast) ud af den igen uden at bruge musen. Hvis der kræves noget mere end de standard pil-/Tab-taster for at forlade — f.eks. Ctrl+M for at forlade en indlejret videoafspiller — skal brugeren informeres om dette.
Dette er ikke det samme som en fokusblokering inde i et modalvindue, som er et ønskeligt mønster: et modalvindue cykler fokus inden i sig selv, men frigiver fokus, når brugeren lukker det. En tastaturblokering opstår, når der ikke er nogen dokumenteret vej ud.
Sådan opfyldes det
- Inde i en modaldialogboks cykles fokus mellem det første og sidste fokuserbare element med Tab og Shift+Tab, og dialogboksen lukkes ved Escape, hvorefter fokus returneres til udløseren.
- For indlejret tredjepartsindhold (videoafspillere, kort, iframes fra ukendte kilder) testes det, om Tab fortsætter forbi det indlejrede indhold. Hvis det ikke gør, dokumenteres exit-tastetrykket i nærheden af det indlejrede indhold.
- For brugerdefinerede widgets der bruger piletaster (datovælgere, kombobokse, trævisninger) holdes Tab som den universelle exitvej — den må aldrig blokeres.
- For trækhåndtag eller redigeringsprogrammer til rig tekst, der bruger Tab til indrykning, angives et dokumenteret alternativ (Escape for at frigive, Ctrl+M for at forlade redigeringstilstand) og det vises i brugergrænsefladen.
Hyppige fejl
- Modaldialogbokse der blokerer fokus, men ikke lukkes med Escape og ikke eksponerer en fokuserbar Luk-knap.
- Indlejrede PDF-fremvisere, Flash-relikvier og visse Tableau/Power BI-dashboards der sluger Tab-tryk ubegrænset.
- Redigeringsprogrammer til rig tekst (TinyMCE, CKEditor i ældre versioner) der fanger Tab til indrykning og aldrig frigiver det.
- Brugerdefinerede kombobokse, hvor piletaster bevæger sig gennem muligheder, men Tab ikke gør noget — brugeren sidder fast ved input-feltet.
- Cookie-bannere med fokusstyring der løber i en sløjfe uden nogensinde at tilbyde fokus på Accepter/Afvis.
Automatiserede værktøjer opdager sjældent dette — axe og Lighthouse kan kun markere mistænkelige mønstre. Manuel tastaturtest er den eneste pålidelige kontrol.
Hvorfor det er vigtigt
En tastaturblokering er en af de alvorligste tilgængelighedsfejl: brugeren er bogstaveligt talt ude af stand til at forlade den del af siden. En blind bruger kan blive nødt til at genindlæse siden og miste sin session og eventuelle formulardata. For mange brugere er dette det øjeblik, de forlader webstedet helt. Af alle WCAG-kriterierne er dette det, der med størst sandsynlighed gør en side juridisk uforsvarlig — domstole og håndhævelsesmyndigheder betragter det at blokere brugere som en klar barriere.