En kort, tydelig sjekkliste for tilgjengelige webknapper

Problemet med råd om tilgjengelighet for knapper

De fleste råd om tilgjengelige knapper havner i én av to leirer: enten er det en 40-siders WCAG-tolkning som ingen leser, eller så er det et vagt forslag om å "gjøre knapper tilgjengelige" uten konkrete steg. Ingen av delene hjelper når du skal levere en funksjon på torsdag.

Denne sjekklisten dekker de fem vanligste tilgjengelighetsfeilene i knapper som vi ser i produksjon. Den gjør deg ikke til en WCAG-ekspert, men den fanger problemene som faktisk påvirker brukere.

1. Bruk button-elementet for knapper

Hvis det oppfører seg som en knapp, bør det være et <button>-element. Ikke en <div> med onclick, ikke en <span> med role="button", ikke en <a> med href="#" og preventDefault.

<button>-elementet gir deg tastaturnavigasjon, fokushåndtering og kunngjøringer for skjermlesere uten ekstra arbeid. Når du bruker en <div>, bygger du alt dette på nytt fra bunnen av — og du kommer til å gjøre det feil.

Det eneste unntaket: hvis handlingen navigerer til en ny side eller endrer URL-en, bruk et <a>-element. Lenker og knapper er semantisk forskjellige. Skjermleserbrukere navigerer etter elementtype, og de forventer at knapper utfører handlinger og at lenker navigerer.

2. Gjør treffområdet minst 44×44 piksler

WCAG 2.5.5 (Level AAA) krever at interaktive elementer har en minste målstørrelse på 44×44 CSS-piksler. Dette handler ikke om visuell størrelse — det handler om det klikkbare området.

Du kan ha en liten visuell knapp med tilstrekkelig padding, eller du kan utvide treffområdet med et pseudo-element. Det som betyr noe, er at brukeren ikke må sikte presist.

Mobilbrukere, personer med motoriske funksjonsnedsettelser og alle som bruker en enhet i bevegelse, vil bomme på små mål. En ikonknapp på 24×24 piksler kan se ryddig ut, men den er en brukervennlighetsfeil.

3. Gi synlige fokustilstander som ikke bare er nettleserens standard

Nettleserens standard fokusring er bedre enn ingenting, men den er inkonsistent på tvers av nettlesere og ofte usynlig mot bestemte bakgrunner. Du trenger en egendefinert fokustilstand som fungerer i designsystemet ditt.

En god fokusindikator har tre egenskaper:

• Høy kontrast: minst 3:1 mot tilstøtende farger
• Synlig avstand: ikke skjult av knappens egen kantlinje eller bakgrunn
• Konsekvent form: brukere bør kjenne den igjen som en fokusindikator på tvers av grensesnittet ditt

Ikke fjern outline: none uten å erstatte det med noe bedre. Og ikke gjør fokustilstander så subtile at bare du kan se dem under perfekte lysforhold.

4. Skriv knappetekster som gir mening uten kontekst

Skjermleserbrukere navigerer ofte ved å hoppe mellom knapper. Når de gjør det, hører de en liste med knappetekster uten omkringliggende kontekst.

En knapp merket "Les mer" er ubrukelig i den listen. Det samme gjelder "Klikk her" eller "Send". Etiketten bør beskrive handlingen: "Last ned tilgjengelighetssjekklisten", "Abonner på oppdateringer", "Slett denne kommentaren".

Hvis designet ditt krever en kort visuell etikett, bruk aria-label for å gi et beskrivende alternativ. Men den bedre løsningen er å skrive etiketter som fungerer for alle.

For knapper med bare ikon er aria-label obligatorisk. En knapp med bare et forstørrelsesglassikon trenger aria-label="Search" eller tilsvarende tekst. Ikonet er ikke tilgjengelig for skjermlesere.

5. Sørg for tilstrekkelig fargekontrast

WCAG 2.1 krever et kontrastforhold på minst 4.5:1 for normal tekst og 3:1 for stor tekst (18pt eller 14pt fet). Knappetekster er vanligvis normal tekst.

Lysegrå tekst på en hvit knapp feiler. Blek blå på en lyseblå bakgrunn feiler. Disse kombinasjonene kan se sofistikerte ut, men de ekskluderer brukere med nedsatt syn, fargeblindhet eller alle som ser på skjermen i sterkt sollys.

Bruk en kontrastsjekker under designarbeidet, ikke etter lansering. Å rette kontrastproblemer i produksjon er dyrt fordi det ofte krever endringer i designsystemet.

Hvis du jobber med bildebehandlingsverktøy, kan klientsidebehandling bidra til å bevare personvernet samtidig som du genererer tilgjengelige visuelle ressurser — spesielt når du tester fargekombinasjoner eller genererer forhåndsvisningstilstander.

Hva denne sjekklisten ikke dekker

Denne listen er med vilje ufullstendig. Den dekker ikke semantikk for deaktivert tilstand, lastetilstander, feilhåndtering eller komplekse knappemønstre som delte knapper eller nedtrekksutløsere. Disse mønstrene trenger egen veiledning.

