En kort, holdningspræget tjekliste for tilgængelige webknapper

Problemet med råd om tilgængelighed for knapper

De fleste retningslinjer for tilgængelighed for knapper falder i to lejre: Enten er det en 40-siders fortolkning af WCAG, som ingen læser, eller også er det et vagt forslag om at "gøre knapper tilgængelige" uden handlingsrettede trin. Ingen af delene hjælper, når du skal sende en funktion i produktion på torsdag.

Denne tjekliste dækker de fem mest almindelige tilgængelighedsfejl ved knapper, vi ser i produktion. Den gør dig ikke til WCAG-ekspert, men den fanger de problemer, der faktisk påvirker brugerne.

1. Brug button-elementet til knapper

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

<button>-elementet giver dig tastaturnavigation, fokusstyring og annonceringer til skærmlæsere gratis. Når du bruger en <div>, genopbygger du alt det fra bunden — og du vil gøre det forkert.

Den eneste undtagelse: Hvis handlingen navigerer til en ny side eller ændrer URL'en, skal du bruge et <a>-element. Links og knapper er semantisk forskellige. Skærmlæserbrugere navigerer efter elementtype, og de forventer, at knapper udfører handlinger, og at links navigerer.

2. Gør træffladen mindst 44×44 pixels

WCAG 2.5.5 (Level AAA) kræver, at interaktive elementer har en minimumsmålstørrelse på 44×44 CSS-pixels. Det handler ikke om visuel størrelse — det handler om det klikbare område.

Du kan have en lille visuel knap med tilstrækkelig padding, eller du kan udvide træffladen med et pseudo-element. Det afgørende er, at brugeren ikke behøver at ramme præcist.

Mobilbrugere, personer med motoriske funktionsnedsættelser og alle, der bruger en enhed i bevægelse, vil ramme ved siden af små mål. En ikonknap på 24×24 pixels ser måske ren ud, men den er en brugervenlighedsfejl.

3. Sørg for synlige fokustilstande, der ikke kun er browserens standard

Browserens standardfokusring er bedre end ingenting, men den er inkonsekvent på tværs af browsere og ofte usynlig på visse baggrunde. Du har brug for en tilpasset fokustilstand, der fungerer i dit designsystem.

En god fokusindikator har tre egenskaber:

• Høj kontrast: mindst 3:1 mod tilstødende farver
• Synlig afstand: ikke skjult af knappens egen kant eller baggrund
• Konsekvent form: brugere bør genkende den som en fokusindikator på tværs af din grænseflade

Fjern ikke outline: none uden at erstatte det med noget bedre. Og gør ikke fokustilstande så subtile, at kun du kan se dem under perfekte lysforhold.

4. Skriv knapetiketter, der giver mening uden kontekst

Skærmlæserbrugere navigerer ofte ved at hoppe mellem knapper. Når de gør det, hører de en liste over knapetiketter uden omgivende kontekst.

En knap med teksten "Læs mere" er ubrugelig på den liste. Det samme gælder "Klik her" eller "Send". Etiketten bør beskrive handlingen: "Download tjeklisten for tilgængelighed", "Abonnér på opdateringer", "Slet denne kommentar".

Hvis dit design kræver en kort visuel etiket, kan du bruge aria-label til at give et beskrivende alternativ. Men den bedre løsning er at skrive etiketter, der fungerer for alle.

For knapper, der kun består af et ikon, er aria-label obligatorisk. En knap med kun et lupikon har brug for aria-label="Search" eller tilsvarende tekst. Ikonet er ikke tilgængeligt for skærmlæsere.

5. Sørg for tilstrækkelig farvekontrast

WCAG 2.1 kræver et kontrastforhold på mindst 4,5:1 for normal tekst og 3:1 for stor tekst (18pt eller 14pt fed). Knapetiketter er som regel normal tekst.

Lysegrå tekst på en hvid knap fejler. Lyseblå på en lyseblå baggrund fejler. Disse kombinationer kan se sofistikerede ud, men de udelukker brugere med nedsat syn, farveblindhed eller alle, der ser på skærmen i stærkt sollys.

Brug en kontrastkontrol under design, ikke efter lancering. Det er dyrt at rette kontrastproblemer i produktion, fordi det ofte kræver ændringer i designsystemet.

Hvis du arbejder med billedbehandlingsværktøjer, kan client-side processing hjælpe med at bevare privatliv, mens der genereres tilgængelige visuelle assets — især når du tester farvekombinationer eller genererer forhåndsvisningstilstande.

Hvad denne tjekliste ikke dækker

Listen er bevidst ufuldstændig. Den dækker ikke semantik for deaktiverede tilstande, indlæsningstilstande, fejlhåndtering eller komplekse knapmønstre som split buttons eller dropdown-triggere. De mønstre har brug for deres egne retningslinjer.

Den dækker heller ikke det bredere spørgsmål om, hvornår man skal bruge en knap frem for andre interaktive elementer. Til det skal du forstå semantisk HTML og tilgængelighedstræet — emner, der fortjener deres egne artikler.

