En kort, tydlig checklista för tillgängliga webbknappar

Problemet med råd om knapptillgänglighet

De flesta råd om tillgängliga knappar hamnar i två läger: antingen är det en 40-sidig WCAG-tolkning som ingen läser, eller en vag uppmaning att "göra knappar tillgängliga" utan konkreta steg. Inget av detta hjälper när du ska leverera en funktion på torsdag.

Den här checklistan täcker de fem vanligaste tillgänglighetsbristerna i knappar som vi ser i produktion. Den gör dig inte till WCAG-expert, men den fångar de problem som faktiskt påverkar användare.

1. Använd button-elementet för knappar

Om det fungerar som en knapp bör det vara ett <button>-element. Inte en <div> med onclick, inte en <span> med role="button", inte en <a> med href="#" och preventDefault.

Elementet <button> ger dig tangentbordsnavigering, fokushantering och skärmläsaruppläsningar utan extra arbete. När du använder en <div> bygger du om allt detta från grunden — och du kommer att göra fel.

Det enda undantaget: om åtgärden navigerar till en ny sida eller ändrar URL:en ska du använda ett <a>-element. Länkar och knappar är semantiskt olika. Skärmläsaranvändare navigerar efter elementtyp, och de förväntar sig att knappar utför åtgärder och att länkar navigerar.

2. Gör träffytan minst 44×44 pixlar

WCAG 2.5.5 (Level AAA) kräver att interaktiva element har en minsta målstorlek på 44×44 CSS-pixlar. Det handlar inte om den visuella storleken — det handlar om den klickbara ytan.

Du kan ha en liten visuell knapp med tillräcklig padding, eller utöka träffytan med ett pseudo-element. Det viktiga är att användaren inte behöver sikta exakt.

Mobilanvändare, personer med motoriska funktionsnedsättningar och alla som använder en enhet i rörelse kommer att missa små mål. En ikonknapp på 24×24 pixlar kan se ren ut, men den är ett användbarhetsproblem.

3. Ge synliga fokuslägen som inte bara är webbläsarens standard

Webbläsarens standardring för fokus är bättre än ingenting, men den är inkonsekvent mellan webbläsare och ofta osynlig mot vissa bakgrunder. Du behöver ett eget fokusläge som fungerar i ditt designsystem.

En bra fokusindikator har tre egenskaper:

• Hög kontrast: minst 3:1 mot intilliggande färger
• Synligt avstånd: inte dold av knappens egen kantlinje eller bakgrund
• Konsekvent form: användare ska känna igen den som en fokusindikator i hela gränssnittet

Ta inte bort outline: none utan att ersätta det med något bättre. Och gör inte fokuslägen så subtila att bara du kan se dem under perfekta ljusförhållanden.

4. Skriv knappetiketter som fungerar utan sammanhang

Skärmläsaranvändare navigerar ofta genom att hoppa mellan knappar. När de gör det hör de en lista med knappetiketter utan omgivande sammanhang.

En knapp med etiketten "Läs mer" är värdelös i den listan. Det gäller även "Klicka här" eller "Skicka". Etiketten ska beskriva åtgärden: "Ladda ner tillgänglighetschecklistan", "Prenumerera på uppdateringar", "Ta bort den här kommentaren".

Om din design kräver en kort visuell etikett kan du använda aria-label för att ge ett beskrivande alternativ. Men den bättre lösningen är att skriva etiketter som fungerar för alla.

För knappar som bara består av en ikon är aria-label obligatoriskt. En knapp med endast en förstoringsglasikon behöver aria-label="Search" eller motsvarande text. Ikonen är inte tillgänglig för skärmläsare.

5. Säkerställ tillräcklig färgkontrast

WCAG 2.1 kräver ett kontrastförhållande på minst 4.5:1 för normal text och 3:1 för stor text (18pt eller 14pt fet). Knappetiketter är vanligtvis normal text.

Ljusgrå text på en vit knapp underkänns. Ljusblått på en ljusblå bakgrund underkänns. Dessa kombinationer kan se sofistikerade ut, men de utesluter användare med nedsatt syn, färgblindhet eller alla som tittar på skärmen i starkt solljus.

Använd en kontrastkontroll under designarbetet, inte efter lansering. Att åtgärda kontrastproblem i produktion är dyrt eftersom det ofta kräver ändringar i designsystemet.

Om du arbetar med bildbehandlingsverktyg kan bearbetning på klientsidan hjälpa till att bevara integriteten samtidigt som tillgängliga visuella resurser genereras — särskilt när du testar färgkombinationer eller genererar förhandsvisningslägen.

Vad den här checklistan inte täcker

Den här listan är avsiktligt ofullständig. Den täcker inte semantik för inaktiverade lägen, laddningslägen, felhantering eller komplexa knappmönster som delade knappar eller dropdown-utlösare. De mönstren behöver egna riktlinjer.

Den täcker inte heller den bredare frågan om när man ska använda en knapp jämfört med andra interaktiva element. För det behöver du förstå semantisk HTML och tillgänglighetsträdet — ämnen som förtjänar egna artiklar.

Det den däremot täcker är de lågt hängande frukterna: misstagen som dyker upp i nästan varje kodgranskning, som påverkar flest användare och som är enklast att åtgärda under utveckling.

Så integrerar du detta i ditt arbetsflöde

Tillgänglighetschecklistor fungerar bara om de är en del av utvecklingsprocessen, inte något som läggs till i efterhand. Så här kan du få det att hända:

I design: lägg till fokuslägen och anteckningar om träffytor i dina designfiler. Lämna inte detta åt utvecklare att gissa.

I kodgranskning: kontrollera <button>-element, aria-label på ikonknappar och CSS för fokuslägen. Detta går snabbt att upptäcka.

I testning: tabba dig igenom gränssnittet med tangentbordet. Om du inte kan nå en knapp eller inte kan se var fokus är, kan dina användare inte heller det.

I dokumentation: inkludera tillgänglighetskrav för knappar i ditt komponentbibliotek. Gör det enklare att göra rätt än att göra fel.

Om du felsöker problem i produktion kan verktyg för att inspektera HTTP-headers och redirects hjälpa dig att förstå hur hjälpmedel tolkar din markup — särskilt vid felsökning av fokushantering efter navigering.

Kostnaden för att hoppa över detta arbete

Otillgängliga knappar bryter inte bara mot WCAG-efterlevnad — de bryter arbetsflöden. En användare som inte kan klicka på en skicka-knapp kan inte slutföra ett formulär. En användare som inte kan se fokuslägen kan inte navigera med tangentbord. En användare som inte kan skilja knapptext från bakgrunden kan inte läsa etiketten.

Det här är inte specialfall. Ungefär 15% av världens befolkning har någon form av funktionsnedsättning, och tillfälliga begränsningar (trasig mus, starkt solljus, att hålla i en bebis) drabbar alla förr eller senare.

Den goda nyheten är att knapptillgänglighet till stor del består av lösta problem. Du behöver inte uppfinna nya mönster eller vänta på webbläsarstöd. Du behöver bara använda plattformen korrekt och testa ditt arbete.

Viktiga slutsatser

• Använd <button>-element för knappar och <a>-element för navigering — den semantiska skillnaden är viktig för hjälpmedel
• Säkerställ att träffytor är minst 44×44 CSS-pixlar för att stödja motoriska funktionsnedsättningar och mobilanvändare
• Ge synliga fokuslägen med hög kontrast som fungerar i hela ditt designsystem
• Skriv knappetiketter som är begripliga när de läses isolerat, och använd aria-label för knappar som bara består av en ikon
• Kontrollera färgkontrast under designarbetet, inte efter lansering, för att undvika dyra efteranpassningar

Vanliga frågor

F: Kan jag använda role="button" på en <div> om jag lägger till tangentbordshanterare?

S: Du kan, men du bör inte göra det. Du måste hantera Enter, Space, fokushantering och inaktiverade lägen manuellt — och du kommer oundvikligen att missa något. Elementet <button> gör allt detta korrekt som standard. Använd det.

F: Hur är det med knappar som växlar läge, som en spela/pausa-knapp?

S: Använd aria-pressed="true" eller aria-pressed="false" för att ange aktuellt läge. Knappetiketten bör också spegla åtgärden som sker vid klick ("Pausa" när något spelas, "Spela" när det är pausat), inte det aktuella läget. Skärmläsaranvändare behöver veta vad knappen kommer att göra, inte vilket läge systemet är i.

F: Måste inaktiverade knappar uppfylla kontrastkraven?

S: WCAG 2.1 undantar inaktiverade kontroller från kontrastkrav (1.4.3), men detta är omdiskuterat. Inaktiverade knappar med dålig kontrast är svåra för alla att uppfatta. Om du ska visa en inaktiverad knapp, gör den läsbar. Ännu bättre: dölj den eller förklara varför den är inaktiverad.

F: Hur testar jag knapptillgänglighet utan skärmläsare?

S: Använd tangentbordet. Tabba dig igenom gränssnittet och kontrollera att du kan nå varje knapp, se var fokus är och aktivera knappar med Enter eller Space. Detta fångar de flesta problem. För djupare testning kan du använda tillgänglighetsinspektören i Chrome eller Firefox DevTools för att kontrollera beräknad roll och etikett.

F: Vad är skillnaden mellan aria-label och aria-labelledby?

S: aria-label anger en textsträng direkt. aria-labelledby refererar till ID:t för ett annat element vars textinnehåll blir etiketten. Använd aria-labelledby när etikettexten redan finns någon annanstans i DOM:en. Använd aria-label när du behöver ange en etikett som inte är synlig på skärmen.

Källor

• 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