WCAG 2.2 för företag: vad du bör kontrollera på webbplatsen

Kort svar

WCAG är inte bara en checklista för offentlig sektor eller stora e-handlare. Det är ett praktiskt sätt att hitta sådant som gör en webbplats svår att använda: svag kontrast, otydliga formulär, modaler som inte fungerar med tangentbord, länkar utan namn och gränssnitt som bara går att förstå visuellt.

För ett företag räcker det ofta att börja med de delar som faktiskt påverkar affären: kontakt, offertförfrågningar, bokningar, köpflöden, inloggning och viktiga informationssidor.

Vad är WCAG?

WCAG står för Web Content Accessibility Guidelines. Riktlinjerna tas fram av W3C och används internationellt för att bedöma om webbinnehåll är tillgängligt.

Grunden är fyra principer. En webbplats ska vara:

• möjlig att uppfatta
• möjlig att använda
• begriplig
• robust nog att fungera med olika hjälpmedel

Det låter teoretiskt, men i ett vanligt webbprojekt blir det ganska konkret. Går menyn att använda utan mus? Har fält i formulär riktiga etiketter? Syns fokus när man tabbar? Går en modal att stänga? Fungerar felmeddelanden för den som använder skärmläsare?

Vad ändrades med WCAG 2.2?

WCAG 2.2 blev en W3C Recommendation den 5 oktober 2023. Versionen bygger vidare på WCAG 2.1 och lade till nio nya framgångskriterier.

De mest praktiska förändringarna rör bland annat:

• fokus som inte får döljas av sticky headers eller overlays
• tydligare krav på fokusmarkering
• alternativ till drag-and-drop
• minsta storlek på klick- och tryckytor
• konsekvent placering av hjälp
• att användaren inte ska behöva mata in samma information i onödan
• autentisering som inte bygger på kognitiva pussel

För många företag är det här inte extrema specialfall. Det handlar om sådant som finns på nästan varje modern webbplats: menyer, formulär, popups, filter, sliders, cookie-banners, chattwidgets och inloggningar.

Är WCAG ett lagkrav?

WCAG är en standard, inte en svensk lag i sig. Men den används ofta som praktisk referens när tillgänglighetskrav ska omsättas i webb.

För offentlig sektor finns krav via DOS-lagen och standarden EN 301 549, där WCAG-baserade krav är centrala. För vissa produkter och tjänster riktade mot konsumenter gäller också lagen om vissa produkters och tjänsters tillgänglighet, ofta kallad tillgänglighetslagen eller LPTT. Den trädde i kraft 28 juni 2025 och omfattar bland annat e-handel, banktjänster och vissa digitala tjänster.

Alla företag omfattas alltså inte på samma sätt. Men det är en dålig strategi att vänta tills frågan blir juridisk. Tillgänglighetsbrister är ofta samma brister som gör webbplatsen svårare att använda, långsammare att förstå och sämre på att konvertera.

Börja med de kritiska flödena

En WCAG-audit kan bli väldigt stor om man försöker granska allt på en gång. Börja hellre med de sidor och flöden där ett problem faktiskt kostar något.

För en vanlig företagswebb brukar det vara:

• startsida
• tjänstesidor
• kontaktformulär
• offert- eller bokningsflöde
• nyhetsbrev
• inloggning eller kundportal
• viktiga landningssidor från annonser
• dokument eller PDF:er som ofta skickas till kunder

För e-handel är köpresan viktigast. Där har vi skrivit mer specifikt om tillgänglighetslagen för e-handlare och om hur man gör en snabb tillgänglighetskontroll av e-handel.

Test 1: använd bara tangentbord

Det enklaste testet är fortfarande ett av de bästa.

Lägg undan musen. Använd Tab, Shift + Tab, Enter, Space och piltangenter. Gå igenom webbplatsens viktigaste flöde.

Kontrollera:

• syns fokus tydligt hela tiden?
• kommer fokus i rimlig ordning?
• går menyn att öppna och stänga?
• går alla knappar att aktivera?
• fastnar fokus i en modal?
• kan du stänga popups med tangentbord?
• går formulär att fylla i och skicka?

Om det här inte fungerar är problemet inte kosmetiskt. Då kan vissa användare inte genomföra uppgiften.

Test 2: kontrollera kontrast där det spelar roll

Svag kontrast är vanligt i moderna designsystem. Det ser ofta elegant ut i en designfil, men fungerar sämre på mobil, i solljus, på äldre skärmar eller för användare med nedsatt syn.

Kontrollera särskilt:

• brödtext
• länkar
• knappar
• formuläretiketter
• felmeddelanden
• placeholdertext
• priser och annan affärskritisk information
• text ovanpå bilder eller gradienter

Det är inte bara tillgänglighet. Det är läsbarhet.

Test 3: granska formulär hårt

