Tillgänglighetsdirektivet och vägen mot en inkluderande webb
Digital tillgänglighet är inte en specialanpassning för en liten grupp användare. Den påverkar alla som navigerar med tangentbord, förstorar text, använder mobil i starkt ljus, har nedsatt syn eller hörsel, behöver tydliga instruktioner eller tillfälligt saknar möjlighet att använda en mus. En webbplats med begriplig struktur, god kontrast och förutsägbara funktioner blir därför ofta enklare att använda för hela målgruppen, samtidigt som fler kan genomföra ett köp, fylla i ett formulär eller hitta rätt information utan hjälp.
Det europeiska tillgänglighetsdirektivet, European Accessibility Act, började i huvudsak tillämpas i Sverige den 28 juni 2025. För en överblick av lagstiftningens europeiska räckvidd kan du läsa mer om European Accessibility Act på Wikipedia. Den här guiden fokuserar inte på tung juridik, utan på hur kraven kan omsättas i praktiken med WCAG, semantisk HTML, tydlig färgkontrast, tangentbordsnavigering och systematisk testning.
Detta omfattar kraven och berörda verksamheter
Reglerna omfattar utvalda produkter och tjänster som riktar sig till konsumenter. För många företag är e-handel det mest konkreta området, men kraven berör även elektronisk kommunikation, bank- och betaltjänster, e-böcker, vissa tjänster inom audiovisuella medier samt passagerartransport. Svenska myndigheter beskriver dessutom krav på att information, webbplatser, appar, supportfunktioner och gränssnitt ska kunna användas av personer med olika funktionsförmåga. Exakt tillsyn och vissa undantag varierar beroende på sektor.
Den tekniska utgångspunkten är ofta EN 301 549, den europeiska standarden för tillgänglighet inom informations- och kommunikationsteknik. För webbinnehåll hänvisar standarden till WCAG 2.1, där nivå A och AA normalt är den praktiska målnivån. WCAG bygger på fyra principer: innehållet ska vara möjligt att uppfatta, använda, förstå och fungera tillsammans med olika hjälpmedel och tekniker. Digg förklarar relationen mellan EN 301 549 och WCAG och varför standarderna behöver ses som kompletterande verktyg.
Verksamheter behöver också kunna beskriva hur tillgänglighet hanteras, vilka kända brister som finns och hur användare kan få hjälp. En tillgänglighetsredogörelse är därför inte bara ett dokument som tas fram en gång. Den bör kopplas till förvaltning, incidenthantering, releaseprocesser och återkommande tester. Mikroföretag kan omfattas av undantag i vissa delar, och undantag kan även bli aktuella om kraven innebär en oproportionerlig börda eller en grundläggande förändring av tjänsten. Det är ändå klokt att arbeta systematiskt, eftersom sena korrigeringar ofta blir dyrare än förändringar som byggs in i designsystemet från början.
- Inventera vilka digitala tjänster, kundflöden och komponenter som omfattas.
- Dokumentera tillgänglighetskrav i design- och utvecklingsbiljetter.
- Testa återanvändbara komponenter innan de sprids till hela webbplatsen.
- Följ upp brister med ansvarig person, prioritet och planerat åtgärdsdatum.
Färgkontrast och visuell tydlighet som fungerar för alla
Färgkontrast handlar om skillnaden i upplevd ljusstyrka mellan förgrund och bakgrund. WCAG uttrycker detta som ett kontrastförhållande från 1:1 till 21:1. För normalstor text krävs minst 4,5:1, medan stor text normalt ska nå minst 3:1. Samma lägre gräns, 3:1, är central för många gränssnittskomponenter och grafiska objekt som behövs för att förstå eller använda funktionen. Stor text har i WCAG en tydlig definition, så en stor rubrik kan inte automatiskt bedömas som stor enbart för att den ser framträdande ut.
| Situation | Praktiskt riktvärde | Vanligt misstag |
|---|---|---|
| Normalstor brödtext | Minst 4,5:1 | Ljusgrå text på vit bakgrund |
| Stor text | Minst 3:1 | En stor rubrik med för svag färg |
| Knappar och formulärfält | Konturer och visuella tillstånd bör nå 3:1 | Fokus eller kantlinje försvinner mot bakgrunden |
| Länkar i löpande text | Texten ska vara läsbar och länken ska kunna urskiljas | Endast en svag färgskillnad visar att texten är klickbar |
Färg får inte vara det enda sättet att förmedla information. Ett formulärfel bör exempelvis inte enbart markeras med röd text eller röd kantlinje. Lägg även till en tydlig feltext, en begriplig ikon med alternativtext där det behövs och en koppling mellan felet och det aktuella fältet. På samma sätt bör statusar som ”klar”, ”väntar” och ”avvisad” beskrivas med text eller annan identifierande information, inte bara med grönt, gult och rött.
Testa hela paletten i de tillstånd som användaren faktiskt möter: normal knapp, hovring, fokus, inaktiv knapp, felmeddelande, länkar över bilder och text ovanpå gradienter. Gratisverktyg som Colour Contrast Analyser och Contrast Checker kan snabbt hitta uppenbara problem, men automatiska mätningar behöver kompletteras med en visuell och funktionell bedömning. En färg kan uppfylla ett numeriskt krav och ändå skapa otydlighet om hierarkin, storleken eller placeringen är svag.
Semantisk HTML och optimering för skärmläsare
Semantisk HTML innebär att rätt element används för rätt innehåll och funktion. En knapp ska vara en button, en länk ska vara en länk och en huvudmeny ska kunna identifieras som navigering. När innehållets struktur uttrycks i koden kan skärmläsare och andra hjälpmedel presentera rubriker, landmärken, formulärfält och kontroller på ett begripligt sätt. En klickbar div kan ibland se ut att fungera visuellt, men kräver ofta extra kod för fokus, tangentbordsinteraktion, roll, namn och status.
Alternativtext ska beskriva bildens funktion i sammanhanget. En produktbild kan behöva ange modell, färg eller annan information som påverkar köpbeslutet. En dekorativ bild ska i stället ha tom alternativtext så att hjälpmedlet kan hoppa över den. Rubriker bör följa en logisk hierarki, där sidans huvudrubrik följs av relevanta underrubriker utan att nivåer väljs enbart för visuell storlek. Formulär ska ha programmässigt kopplade etiketter, instruktioner nära fältet och felmeddelanden som förklarar vad användaren behöver ändra.
- Använd landmärken som header, nav, main och footer när de beskriver sidans struktur.
- Ge länkar beskrivande namn, inte enbart formuleringar som ”klicka här”.
- Kontrollera läsordningen när innehåll skapas med flexbox, grid eller dynamiska komponenter.
- Exponera namn, roll, tillstånd och värde för interaktiva kontroller.
- Hantera uppdateringar, fel och bekräftelser så att de meddelas hjälpmedel.
Internationell vägledning ger stöd för hur innehåll, design och utveckling kan förenas. I Section508.gov:s guide för tillgänglig webbutveckling betonas bland annat formuläretiketter, tillgängliga felmeddelanden, tangentbordsstyrning, kontrast och kontrollers programmässigt tillgängliga information. ARIA kan vara värdefullt när en egen komponent behöver kompletterande semantik, men det ersätter inte korrekt HTML. Rätt ordning är därför normalt att välja ett inbyggt HTML-element först och använda ARIA endast när behovet är tydligt.
Navigering med tangentbord och synligt fokus i praktiken
En användare ska kunna genomföra hela flödet utan mus. Tab ska flytta fokus framåt, Shift+Tab bakåt och Enter eller mellanslag ska aktivera rätt typ av kontroll. Testa inte bara startsidan. Gå igenom sökning, filtrering, produktval, varukorg, inloggning, formulär, betalning och bekräftelsesida. Om en viktig funktion kräver dra-och-släpp, hovring eller en musgest måste det finnas ett alternativ som fungerar med tangentbord.
Fokusindikatorn ska vara synlig, tydlig och tillräckligt kontrasterad mot omgivningen. Ta inte bort webbläsarens standardfokus utan att ersätta det med en bättre lösning. En tunn, svagt färgad linje kan försvinna på en komplex bakgrund, särskilt när fokus flyttas mellan kort, knappar och formulärfält. Testa också fokusordningen. Den ska följa den visuella och logiska ordningen, inte hoppa från sidhuvud till en dold komponent längre ned i DOM-strukturen.
- Lägg en ”Hoppa till huvudinnehåll”-länk tidigt i sidans fokusordning.
- Kontrollera att menyn kan öppnas, stängas och navigeras utan mus.
- Se till att fokus flyttas till en modal när den öppnas och återgår till rätt utlösande kontroll när den stängs.
- Förhindra fokusfällor där användaren inte kan ta sig ut med tangentbordet.
- Hantera dynamiska meddelanden, exempelvis ”varan har lagts i varukorgen”, på ett begripligt sätt.
WCAG 2.1 beskriver tangentbordsåtkomst och fokus som testbara kriterier, men god tillgänglighet kräver mer än att varje kontroll tekniskt går att nå. Användaren måste förstå var fokus är, vad kontrollen gör och vad som händer efter aktivering. En meny som öppnas utan att fokus flyttas eller utan att öppet tillstånd kommuniceras kan därför fortfarande vara mycket svår att använda.
Steg för steg mot en snabb intern tillgänglighetsgranskning
En intern granskning ersätter inte en fullständig bedömning, men den kan snabbt hitta hinder med hög användarpåverkan. Börja med ett representativt kundflöde och dokumentera både tekniska fel och upplevd svårighet. En återkommande fyrpunktskontroll med zoom, tangentbord, skärmläsare och kontrast ger ett bra första underlag för prioritering.
- Testa zoom och textstorlek. Zooma webbläsaren till 200 procent och kontrollera att text, knappar och formulär fortfarande är synliga och användbara. Innehållet ska behålla en logisk ordning, inte kräva onödig horisontell scrollning och inte hamna bakom fasta sidhuvuden eller dialoger. Testa gärna flera skärmstorlekar och orienteringar.
- Koppla bort musen. Genomför ett helt köp- eller bokningsflöde med Tab, Shift+Tab, Enter och mellanslag. Markera var fokus försvinner, var ordningen blir ologisk och vilka kontroller som inte går att aktivera. Kontrollera särskilt filter, varukorg, rabattkod, betalning och felhantering.
- Slå på en skärmläsare. Använd exempelvis VoiceOver, Narrator, NVDA eller TalkBack beroende på plattform. Lyssna efter rubriker, landmärken, länktexter, alternativtexter, formuläretiketter och dynamiska bekräftelser. Skärmläsartestning kan avslöja problem med läsordning och information som inte syns i en vanlig visuell kontroll.
- Dokumentera och prioritera. Skriv vad som händer, vilken sida och komponent som berörs, vilken användare som påverkas och hur felet kan åtgärdas. Prioritera hinder som stoppar ett köp, gör formulär omöjliga att fylla i eller döljer viktig information. Koppla sedan varje åtgärd till ansvarig, deadline och ett nytt test.
Automatiska verktyg kan upptäcka vissa kod- och kontrastproblem, men de kan inte ensamma avgöra om en alternativtext är relevant, om fokusordningen är begriplig eller om ett felmeddelande hjälper användaren vidare. Manuell testning bör därför ingå i utvecklingsprocessen, inte läggas sist när designen redan är låst. För komplexa JavaScript-komponenter, dokument och betalflöden kan flera kombinationer av webbläsare, operativsystem och hjälpmedel behövas.
Resultatet blir mest användbart när det presenteras som konkreta arbetsuppgifter. ”Tillgängligheten är bristande” säger lite, medan ”fokus försvinner efter färgfilter, återställ fokus till filterknappen när dialogen stängs” går att utveckla, testa och följa upp. På så sätt blir granskningen en del av kvalitetssäkringen i stället för ett separat juridiskt projekt.
Ta kommandot över tillgängligheten och stärk din digitala affär
Tillgänglighet enligt Tillgänglighetsdirektivet och WCAG handlar i grunden om att skapa digitala tjänster som fler kan förstå och använda utan onödiga hinder. God kontrast gör text lättare att läsa, semantisk HTML ger en stabil struktur och tangentbordsnavigering gör funktioner tillgängliga även när musen inte kan användas. Samma förbättringar leder ofta till tydligare gränssnitt, färre supportärenden och smidigare kundflöden för alla.
Nästa steg behöver inte vara ett omfattande ombygge. Börja med ett viktigt kundflöde, testa det metodiskt och åtgärda de mest kritiska hindren. Lägg sedan in tillgänglighetskrav i designsystem, innehållsgranskning, kodgranskning och releasechecklistor. Små, kontinuerliga förändringar ger mätbar effekt över tid, samtidigt som tidiga insatser minskar teknisk skuld, skyddar varumärkets förtroende och gör det möjligt att nå en bredare kundbas.