WCAG för icke-utvecklare: det ni ansvarar för

En webbplats som inte går att använda för alla besökare förlorar kunder och förtroende, och i vissa fall bryter den mot lag. Ändå hamnar tillgänglighet ofta hos utvecklarna och blir något som ingen i kommunikationen riktigt äger. Det är synd, eftersom en stor del av det som avgör tillgängligheten ligger i det ni skriver, väljer och publicerar varje vecka.

Den här guiden förklarar vad WCAG är, vilka krav som gäller, vad ni själva kan göra och vad som kräver en utvecklare. Den är skriven för den som ansvarar för en webbplats men inte för koden.

Vad är WCAG?

WCAG står för Web Content Accessibility Guidelines. Det är ett internationellt regelverk från W3C, organisationen bakom webbens standarder, för hur webbinnehåll görs tillgängligt för personer med olika funktionsvariationer: synnedsättning, hörselnedsättning, motoriska svårigheter, kognitiva funktionsnedsättningar och mycket annat.

Det finns flera versioner. WCAG 2.0 kom 2008, 2.1 kom 2018 och 2.2 publicerades i oktober 2023. Varje version bygger på den förra, så en webbplats som följer 2.2 följer i praktiken också de tidigare nivåerna för de flesta kriterier.

Fyra principer

Allt i WCAG utgår från fyra principer, ofta förkortade POUR. Webbplatsen ska vara:

• Möjlig att uppfatta (Perceivable). Informationen ska kunna tas emot även av den som inte ser, hör eller skiljer färger. Exempel: alternativtext till bilder, undertexter till filmer, tillräcklig kontrast.
• Hanterbar (Operable). Allt ska gå att använda, till exempel med enbart tangentbord, och det ska finnas tillräckligt med tid och inga blixtrande element som kan utlösa anfall.
• Begriplig (Understandable). Texten ska vara läsbar och navigeringen förutsägbar. Formulär ska tala om vad som gick fel och hur det rättas.
• Robust (Robust). Innehållet ska fungera med olika webbläsare och hjälpmedel, som skärmläsare.

Tre nivåer

Varje princip har kriterier som är indelade i nivåerna A, AA och AAA:

• A är grundnivån. Det som saknas här stänger ute många helt.
• AA är nivån som i praktiken efterfrågas i lagar, upphandlingar och standarder.
• AAA är den högsta nivån. Den går sällan att uppnå för en hel webbplats, eftersom vissa kriterier inte passar allt innehåll.

När någon säger "vi ska följa WCAG" menar de nästan alltid nivå AA.

Vilka krav gäller i Sverige?

Offentlig sektor

Myndigheter, kommuner, regioner och andra offentliga aktörer omfattas av lagen (2018:1937) om tillgänglighet till digital offentlig service, ofta kallad DOS-lagen. De ska bland annat följa tillgänglighetskraven och publicera en tillgänglighetsredogörelse. Se Tillgänglighetsredogörelse.

Privata företag: lagen (2023:254)

Lagen (2023:254) om vissa produkters och tjänsters tillgänglighet började gälla den 28 juni 2025. Den genomför ett EU-direktiv och omfattar bland annat e-handelstjänster: tjänster som erbjuds på distans via webbplats eller app, där en konsument beställer och ingår ett avtal. Förordningen (2023:676) preciserar tillgänglighetskraven.

Några saker att känna till:

• Ingen särskild webbstandard i själva lagtexten. Lagen presumerar att kraven är uppfyllda om en harmoniserad standard följs. För webben används i praktiken den europeiska standarden EN 301 549, som i sin tur hänvisar till WCAG (nuvarande versioner hänvisar till WCAG 2.1 nivå AA).
• Mikroföretag undantas från kraven för tjänster. Ett mikroföretag har färre än tio anställda och en årsomsättning eller balansomslutning på högst 2 miljoner euro.
• Tillsyn. Post- och telestyrelsen (PTS) har inlett tillsyn av e-handel och har sagt att de börjar med större aktörer och tittar på bland annat startsida, produktsida och sökfunktion. Granskningen sker stegvis.
• Lagen är ändrad flera gånger. Läs alltid den aktuella lydelsen och fråga en jurist om ni är osäkra på om ni omfattas.

Oavsett lagkrav är tillgänglig webb god kommunikation. Fler kan använda er sajt, och det som gör den tillgänglig gör den ofta bättre för alla: tydliga rubriker, läsbara kontraster, enkla formulär och snabba sidor hjälper även den som sitter på en telefon i solen.

Vad kommunikatören ansvarar för

Mycket av tillgängligheten avgörs i redaktionellt arbete, inte i kod. Gå igenom listan för det ni själva producerar.

Bilder och alternativtexter (kriterium 1.1.1)

Varje bild som bär information behöver en alternativtext som beskriver vad den visar eller betyder, så att den som använder skärmläsare får samma information. Skriv inte "bild på", beskriv innehållet och syftet. En bild på ett diagram ska få en text som återger diagrammets poäng, inte bara "diagram".

Rent dekorativa bilder ska ha tom alternativtext så att skärmläsaren hoppar över dem. Text som är en del av en bild, som en logotyp med ord, ska återges i alternativtexten. Undvik text i bilder när det går: den går inte att förstora eller markera.

Rubriker och struktur (1.3.1, 2.4.6)

Använd rubriker för att strukturera texten, i logisk ordning: en huvudrubrik, sedan underrubriker. Välj inte rubriknivå för att den ser stor ut. Skärmläsaranvändare navigerar ofta genom att hoppa mellan rubriker, ungefär som en seende skummar en sida. Samma gäller listor: använd riktiga listor, inte tankstreck på varje rad.

