Så gör du din webbplats tillgänglig: en startguide till WCAG 2.2

För att göra en webbplats tillgänglig bygger du den så att människor kan använda den med tangentbord, skärmläsare, zoom eller en omkopplare, och inte bara med mus: använd riktiga HTML-element för knappar, länkar, rubriker och formulärsetiketter, ge bilder meningsfull alt-text, håll textkontrasten hög och gör fokus synligt. Standarden att sikta mot är WCAG 2.2 nivå AA. Automatiska kontroller fångar en del av problemet; ett tio minuter långt test med tangentbord och skärmläsare fångar mycket av resten.

Vad "tillgänglig" innebär i praktiken

Tillgänglighet handlar om människor: någon som är blind och använder skärmläsare, någon med skakningar som navigerar med tangentbord, någon med nedsatt syn som zoomar till 200 procent, någon som läser i starkt solljus, någon med ett tillfälligt brutet handled. God tillgänglighet brukar göra en sajt bättre för alla: tydligare struktur, läsbar text, formulär som förklarar sina fel.

Referensstandarden är W3C:s Web Content Accessibility Guidelines (WCAG). Från och med september 2026 är den aktuella versionen WCAG 2.2 (publicerad oktober 2023, uppdaterad december 2024); WCAG 3 är ett tidigt utkast. WCAG bygger på fyra principer: innehållet ska vara uppfattbart, användbart, begripligt och robust, och det har tre överensstämmelsenivåer:

Nivå	Vad det betyder	Vem siktar mot den
A	Minimum; utan den kan vissa människor inte använda sajten alls	Alla
AA	Det vanliga målet; omfattar kontrast, fokus, storleksändring, felhantering	De flesta organisationer och många lagar
AAA	Den strängaste; går inte att uppnå för allt innehåll	Specifika tjänster och målgrupper

Lagar på flera håll refererar till WCAG, till exempel European Accessibility Act, som har gällt för många digitala konsumenttjänster i EU sedan juni 2025. Vilka regler som gäller för dig beror på var du verkar och vad du säljer; kontrollera med en rådgivare om du är osäker. Den här guiden täcker det praktiska arbetet.

Alternativ: så kommer du dit

Ansats	Bra för	Avvägning
Bygg in det från början	Nya sajter och appar	Minst arbete totalt; måste sägas från början
Granska och åtgärda	Befintliga sajter	Hittar verkliga problem; kräver ett fokuserat pass per sida
Professionell granskning	Reglerade branscher, stora sajter, offentliga organ	Grundlig och dokumenterad; kostar pengar
Överlägg-widget	Rekommenderas inte	Kan inte åtgärda den underliggande koden

För de flesta små sajter räcker de två första: be AI:n bygga tillgängligt från början och granska sedan före lansering.

De åtgärder som betyder mest

Använd rätt HTML-element

Mycket tillgänglighet kommer gratis med korrekt HTML. En <button> är fokuserbar, fungerar med Enter och mellanslag och upplästs som knapp. En <div> med en klickhanterare är inget av detta. AI-genererad kod använder ibland stylade div:ar för allt; be om semantiska element:

<button> för åtgärder, <a href> för navigering
En <h1> per sida, sedan <h2> och <h3> i ordning; skärmläsaranvändare hoppar mellan rubriker
Landmärken: <header>, <nav>, <main>, <footer>
En <label> kopplad till varje formulärfält
Sidans språk i <html lang="sv">

Använd ARIA-attribut bara när inget inbyggt element passar, till exempel för en egen flikuppsättning eller combobox. Felaktig ARIA är värre än ingen alls.

Tangentbordsåtkomst och synligt fokus

Allt du kan göra med musen måste fungera med enbart tangentbordet (WCAG 2.1.1). Tryck Tab genom sidan: varje länk, knapp och fält ska kunna nås i logisk ordning, och du ska alltid se var fokus är (2.4.7 Focus Visible). WCAG 2.2 lade till att det fokuserade elementet inte får vara helt dolt bakom fästa sidhuvuden eller cookiebanners (2.4.11, nivå AA).

Vanliga fel: menyer som bara öppnas vid hover, modala fönster som inte fångar fokus eller inte kan stängas med Escape, och outline: none i CSS utan något som ersätter den.

Textalternativ

Varje meningsfull bild behöver alt-text som beskriver vad den visar i sitt sammanhang ("Kocken anrättar smakmenyn", inte "bild1.jpg"). Dekorativa bilder får ett tomt alt="" så att skärmläsare hoppar över dem. Knappar med enbart ikon behöver ett tillgängligt namn ("Stäng", "Sök"). Videor behöver undertexter; ljud behöver en transkription.

Färg och kontrast

WCAG 2.2 AA kräver en kontrastkvot på minst 4,5:1 för normal text och 3:1 för stor text (1.4.3), och 3:1 för gränssnittsdelar som inmatningsramar och ikoner med betydelse (1.4.11). Ljusgrå platshållartext och bleka knappar är de vanliga felen. Använd dessutom aldrig enbart färg för att bära betydelse; en röd ram på ett ogiltigt fält behöver även ett felmeddelande.

Storleksändring och omflöde

Text måste förbli användbar vid zoom till 200 procent (1.4.4), och innehållet måste fungera vid en bredd på 320 CSS-pixlar utan att behöva scrollas åt sidan (1.4.10). En ordentligt responsiv layout klarar det mesta av detta.

Träffytor, formulär och fel