Formulär är ofta där en tillgänglighetsgranskning hittar flest riktiga problem.

Varje fält behöver ett tillgängligt namn. Det ska gå att förstå vad fältet betyder även om man inte ser layouten. Felmeddelanden ska förklara vad som behöver ändras, inte bara markera fältet rött.

Titta på:

• etiketter
• obligatoriska fält
• felmeddelanden
• fokus efter fel
• autokomplettering
• tabbordning
• checkboxar och radioknappar
• integritetstexter

Ett kontaktformulär som inte fungerar med hjälpmedel är inte bara ett WCAG-problem. Det är ett tappat lead.

Test 4: rubriker, länkar och struktur

En sida ska gå att förstå utan att man behöver se den visuella designen.

Det betyder inte att allt måste vara tråkigt. Det betyder att HTML-strukturen ska bära innehållet.

Kontrollera:

• en tydlig H1 per sida
• rimlig ordning på H2 och H3
• länkar som säger vart de leder
• knappar som beskriver handlingen
• bilder med alt-text när bilden tillför information
• dekorativa bilder utan onödig alt-text
• huvudnavigering, brödsmulor och footer som är begripliga

Det här hjälper också SEO och AI-sök, eftersom tydlig struktur gör sidan enklare att tolka.

Test 5: se upp med tredjepartsscript

Många tillgänglighetsproblem kommer inte från den egna koden. De kommer från sådant man lägger ovanpå:

• cookie-banners
• chattar
• formulärverktyg
• bokningssystem
• betalmoduler
• kartor
• videospelare
• personaliseringsverktyg

Det räcker inte att den egna sidan är välbyggd om ett externt formulär saknar fältetiketter eller om en popup inte går att stänga med tangentbord.

Här behöver man vara praktisk. Antingen väljer man en bättre leverantör, konfigurerar verktyget rätt eller bygger en lokal lösning där man har kontroll.

Automatiska tester räcker inte

Lighthouse, axe och liknande verktyg är bra. De hittar kontrastproblem, saknade namn, felaktig ARIA och en del strukturfel.

Men de kan inte avgöra allt.

Ett automatiskt test vet inte alltid om länktexten är begriplig, om felmeddelandet hjälper användaren, om flödet känns logiskt eller om en text är för svår att förstå. Därför bör en rimlig audit kombinera maskinella tester med manuell genomgång.

En praktisk nivå för många företag är:

1. Kör Lighthouse eller axe på viktiga sidtyper.
2. Testa kritiska flöden med tangentbord.
3. Kontrollera formulär och fel.
4. Granska kontrast på mobil.
5. Testa några sidor med skärmläsare.
6. Dokumentera problem med sida, påverkan och prioritet.

Prioritera blockerande problem först

Alla WCAG-avvikelser är inte lika akuta. Börja med sådant som hindrar användaren från att göra något viktigt.

Hög prioritet:

• kontaktformulär som inte går att skicka
• checkout som inte fungerar med tangentbord
• modal som låser fokus
• fält utan tillgängligt namn
• knappar utan begripligt namn
• text med för låg kontrast i viktiga flöden
• felmeddelanden som inte går att uppfatta

Lägre prioritet kan vara förbättringar på dekorativa delar, enstaka mindre strukturproblem eller komponenter som inte påverkar kritiska flöden. De ska också hanteras, men de behöver inte alltid stoppa en lansering.

Bygg in WCAG i processen

Det dyraste sättet att jobba med tillgänglighet är att vänta till slutet.

Gör i stället enkla kontroller i varje fas:

• i design: kontrast, fokus, klickytor och tillstånd
• i frontend: semantik, tangentbord, ARIA och responsivitet
• i content: rubriker, länktexter, alt-texter och begripligt språk
• i QA: riktiga flöden, formulär, modaler och tredjepartsscript

Det gör arbetet mindre dramatiskt. Tillgänglighet blir en del av kvaliteten, inte ett separat projekt som dyker upp när allt redan är byggt.

Sammanfattning

WCAG 2.2 gör tillgänglighet mer konkret för moderna webbplatser. Fokus, tryckytor, formulär, hjälp, autentisering och interaktiva komponenter hamnar tydligare i centrum.

För företag är rätt startpunkt inte att läsa varje kriterium från början till slut. Börja med de flöden som måste fungera: kontakt, köp, bokning, inloggning och viktiga landningssidor. Testa med tangentbord. Granska kontrast. Kontrollera formulär. Titta extra noga på tredjepartstjänster.

Vill ni ha hjälp att hitta och åtgärda tillgänglighetsproblem i en befintlig webbplats? Läs mer om hur vi arbetar som webbkonsult.

Källor: W3C om WCAG 2.2, PTS om tillgänglighetslagen, Digg om WCAG, EN 301 549 och DOS-lagen, Regeringen om tillgänglighetsdirektivet.