Länktexter (2.4.4)

"Klicka här" och "Läs mer" betyder ingenting för den som hör en lista över sidans länkar. Skriv länktexter som beskriver målet: "Läs vår guide om årsplanering". Undvik flera olika länkar med exakt samma text men olika mål.

Färg och kontrast (1.4.1, 1.4.3)

Vanlig text måste ha en kontrast mot bakgrunden på minst 4,5 till 1. Stor text klarar 3 till 1. Ljusgrå text på vit bakgrund är den vanligaste synden. Kontrollera era färger med ett kontrastverktyg, och gör det redan när ni väljer grafisk profil. Använd inte bara färg för att förmedla information, som "de röda fälten är obligatoriska". Komplettera med text eller symbol.

Språk och begriplighet (3.1.1, 3.1.2)

Skriv klart och enkelt. Förklara förkortningar första gången. Sidans språk ska anges i koden, så att skärmläsare uttalar rätt, och stycken på ett annat språk bör markeras. Se Copywriting för webben.

Videor och ljud (1.2.x)

Filmer behöver undertexter, och ljud behöver en textversion. Det är också användbart för alla som tittar utan ljud. Filmer som har viktig bildinformation behöver dessutom en beskrivning.

Dokument och PDF

PDF-filer och dokument ska vara tillgängliga: med taggade rubriker, alternativtexter och logisk läsordning. En inskannad bild av en text är inte tillgänglig. Fråga er om innehållet verkligen behöver vara en PDF; en vanlig webbsida är ofta lättare att göra tillgänglig.

Formulär och felmeddelanden (3.3.x)

Varje fält ska ha en synlig etikett som är kopplad till fältet, och felmeddelanden ska tala om vad som gick fel och hur det rättas. "Ogiltigt värde" hjälper ingen. "Ange telefonnumret med endast siffror, utan mellanslag eller bindestreck" gör det.

Vad som kräver utvecklare

Vissa saker går inte att lösa i redigeringsverktyget och bör ställas som krav på den som bygger och förvaltar webbplatsen:

• Tangentbordsnavigering (2.1.1). Allt som går att göra med musen ska gå att göra med tangentbordet, i en logisk ordning, utan att fastna.
• Synlig fokusmarkering (2.4.7) som inte döljs av annat innehåll (2.4.11 i WCAG 2.2). Den som navigerar med tangentbord ser var hen är.
• Rätt märkning av komponenter (4.1.2). Knappar, menyer, flikar och dialogrutor måste förmedla namn, roll och tillstånd till hjälpmedel.
• Anpassning vid inzoomning (1.4.4, 1.4.10). Sidan ska fungera när texten förstoras till 200 procent och på en smal skärm utan att innehåll försvinner eller kräver scroll i två riktningar.
• Tillräckligt stora tryckytor (2.5.8, ny i WCAG 2.2). Klickbara ytor bör vara minst 24 gånger 24 pixlar, med undantag.
• Inloggning som inte kräver att man löser kognitiva test (3.3.8, ny i 2.2). Till exempel ska lösenordsfält tillåta inklistring och lösenordshanterare.

Ställ kraven skriftligt när ni upphandlar. Skriv "WCAG 2.2 nivå AA", och be om ett intyg på hur det testats. Se Så väljer ni webbyrå.

Så testar ni själva

Automatiska verktyg hittar en del av felen, men inte alla. Ofta uppskattas det vara långt under hälften, eftersom verktyget inte kan bedöma om en alternativtext är bra eller om ordningen är logisk. Därför behövs en kombination.

1. Automatiskt test (ca 10 minuter)

Kör Lighthouse (finns i Chrome), axe DevTools eller WAVE på era viktigaste sidor. De hittar bland annat saknade alternativtexter, för låg kontrast och formulär utan etiketter. Notera resultatet som ett startvärde.

2. Tangentbordstest (ca 10 minuter)

Lägg undan musen. Gå igenom sidan med Tab (framåt), Skift+Tab (bakåt), Enter och mellanslag. Kan ni nå allt? Syns det var ni är? Går det att stänga en dialogruta med Esc? Fastnar ni någonstans?

3. Zoomtest (ca 5 minuter)

Zooma sidan till 200 procent. Försvinner något? Måste ni scrolla i sidled för att läsa en text?

4. Skärmläsare (ca 20 minuter första gången)

Prova en skärmläsare på en sida: VoiceOver finns i Mac och iPhone, TalkBack i Android och NVDA är gratis för Windows. Det är ovant i början, men även tio minuter ger insikt. Lyssna på sidan med slutna ögon och fråga er om den går att förstå.

5. Läs med fokus på språk

Är texterna begripliga? Finns det jargong utan förklaring? Låt någon utanför läsa.

Dokumentera vad ni hittar, och prioritera: fel som hindrar någon från att genomföra en viktig uppgift (boka, köpa, kontakta) först.

Gör tillgänglighet till en rutin

Tillgänglighet är inget projekt som blir klart. Webbplatsen förändras, och tillgängligheten måste följa med. Några enkla vanor:

• Lägg en kontrollpunkt i publiceringsflödet. Innan en ny sida publiceras: alternativtexter, rubriker, länktexter, kontrast.
• Utbilda dem som publicerar. Trettio minuter räcker för grunderna.
• Testa efter varje större förändring, och minst en gång per år.
• Skriv och uppdatera en tillgänglighetsredogörelse. Se Tillgänglighetsredogörelse.
• Ha en kontaktväg för synpunkter, och svara.

Vanliga frågor