Den dekker heller ikke det bredere spørsmålet om når du skal bruke en knapp kontra andre interaktive elementer. For det må du forstå semantisk HTML og tilgjengelighetstreet — temaer som fortjener egne artikler.

Det den dekker, er de enkle gevinstene: feilene som dukker opp i nesten hver kodegjennomgang, som påvirker flest brukere, og som er lettest å rette under utvikling.

Slik integrerer du dette i arbeidsflyten din

Tilgjengelighetssjekklister fungerer bare hvis de er en del av utviklingsprosessen, ikke lagt på i etterkant. Slik får du det til:

I design: legg til fokustilstander og merknader om treffområde i designfilene dine. Ikke la utviklere gjette seg til dette.

I kodegjennomgang: sjekk etter <button>-elementer, aria-label på ikonknapper og CSS for fokustilstand. Dette er raskt å oppdage.

I testing: tab deg gjennom grensesnittet med tastaturet. Hvis du ikke kan nå en knapp eller ikke kan se hvor fokuset er, kan ikke brukerne dine det heller.

I dokumentasjon: inkluder tilgjengelighetskrav for knapper i komponentbiblioteket ditt. Gjør det enklere å gjøre det riktige enn å gjøre det gale.

Hvis du feilsøker produksjonsproblemer, kan verktøy for å inspisere HTTP-headere og omdirigeringer hjelpe deg med å forstå hvordan hjelpemiddelteknologi tolker markupen din — spesielt når du feilsøker fokushåndtering etter navigasjon.

Kostnaden ved å hoppe over dette arbeidet

Utilgjengelige knapper bryter ikke bare WCAG-samsvar — de ødelegger arbeidsflyter. En bruker som ikke kan klikke på en send-knapp, kan ikke fullføre et skjema. En bruker som ikke kan se fokustilstander, kan ikke navigere med tastatur. En bruker som ikke kan skille knappeteksten fra bakgrunnen, kan ikke lese etiketten.

Dette er ikke randtilfeller. Omtrent 15 % av verdens befolkning har en form for funksjonsnedsettelse, og midlertidige begrensninger (ødelagt mus, sterkt sollys, å holde en baby) påvirker alle til slutt.

Den gode nyheten er at tilgjengelige knapper stort sett er løste problemer. Du trenger ikke å finne opp nye mønstre eller vente på nettleserstøtte. Du trenger bare å bruke plattformen riktig og teste arbeidet ditt.

Viktige punkter

• Bruk <button>-elementer for knapper og <a>-elementer for navigasjon — den semantiske forskjellen betyr noe for hjelpemiddelteknologi
• Sørg for at treffområder er minst 44×44 CSS-piksler for å ta hensyn til motoriske funksjonsnedsettelser og mobilbrukere
• Gi synlige fokustilstander med høy kontrast som fungerer på tvers av designsystemet ditt
• Skriv knappetekster som gir mening når de leses isolert, og bruk aria-label for knapper med bare ikon
• Sjekk fargekontrast under designarbeidet, ikke etter lansering, for å unngå dyre ettermonteringer

FAQ

Q: Kan jeg bruke role="button" på en <div> hvis jeg legger til tastaturhåndterere?

A: Du kan, men du bør ikke. Du må håndtere Enter, Space, fokushåndtering og deaktiverte tilstander manuelt — og du vil uunngåelig overse noe. <button>-elementet gjør alt dette riktig som standard. Bruk det.

Q: Hva med knapper som veksler tilstand, som en spill av/pause-knapp?

A: Bruk aria-pressed="true" eller aria-pressed="false" for å angi gjeldende tilstand. Knappeteksten bør også reflektere handlingen som skjer ved klikk ("Pause" når noe spiller, "Spill av" når det er pauset), ikke den gjeldende tilstanden. Skjermleserbrukere må vite hva knappen vil gjøre, ikke hvilken tilstand systemet er i.

Q: Må deaktiverte knapper oppfylle kontrastkrav?

A: WCAG 2.1 unntar deaktiverte kontroller fra kontrastkrav (1.4.3), men dette er omdiskutert. Deaktiverte knapper med dårlig kontrast er vanskelige for alle å oppfatte. Hvis du skal vise en deaktivert knapp, gjør den lesbar. Enda bedre: skjul den eller forklar hvorfor den er deaktivert.

Q: Hvordan tester jeg knappers tilgjengelighet uten en skjermleser?

A: Bruk tastaturet. Tab deg gjennom grensesnittet og verifiser at du kan nå hver knapp, se hvor fokuset er, og aktivere knapper med Enter eller Space. Dette fanger de fleste problemer. For dypere testing, bruk tilgjengelighetsinspektøren i Chrome eller Firefox DevTools for å sjekke beregnet rolle og etikett.

Q: Hva er forskjellen mellom aria-label og aria-labelledby?

A: aria-label gir en tekststreng direkte. aria-labelledby refererer til ID-en til et annet element hvis tekstinnhold blir etiketten. Bruk aria-labelledby når etikettteksten allerede finnes et annet sted i DOM-en. Bruk aria-label når du må gi en etikett som ikke er synlig på skjermen.

Kilder

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM