Guide till webbtillgänglighet: grunderna i WCAG

01Vem är tillgänglighet till för?

Tillgänglighet förknippas ofta bara med synskadade användare. Omfånget är dock mycket bredare: personer med färgblindhet, de som inte kan använda mus för att handen är bruten, äldre användare, de som tittar på video utan ljud i bullriga miljöer och alla som tittar på telefonskärmen i solsken.

Därför är tillgänglig webbdesign inte extra arbete för en liten grupp utan en bättre upplevelse för alla. Tydliga rubriker, läsbar text och förutsägbar navigering underlättar även för användare utan funktionsnedsättning.

Tillgänglighet stöder dessutom synligheten i sökmotorer. Rätt rubrikhierarki, beskrivande länktexter och bildbeskrivningar överlappar till stor del med det som hjälper sökmotorer att förstå en sida.

02Vad är WCAG?

WCAG (Web Content Accessibility Guidelines) är riktlinjer för tillgängligt webbinnehåll som tas fram inom W3C. Riktlinjerna består av testbara framgångskriterier och delas in i tre nivåer av uppfyllelse: A, AA och AAA. För de flesta organisationer och regelverk är målet nivå AA.

WCAG vilar på fyra grundprinciper. Varje kriterium hör till en av principerna; att förstå principerna är mer användbart än att lära sig kriterierna utantill. Den officiella texten hittar du på sidan W3C WAI.

03Färgkontrast och läsbarhet

På nivå AA krävs minst 4,5:1 i kontrast mellan normal text och bakgrund. För stor text, alltså text på cirka 24 pixlar eller mer eller fet text på 18,5 pixlar eller mer, sjunker kravet till 3:1. Även för gränssnittskomponenter som formulärkanter och ikoner förväntas 3:1.

Vid sidan av kontrasten finns en regel till: ge inte information enbart med färg. Att markera obligatoriska fält bara med en röd stjärna eller skilja länkar åt bara med färg utesluter användare med färgblindhet. Använd understrykning på länkar och förklarande text vid fel.

Textstorleken är också en del av läsbarheten. När användaren förstorar texten i webbläsaren upp till 200 procent ska innehåll inte försvinna och sidan inte gå sönder.

04Navigering med tangentbord

Användare som inte kan använda mus eller som navigerar med skärmläsare tar sig fram på webbplatsen med Tab, Shift+Tab, Enter och piltangenterna. Därför måste menyer, knappar, formulär och popup-fönster gå att använda helt enbart med tangentbord.

• Synlig fokus: elementet som har fokus ska visas med en tydlig ram; ta inte bort fokuslinjen helt med CSS.
• Logisk ordning: tabbordningen ska följa den visuella ordningen.
• Hoppa-till-innehåll-länk: en dold länk i början av sidan som hoppar över menyn till huvudinnehållet.
• Inga fällor: man ska kunna lämna ett öppnat fönster med Esc eller tangentbordet.
• Riktiga knappar: använd taggarna button och a i stället för div för klickbara element.

<a class="atla" href="#icerik">Hoppa till innehållet</a>
<header>...</header>
<main id="icerik">...</main>

05Alternativ text och bilder

Skärmläsare kan inte se bilder; i stället läser de texten i attributet alt. Den alternativa texten ska kort beskriva bildens funktion på sidan. För ett produktfoto räcker produktens namn och särskiljande egenskap; om bilden innehåller text ska den texten också stå i den alternativa texten.

För rent dekorativa bilder används ett tomt alt-värde; då hoppar skärmläsaren över dem. Om en länk eller knapp bara består av en ikon ska det ikonen gör anges med text.

<img src="zeytinyagi.webp" alt="Kallpressad olivolja i en glasflaska på 500 ml">
<img src="dalga-deseni.svg" alt="">
<button aria-label="Öppna menyn">
  <svg aria-hidden="true">...</svg>
</button>

06Formulär och kompatibilitet med skärmläsare

Formulär är platsen där tillgänglighetsproblem oftast uppstår. Varje fält ska ha en synlig och i koden kopplad formuläretikett. Platshållartext som bara står inne i rutan ersätter inte en etikett, eftersom den försvinner när man börjar skriva. Om offertformuläret på en företagswebbplats eller betalsteget i en butik inte går att genomföra med tangentbord och skärmläsare kan den användaren inte bli kund.

För kompatibilitet med skärmläsare ska felmeddelanden kopplas till rätt fält och tydligt säga vad som ska göras: i stället för “Ogiltig inmatning” något som “Telefonnumret måste ha 10 siffror”. Sidans språk ska anges med attributet lang i html-taggen (sv för svenska); annars läser skärmläsaren texten med fel språks regler.

<html lang="tr">
...
<label for="tel">Telefon</label>
<input id="tel" type="tel" autocomplete="tel"
       aria-describedby="tel-hata" aria-invalid="true">
<p id="tel-hata">Telefonnumret måste vara 10 siffror långt.</p>

När ska man använda ARIA?

ARIA-attribut är till för situationer som HTML inte täcker. Första regeln är: om ett inbyggt HTML-element gör jobbet, använd det. Fel använd ARIA kan skapa fler problem än om den inte användes alls.

07Tillgänglighet på mobil och pekskärm

Tillgänglighet på telefon tillför ytterligare frågor. WCAG 2.2 föreskriver på nivå AA minst 24×24 CSS-pixlar för tryckytor; för bekväm användning föredras större ytor. Små länkar som sitter tätt intill varandra leder till felträffar.

Skärmens orientering ska inte låsas, och innehållet ska fungera både i stående och liggande läge. Inställningar som hindrar zoomning ska inte användas. Andra punkter att tänka på på mobil hittar du i inlägget mobilanpassad webbplats och på sidan mobilanpassad design.

08De vanligaste misstagen

På webbplatserna vi har granskat i praktiken samlas tillgänglighetsproblemen oftast kring samma få punkter. Den goda nyheten är att det mesta går att åtgärda med små kodändringar och ger en förbättring som användarna märker direkt.

• Ljusgrå text på ljusgrå bakgrund, alltså otillräcklig kontrast.
• Produktbilder med tom alternativ text eller text som fyllts i med filnamnet.
• Länktexter som inte förklarar sammanhanget, som “Klicka här” eller “läs mer”.
• Rubriknivåer som väljs efter utseende; att hoppa direkt från H1 till H4.
• Rullgardinsmenyer som inte öppnas med tangentbord och popup-fönster som inte går att stänga.
• Bildspel som startar av sig själva och inte går att stoppa, och videor med ljud.
• Att fokuslinjen döljs helt av designskäl.

09Hur testar du din webbplats?

Automatiska verktyg fångar en del av problemen men inte alla. Bäst resultat får du genom att kombinera verktygen med korta manuella tester. Den här kontrollen är en naturlig del av en bra UI/UX-designprocess; skillnaden mellan de två begreppen har vi beskrivit i skillnaden mellan UI och UX.

1. Lägg undan musen och använd sidan bara med Tab och Enter.
2. Ta en tillgänglighetsrapport med Lighthouse i Chromes utvecklarverktyg.
3. Lyssna på några sidor med gratisverktyget NVDA (Windows) eller den inbyggda VoiceOver (macOS, iOS).
4. Förstora texten 200 procent i webbläsaren och se om sidan går sönder.
5. Stäng av bilderna och kontrollera om sidan fortfarande är begriplig.