Ingen overraskelser når noe får fokus (WCAG 3.2.1)

Når du trykker Tab-tasten for å navigere gjennom en nettside, forventer du at fokus flyttes stille og rolig til neste element. Du forventer ikke at siden plutselig navigerer bort, at et skjema sender seg selv, eller at et vindu åpner seg. Likevel skjer dette overraskende ofte på norske nettsider - og det skaper store problemer for tastaturbrukere.

Hva sier kravet?

WCAG 3.2.1 Ved fokus krever at ingenting uventet skal skje bare fordi et element mottar fokus. Med «kontekstendring» mener WCAG en større endring som - hvis den skjer uten brukerens vilje - kan forvirre brukeren. Typiske kontekstendringer er:

• Navigasjon til en ny side eller et nytt vindu
• Betydelig omstrukturering av innholdet på siden
• At fokus flyttes til et annet element
• At skjemadata sendes inn

Kravet er klassifisert som nivå A, altså helt grunnleggende. Det betyr at dette er noe alle norske nettsider må oppfylle. Prinsippet bak er enkelt: brukeren skal alltid ha kontroll over hva som skjer. Endringer på siden skal skje som respons på en bevisst handling - et klikk, et tastetrykk, en innsending - ikke bare fordi brukeren tabbet seg til et element.

Det er verdt å merke seg at kravet ikke forbyr alle endringer ved fokus. Små visuelle endringer som at en knapp skifter farge, at det vises et tooltip, eller at en ramme markerer det fokuserte elementet er helt greit. Det er de store, uventede endringene som er problemet.

Hvorfor er dette viktig?

Tastaturbrukere mister kontrollen

Mange bruker tastaturet som primær navigasjonsmetode - enten fordi de har en motorisk funksjonsnedsettelse, bruker skjermleser, eller rett og slett foretrekker tastatur. Når fokus alene utløser navigasjon eller andre store endringer, mister disse brukerne orienteringen. De vet ikke lenger hvor de er på siden, hva som endret seg, eller hvordan de kommer tilbake.

Skjermleserbrukere blir spesielt rammet

En skjermleserbruker oppdager innhold sekvensielt - element for element. Hvis fokus på et element plutselig fører til at hele sidens innhold endres, har brukeren ingen visuell kontekst å lene seg på. De vet kanskje ikke engang at noe har skjedd, og fortsetter å navigere i det de tror er det opprinnelige innholdet.

Det bryter med brukernes forventninger

Alle brukere, uansett funksjonsnivå, har innlærte forventninger til hvordan nettsider oppfører seg. Vi forventer at ting skjer når vi klikker, ikke når vi bare ser på noe. En nettside som bryter med dette mønsteret oppleves som uforutsigbar og upålitelig.

Slik oppfyller du kravet

Ikke bruk onfocus for navigasjon

Det vanligste bruddet er JavaScript-kode som navigerer eller gjør store endringer i en onfocus- eller focus-hendelse:

<!-- Feil: Navigerer når feltet får fokus -->
<select onfocus="window.location = this.value;">
  <option value="/side1">Side 1</option>
  <option value="/side2">Side 2</option>
</select>

<!-- Riktig: Bruk en knapp for å bekrefte valget -->
<select id="sidevelger">
  <option value="/side1">Side 1</option>
  <option value="/side2">Side 2</option>
</select>
<button onclick="window.location = 
  document.getElementById('sidevelger').value;">
  Gå til valgt side
</button>

Ikke åpne modaler ved fokus

Noen nettsider åpner dialogbokser eller modaler når brukeren tabber til et bestemt element. Dette er nesten alltid forvirrende:

// Feil: Åpner modal bare fordi elementet får fokus
document.getElementById('hjelp-lenke')
  .addEventListener('focus', function() {
    openHelpModal();
  });

// Riktig: Åpne modalen ved klikk eller Enter
document.getElementById('hjelp-lenke')
  .addEventListener('click', function() {
    openHelpModal();
  });

Ikke send skjemaer ved fokus

Å sende inn skjemadata bare fordi et felt får fokus er en alvorlig feil som heldigvis er sjelden, men som forekommer:

// Feil: Sender skjema når siste felt får fokus
lastField.addEventListener('focus', function() {
  document.forms[0].submit();
});

// Riktig: La brukeren klikke en send-knapp
submitButton.addEventListener('click', function() {
  document.forms[0].submit();
});

Tooltips og hjelpetekst er OK

Det er helt greit å vise tilleggsinformasjon ved fokus, så lenge det ikke endrer konteksten:

/* Synlig fokusstil - anbefalt */
button:focus {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

/* Tooltip ved fokus - OK */
.tooltip-trigger:focus + .tooltip {
  display: block;
}

<!-- Hjelpetekst som vises ved fokus - OK -->
<input type="email" id="epost" 
  aria-describedby="epost-hjelp">
<span id="epost-hjelp" class="hjelpetekst">
  Vi bruker e-posten din kun for å sende kvittering.
</span>

Bruk fokusindikatorer, ikke fokushendelser

Skillet er viktig: bruk gjerne CSS til å style fokustilstanden slik at brukeren ser hvor de er (det er faktisk påkrevd av WCAG 2.4.7). Men ikke bruk fokushendelser i JavaScript til å utføre handlinger som endrer konteksten.

Vanlige feil

• Dropdown-menyer som navigerer ved fokus - en <select> som sender brukeren til en ny side bare fordi de tabbet til den, uten å trykke Enter eller klikke.
• Autoplay av video eller lyd ved fokus - medieelementer som starter avspilling når de får fokus, spesielt problematisk for skjermleserbrukere som plutselig hører to lydkilder samtidig.
• Fokusfeller - elementer der fokus flyttes automatisk tilbake til det samme elementet, slik at brukeren ikke kommer seg videre. Dette er ikke bare et WCAG 3.2.1-brudd, men også et brudd på 2.1.2 Ingen tastaturfelle.
• Chat-widgets som åpner seg ved fokus - noen chat-løsninger utvider seg når elementet mottar fokus, noe som endrer layout og kan flytte innhold brukeren prøver å lese.
• Skjemavalidering ved fokus - feilmeldinger som dukker opp før brukeren har skrevet noe, bare fordi feltet fikk fokus.

Hovedregelen er enkel: la brukeren bestemme selv. Fokus er ikke en handling - det er bare en markør som viser hvor brukeren er. Bruk klikk, Enter eller andre eksplisitte handlinger for å utløse endringer.