Interaktive elementer

Alle som besøker nettsiden din bruker ikke mus. Noen navigerer utelukkende med tastatur – kanskje på grunn av en motorisk funksjonsnedsettelse, kanskje fordi de bruker en skjermleser, eller kanskje bare fordi de foretrekker det. WCAG-suksesskriteriet 2.1.1 «Tastatur» krever at all funksjonalitet på nettsiden skal være tilgjengelig via tastatur. Det er et nivå A-krav, altså et absolutt minimumskrav for tilgjengelighet.

Hva sier WCAG 2.1.1?

Kravet er rett frem: alle funksjoner som kan brukes med mus, skal også kunne brukes med tastatur alene. Det inkluderer å klikke på knapper, følge lenker, fylle ut skjemaer, åpne menyer, spille av videoer, lukke dialoger – absolutt alt. Det eneste unntaket er funksjoner som er avhengige av selve bevegelsen til musepekeren, som frihåndstegning.

Tastaturbrukere navigerer med Tab-tasten for å flytte mellom interaktive elementer, Enter eller Space for å aktivere dem, og Escape for å lukke dialoger og menyer. Piltastene brukes for å navigere inni komponenter som menyer, faner og radioknapper.

Bruk de riktige HTML-elementene

Den enkleste og mest effektive måten å sikre tastaturstøtte på er å bruke de riktige HTML-elementene. HTML har innebygd tastaturstøtte for mange elementer:

• <a href="..."> – kan fokuseres med Tab og aktiveres med Enter.
• <button> – kan fokuseres med Tab og aktiveres med Enter eller Space.
• <input>, <select>, <textarea> – alle skjemaelementer har innebygd tastaturfunksjonalitet.

Problemet oppstår når utviklere bruker ikke-interaktive elementer som <div> eller <span> for klikkbare funksjoner:

<!-- FEIL: div med klikkhendelse er ikke tastaturvennlig -->
<div class="knapp" onclick="sendSkjema()">Send inn</div>

Denne «knappen» fungerer fint med mus, men en tastaturbruker kan verken fokusere på den eller aktivere den. Løsningen er enkel – bruk et ekte <button>-element:

<!-- RIKTIG: Ekte knapp med innebygd tastaturstøtte -->
<button type="button" onclick="sendSkjema()">Send inn</button>

Forstå tabindex

tabindex-attributtet styrer om og i hvilken rekkefølge et element kan fokuseres med tastatur. Det har tre verdier du bør kjenne til:

tabindex="0" – Legg til i fokusrekkefølgen

Gjør et element fokusbart via Tab, i den naturlige rekkefølgen det forekommer i HTML-koden. Bruk dette når du unntaksvis trenger å gjøre et ikke-interaktivt element fokusbart:

<div role="button" tabindex="0" onclick="doSomething()" onkeydown="handleKey(event)">
  Egendefinert knapp
</div>

Merk at du da også må håndtere tastaturhendelser manuelt – noe som er enda en grunn til å bruke ekte <button>-elementer i stedet.

tabindex="-1" – Fokusbar via script, ikke Tab

Gjør et element fokusbart med JavaScript (element.focus()), men det dukker ikke opp i Tab-rekkefølgen. Nyttig for elementer som skal kunne motta fokus programmatisk, for eksempel en feilmelding:

<div id="feilmelding" tabindex="-1" role="alert">
  Vennligst fyll ut alle obligatoriske felter.
</div>

<script>
  document.getElementById('feilmelding').focus();
</script>

tabindex med positive verdier – unngå dette

Verdier som tabindex="1", tabindex="5" osv. endrer Tab-rekkefølgen manuelt. Dette skaper nesten alltid forvirring og bør unngås. La Tab-rekkefølgen følge den naturlige rekkefølgen i HTML-koden i stedet.

Vanlige feil

Klikkhandlere på div-elementer

Som nevnt over er dette den vanligste feilen. Når du bruker onclick på et <div>-element, fungerer det ikke med tastatur. Bruk <button> eller <a> i stedet.

Fokusfeller

En fokusfelle oppstår når tastaturbrukeren ikke kan navigere seg ut av et element. Det vanligste tilfellet er modale dialoger som ikke lukkes med Escape-tasten, og der fokus ikke holdes inni dialogen. En tilgjengelig modal skal:

1. Flytte fokus inn i dialogen når den åpnes.
2. Holde fokus inni dialogen (Tab skal «wrappe» inni dialogen).
3. Lukke dialogen og flytte fokus tilbake til utløserelementet når brukeren trykker Escape.

<dialog id="minDialog">
  <h2>Bekreft sletting</h2>
  <p>Er du sikker på at du vil slette denne siden?</p>
  <button onclick="document.getElementById('minDialog').close()">Avbryt</button>
  <button onclick="slettSide()">Slett</button>
</dialog>

HTML-elementet <dialog> har mye av denne funksjonaliteten innebygd, og er et godt alternativ til selvlagde modale vinduer.

Manglende fokusindikator

Når du fjerner standard-fokusindikatoren med outline: none uten å legge til en alternativ, gjør du det umulig for tastaturbrukere å se hvor de er på siden:

/* FEIL: Fjerner fokusindikator uten erstatning */
*:focus {
  outline: none;
}

/* RIKTIG: Erstatter med tydelig fokusindikator */
*:focus-visible {
  outline: 3px solid #1a73e8;
  outline-offset: 2px;
}

Bruk :focus-visible i stedet for :focus for å bare vise fokusindikatoren for tastaturbrukere, ikke for museklikk.

Hover-innhold som ikke er tilgjengelig med tastatur

Innhold som kun vises ved mus-hover (for eksempel tooltips eller dropdown-menyer) må også være tilgjengelig via tastaturfokus:

.meny-element .undermeny {
  display: none;
}

.meny-element:hover .undermeny,
.meny-element:focus-within .undermeny {
  display: block;
}

Praktiske tips

1. Bruk native HTML-elementer der det er mulig – <button>, <a>, <input> og <select> har innebygd tastaturstøtte.
2. Test med tastatur. Naviger gjennom hele nettsiden med bare Tab, Enter, Space og Escape. Kan du nå alt?
3. Sjekk fokusrekkefølgen. Er den logisk? Følger den den visuelle rekkefølgen på siden?
4. Unngå positive tabindex-verdier. La rekkefølgen i HTML-koden bestemme Tab-rekkefølgen.
5. Ha alltid en synlig fokusindikator. Uten den er tastaturnavigasjon som å kjøre bil uten speedometer.
6. Test modale dialoger. Kan du lukke dem med Escape? Holdes fokus inni dialogen?

Tastaturnavigasjon er grunnmuren i tilgjengelighet. Nesten alle andre hjelpeteknologier – skjermlesere, bryterstyring, stemmestyring – bygger på tastaturtilgjengelighet. Får du dette riktig, er du godt på vei mot en universelt utformet nettside.