Unngå tastaturfeller (WCAG 2.1.2)

Har du noen gang trykket Tab for å navigere deg gjennom en nettside, bare for å oppdage at du er «fanget» i et element du ikke kommer deg ut av? Kanskje fokus havnet inni en videospiller, en innebygd kartkomponent eller en modal - og uansett hva du trykker, sitter du fast. For de som er avhengige av tastaturnavigasjon, er dette ikke bare irriterende - det gjør nettsiden helt ubrukelig.

Hva sier kravet?

WCAG 2.1.2 «Ingen tastaturfelle» er et nivå A-krav, altså et absolutt minstekrav for tilgjengelighet. Kravet sier at dersom tastaturfokus kan flyttes til en komponent på siden, skal brukeren alltid kunne flytte fokus bort igjen med tastaturet alene. Hvis det kreves noe annet enn vanlige navigasjonstaster (Tab, Shift+Tab, piltaster), skal brukeren informeres om hvordan de kommer seg ut.

Kort sagt: brukeren skal aldri bli sittende fast. Uansett hvilken komponent de navigerer til, skal det alltid finnes en utvei med tastaturet.

Hvorfor er dette viktig?

En tastaturfelle er noe av det mest alvorlige som kan skje fra et tilgjengelighetsperspektiv. Når en bruker blir fanget, mister de all kontroll over navigasjonen. De kan ikke gå videre til neste element, ikke gå tilbake, og ofte ikke en gang lukke fanen i nettleseren med vanlige tastetrykk. I praksis betyr det at hele nettstedet stopper opp.

Dette rammer flere grupper enn de fleste tror:

• Tastaturbrukere med motoriske funksjonsnedsettelser som ikke kan bruke mus og er helt avhengige av tastaturnavigasjon
• Skjermleserbrukere som navigerer med de samme tastene og opplever den samme fellen
• Brukere med midlertidige skader - en brukket arm betyr at musen er ubrukelig i flere uker
• Avanserte brukere som foretrekker tastaturnavigasjon fordi det er raskere

En tastaturfelle kan også være et brudd på likestillings- og diskrimineringslovverket i Norge. Når en funksjon fungerer med mus men ikke med tastatur, diskriminerer du i praksis brukere som ikke kan bruke mus.

Slik oppfyller du kravet

Vær forsiktig med innebygd innhold

Det vanligste stedet for tastaturfeller er innebygd innhold via <iframe> - for eksempel kart fra Google Maps, videoavspillere, innebygde skjemaer fra tredjeparter eller sosiale medier-widgets. Problemet er at disse komponentene ofte håndterer tastaturfokus internt uten å slippe brukeren tilbake til hovedsiden.

Test alltid innebygd innhold ved å navigere inn i det med Tab og forsøke å komme ut igjen med Tab eller Escape. Hvis du sitter fast, må du finne en løsning:

<!-- Gi brukeren en vei forbi iframen -->
<a href="#etter-kart">Hopp forbi kartet</a>
<iframe src="https://maps.example.com/embed" title="Kart over kontoret vårt"></iframe>
<div id="etter-kart"></div>

Håndter modale dialoger riktig

Modaler er en annen klassisk kilde til tastaturfeller - men her handler det om balanse. En modal skal holde fokus inni seg selv (det kalles en «fokus-loop»), men den skal alltid kunne lukkes med Escape-tasten. Det er forskjellen mellom en tilsiktet fokus-begrensning og en felle.

<dialog id="bekreftelseDialog">
  <h2>Bekreft handling</h2>
  <p>Vil du slette denne filen permanent?</p>
  <button onclick="document.getElementById('bekreftelseDialog').close()">Avbryt</button>
  <button onclick="slettFil()">Ja, slett</button>
</dialog>

<script>
  const dialog = document.getElementById('bekreftelseDialog');
  dialog.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') {
      dialog.close();
    }
  });
</script>

HTML-elementet <dialog> håndterer mye av dette automatisk, inkludert Escape-lukking og fokusfanging. Det er langt tryggere enn å bygge egne modale løsninger med <div>.

Egendefinerte widgets og JavaScript-komponenter

Hvis du bygger egne interaktive komponenter - trekkspillmenyer, faner, datovalgverktøy eller lignende - må du tenke nøye gjennom tastaturnavigasjonen. Bruk ARIA Authoring Practices som referanse for forventede tastemønstre. For de fleste komponenttyper gjelder følgende:

• Tab skal flytte fokus inn og ut av komponenten
• Piltaster skal navigere inni komponenten
• Escape skal lukke popups, menyer og lignende
• Enter/Space skal aktivere valgt element

widget.addEventListener('keydown', (e) => {
  switch (e.key) {
    case 'Escape':
      lukkWidget();
      utloeserKnapp.focus(); // Flytt fokus tilbake
      break;
    case 'Tab':
      // La standard Tab-oppførsel fungere - ikke kall preventDefault()
      break;
  }
});

Den viktigste regelen er: aldri bruk preventDefault() på Tab-tasten uten en svært god grunn, og aldri uten å gi brukeren en alternativ utvei.

Tredjepartskomponenter

Mange tastaturfeller stammer fra tredjepartsverktøy - chat-widgets, cookie-bannere, analyseverktøy og sosiale medier-innbygg. Test disse grundig med tastaturet. Hvis de fanger fokus uten mulighet for å komme seg ut, bør du kontakte leverandøren eller vurdere alternative løsninger.

Vanlige feil

• Innebygde kartløsninger der fokus blir fanget inni kartet uten mulighet for å tabbe videre
• Egendefinerte modaler bygget med <div> som mangler Escape-funksjonalitet og fokusstyring
• Rich text-editorer som fanger Tab-tasten for å sette inn tabulatortegn i stedet for å flytte fokus videre
• Autofullfør-felter som åpner en dropdown men ikke lar brukeren tabbe forbi den
• Cookie-bannere fra tredjeparter som fanger fokus og ikke kan lukkes med tastatur
• Bruk av preventDefault() på tastaturhendelser som blokkerer normal Tab-navigasjon uten å tilby et alternativ

Test alltid med tastaturet. Trykk Tab gjennom hele siden, og legg spesielt merke til innebygd innhold, modaler og egne JavaScript-komponenter. Blir du fanget noe sted, har du funnet en feil som må fikses.