Det, den dækker, er de lavthængende frugter: de fejl, der dukker op i næsten hver eneste code review, som påvirker flest brugere, og som er lettest at rette under udviklingen.

Sådan integrerer du dette i din arbejdsgang

Tjeklister for tilgængelighed virker kun, hvis de er en del af udviklingsprocessen og ikke blot boltes på bagefter. Sådan får du det til at ske:

I design: Tilføj fokustilstande og annotationer for træfflader til dine designfiler. Lad ikke udviklere gætte sig til dem.

I code review: Tjek for <button>-elementer, aria-label på ikonknapper og CSS for fokustilstande. De er hurtige at få øje på.

I test: Tab dig gennem din grænseflade med tastaturet. Hvis du ikke kan nå en knap eller ikke kan se, hvor fokus er, kan dine brugere heller ikke.

I dokumentation: Inkludér krav til knaptilgængelighed i dit komponentbibliotek. Gør det lettere at gøre det rigtige end at gøre det forkerte.

Hvis du debugger produktionsproblemer, kan værktøjer til at inspicere HTTP headers og redirects hjælpe dig med at forstå, hvordan hjælpeteknologier fortolker din markup — især når du fejlsøger fokusstyring efter navigation.

Prisen for at springe dette arbejde over

Utilgængelige knapper fejler ikke kun WCAG-overholdelse — de ødelægger arbejdsgange. En bruger, der ikke kan klikke på en send-knap, kan ikke udfylde en formular. En bruger, der ikke kan se fokustilstande, kan ikke navigere med et tastatur. En bruger, der ikke kan skelne knaptekst fra baggrunden, kan ikke læse etiketten.

Det er ikke edge cases. Omtrent 15 % af verdens befolkning har en eller anden form for funktionsnedsættelse, og midlertidige begrænsninger (defekt mus, stærkt sollys, at holde en baby) påvirker alle på et tidspunkt.

Den gode nyhed er, at tilgængelighed for knapper for det meste er løste problemer. Du behøver ikke opfinde nye mønstre eller vente på browserunderstøttelse. Du skal bare bruge platformen korrekt og teste dit arbejde.

Vigtige pointer

• Brug <button>-elementer til knapper og <a>-elementer til navigation — den semantiske forskel betyder noget for hjælpeteknologi
• Sørg for, at træfflader er mindst 44×44 CSS-pixels for at tage højde for motoriske funktionsnedsættelser og mobilbrugere
• Sørg for synlige fokustilstande med høj kontrast, der fungerer på tværs af dit designsystem
• Skriv knapetiketter, der giver mening, når de læses isoleret, og brug aria-label til knapper, der kun består af ikoner
• Tjek farvekontrast under design, ikke efter lancering, for at undgå dyre eftermonteringer

FAQ

Q: Kan jeg bruge role="button" på en <div>, hvis jeg tilføjer tastaturhåndteringer?

A: Det kan du, men det bør du ikke. Du skal håndtere Enter, Space, fokusstyring og deaktiverede tilstande manuelt — og du vil uundgåeligt overse noget. <button>-elementet gør alt dette korrekt som standard. Brug det.

Q: Hvad med knapper, der skifter tilstand, som en afspil/pause-knap?

A: Brug aria-pressed="true" eller aria-pressed="false" til at angive den aktuelle tilstand. Knapetiketten bør også afspejle den handling, der sker ved klik ("Pause" under afspilning, "Afspil" når der er sat på pause), ikke den aktuelle tilstand. Skærmlæserbrugere har brug for at vide, hvad knappen vil gøre, ikke hvilken tilstand systemet er i.

Q: Skal deaktiverede knapper opfylde kontrastkrav?

A: WCAG 2.1 undtager deaktiverede kontroller fra kontrastkrav (1.4.3), men det er omdiskuteret. Deaktiverede knapper med dårlig kontrast er svære for alle at opfatte. Hvis du vil vise en deaktiveret knap, så gør den læsbar. Endnu bedre: Skjul den, eller forklar, hvorfor den er deaktiveret.

Q: Hvordan tester jeg tilgængelighed for knapper uden en skærmlæser?

A: Brug dit tastatur. Tab dig gennem grænsefladen, og kontrollér, at du kan nå alle knapper, se hvor fokus er, og aktivere knapper med Enter eller Space. Det fanger de fleste problemer. Til dybere test kan du bruge accessibility inspector i Chrome eller Firefox DevTools til at tjekke den beregnede rolle og etiket.

Q: Hvad er forskellen på aria-label og aria-labelledby?

A: aria-label angiver en tekststreng direkte. aria-labelledby henviser til ID'et på et andet element, hvis tekstindhold bliver etiketten. Brug aria-labelledby, når etiketteksten allerede findes et andet sted i DOM'en. Brug aria-label, når du skal angive en etiket, der ikke er synlig på skærmen.

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