Storlek på träffytor: WCAG 2.2 AA kräver att pekarmål är minst 24 gånger 24 CSS-pixlar, eller tillräckligt med avstånd runt mindre (2.5.8). Större är vänligare på telefoner.
Formulär: synliga etiketter (inte bara platshållare), tydliga instruktioner och felmeddelanden som säger vad som är fel och hur man åtgärdar det, bredvid fältet.
Inloggning: tvinga inte människor att lösa ett pussel eller skriva av en kod utan alternativ; tillåt lösenordshanterare och inklistring (3.3.8 Accessible Authentication).

Prompter som fungerar

Bygg den här sajten så att den uppfyller WCAG 2.2 nivå AA: semantiska HTML-landmärken, en h1 per sida med rubriker i ordning, riktiga knapp- och länkelement, etiketter på varje formulärfält, synliga fokusstilar, textkontrast på minst 4,5:1, alt-text på meningsfulla bilder och alt="" på dekorativa, och html lang satt.

Granska sidorna /signup och /checkout för tillgänglighet. Kontrollera användning med enbart tangentbord, fokusordning, synligt fokus, etiketter, felmeddelanden, kontrast och skärmläsarnamn för knappar med enbart ikon. Lista varje problem med WCAG-kriteriet och åtgärda dem utan att ändra den visuella designen mer än nödvändigt.

Mobilmenyn går inte att använda med tangentbord. Gör den till en knapp med aria-expanded, flytta fokus in i menyn när den öppnas, stäng den med Escape och returnera fokus till knappen.

Steg för steg

Kör en automatisk kontroll. Lighthouses avsnitt om tillgänglighet i Chrome DevTools, eller tilläggen axe för webbläsaren, på varje huvudsida. Åtgärda allt det rapporterar.
Koppla bort musen. Tabba genom varje sida och slutför varje viktig uppgift: registrera dig, sök, betala. Notera allt du inte kan nå, inte ser fokus på eller inte kan lämna.
Zooma till 200 procent och gör fönstret smalt, som på en telefon. Inget ska vara avklippt eller kräva sidoscroll.
Prova en skärmläsare i tio minuter: VoiceOver på Mac och iPhone, TalkBack på Android, eller NVDA på Windows (gratis). Lyssna på rubriker, länkar och formulärfält. "Knapp" utan namn, eller "länk, klicka här", betyder arbete att göra.
Kontrollera kontrasten för text, knappar och fält med en kontrastkontroll.
Åtgärda och testa om samma uppgifter.
Publicera ett tillgänglighetsutlåtande som säger vilken standard du siktar mot och hur man rapporterar problem, och svara på rapporterna.

Vanliga misstag

Att förlita sig på en överlägg-widget i stället för att åtgärda koden.
Att ta bort fokusramar för att de ser otrevliga ut, utan ersättning.
Platshållartext som enda etikett. Den försvinner när någon börjar skriva och har ofta låg kontrast.
Länkarna "Klicka här" och "Läs mer". Utan sammanhang hör skärmläsaranvändare en lista med identiska länkar.
Alt-text fylld med nyckelord. Alt-text är till för människor; beskriv bilden.
Att testa en gång. Varje ny funktion kan bryta tangentbordsåtkomsten. Lägg till ett tangentbordspass i din testning före lansering.

Checklista för tillgänglighet

Automatisk kontroll (Lighthouse eller axe) ren på huvudsidorna
Varje uppgift kan slutföras med enbart tangentbord
Fokus alltid synligt och aldrig dolt bakom fästa element
Semantiska rubriker, landmärken, knappar och länkar; lang satt
Meningsfull alt-text; dekorativa bilder alt=""; undertexter på video
Textkontrast ≥ 4,5:1 (stor text ≥ 3:1); gränssnittsdelar ≥ 3:1
Fungerar vid 200 procent zoom och 320 px bredd
Varje formulärfält har en synlig etikett och tydliga felmeddelanden
Tillgänglighetsutlåtande med ett sätt att rapportera problem

För begreppen bakom detta, läs vad är webbtillgänglighet. Tillgänglig design och god design överlappar mycket; hur du designar en snygg app med AI täcker den visuella sidan.

Tillgänglighet på Mythex

Mythex bygger efter vilken standard du begär, så skriv "WCAG 2.2 AA" i din första prompt och i uppföljningar. Du kan använda förhandsvisningens ram i telefonstorlek för att kontrollera små skärmar (Förhandsvisning och kod), men tester med tangentbord, zoom och skärmläsare fungerar bäst på den publicerade URL:en eller en förhandsvisning öppnad i en egen flik. Be agenten granska en sida, åtgärda det den hittar och testa sedan åtgärderna själv; en automatisk genomgång är en början, inte ett godkännande.

Frågor

Vilken tillgänglighetsstandard gäller för webbplatser?

Från och med september 2026 är den aktuella standarden från W3C WCAG 2.2, som först publicerades i oktober 2023. De flesta organisationer och många lagar siktar på nivå AA. WCAG 3 är fortfarande ett tidigt utkast.

Kan ett tillgänglighetsverktyg som överlagrar sidan göra min sajt kompatibel?

Lita inte på ett sådant. Överlägg lägger en verktygsrad ovanpå sidan men kan inte åtgärda saknade etiketter, trasig tangentbordsåtkomst eller dålig struktur i den underliggande koden. Att åtgärda själva sajten är det som gör den användbar.

Hittar automatiska kontroller alla problem?

Nej. Verktyg som Lighthouse och axe fångar sådant som saknad alt-text, låg kontrast och omärkta fält, men många problem, till exempel förvirrande fokusordning, meningslös linktext eller alt-text som finns men är fel, kräver att en person kontrollerar med tangentbord och skärmläsare.

Vilket kontrastvärde kräver WCAG?

WCAG 2.2 nivå AA kräver minst 4,5:1 för normal text och 3:1 för stor text, samt 3:1 för gränssnittskomponenter som inmatningsramar och ikoner som bär betydelse.