Tillgänglighets­direktivet 2025: vad lagen faktiskt kräver av er

Vi arbetar dagligen med tillgänglighet och WCAG i webbprojekt, och det som följer bygger på det arbetet och på vägledningen från Digg och de ansvariga tillsynsmyndigheterna. Det går igenom vem lagen gäller, vad kraven innebär tekniskt och i vilken ordning arbetet brukar göras.

Tillgänglighetsdirektivet, på EU-nivå European Accessibility Act (EAA), direktiv 2019/882, ställer krav på att vissa digitala produkter och tjänster ska gå att använda för personer med funktionsnedsättning. I Sverige har det genomförts genom lagen om vissa produkters och tjänsters tillgänglighet, ofta kallad tillgänglighetslagen (LPTT), som började tillämpas den 28 juni 2025.

Till skillnad från DOS-lagen, som gäller offentlig sektor, riktar sig tillgänglighetslagen mot privata aktörer som erbjuder produkter och tjänster till konsumenter. Därför berör den betydligt fler företag än många räknar med.

Inom EU lever uppskattningsvis 87 miljoner människor med någon form av funktionsnedsättning. När bank, handel, resor och myndighetskontakter flyttade till digitala gränssnitt riskerade den gruppen att stängas ute, samtidigt som medlemsländerna började införa egna tillgänglighetsregler som gjorde det svårare för företag att sälja över gränserna.

Direktivet tar hand om båda problemen genom att samla kraven i en gemensam standard för hela unionen. För ett företag innebär det att samma tekniska nivå gäller oavsett vilket EU-land ni säljer till, vilket också är en förenkling. Direktivet antogs 2019, medlemsländerna skulle ha infört det i nationell lag senast 2022, och reglerna började tillämpas den 28 juni 2025, efter en infasning på sex år.

Den vanligaste förväxlingen vi möter gäller de två svenska tillgänglighetslagarna, som finns parallellt och delvis överlappar men träffar olika aktörer. DOS-lagen, lagen om tillgänglighet till digital offentlig service, gäller sedan 2019 myndigheter, kommuner, regioner och vissa offentligt finansierade aktörer, med Digg som tillsynsmyndighet. Tillgänglighetslagen från 2025 gäller privata aktörer som erbjuder produkter och tjänster till konsumenter.

Ett företag kan i vissa fall omfattas av båda, till exempel en offentligt finansierad aktör som också driver e-handel. Den tekniska måttstocken är i praktiken densamma, WCAG 2.1 nivå AA via den europeiska standarden EN 301 549, men tillsyn, undantag och ansvar skiljer sig. Är ni ett privat företag som säljer till konsumenter är det tillgänglighetslagen ni behöver hålla koll på.

Lagen gäller produkter och tjänster som erbjuds konsumenter, oavsett vem som står bakom dem. Säljer ni en produkt eller tjänst digitalt till konsumenter i Sverige eller övriga EU är utgångspunkten att lagen berör er, och det gäller även företag utanför EU, eftersom det är marknaden ni säljer till som avgör. I praktiken omfattas bland annat:

• e-handel, hela vägen från produktsida och varukorg till kassa och betalning
• banktjänster och andra finansiella tjänster för konsumenter, som inloggning, överföringar och ärenden
• elektronisk kommunikation, som telekomtjänster
• digitala medietjänster, som strömning, e-böcker och nyhetstjänster med prenumeration
• digitala boknings- och biljettflöden för persontransport, liksom självbetjäningsterminaler

Det räcker alltså inte att startsidan fungerar. Hela vägen fram till ett slutfört köp eller ärende ska gå att använda med tangentbord och skärmläsare, och det är ofta i kassan de dyraste bristerna finns, eftersom ett otillgängligt steg där stoppar köpet.

Företag som tillhandahåller tjänster och har färre än tio anställda och en årsomsättning eller balansomslutning på högst två miljoner euro är i regel undantagna. Undantaget gäller alltså inte alla små företag, och det är snävare för den som säljer produkter. Den som växer förbi gränsen omfattas av lagen, och att bygga om en digital plattform i efterhand kostar betydligt mer än att göra rätt från början. Är ni osäkra på om ni omfattas är en juridisk bedömning värd pengarna, eftersom gränsdragningen inte alltid är självklar.

Lagen pekar på den europeiska standarden EN 301 549, som i sin tur bygger på WCAG 2.1 nivå AA (Web Content Accessibility Guidelines). Det är alltså WCAG 2.1 AA som i praktiken är måttstocken för en tillgänglig webbplats eller app. Standarden vilar på fyra principer, och nedan beskriver vi vad de brukar innebära i ett webbprojekt. Hur WCAG är uppbyggt, med nivåer och versioner, går vi igenom i Vad är WCAG?.

Innehållet ska gå att ta till sig med fler än ett sinne. Bilder behöver alt-texter (textalternativ) som en skärmläsare kan läsa upp, medan rent dekorativa bilder markeras så att de hoppas över. Brödtext ska ha en kontrast på minst 4,5:1 mot bakgrunden och stor text minst 3:1, och ljusgrå text på vit bakgrund är en av de vanligaste bristerna vi ser. Video behöver undertexter, ljud behöver transkription, och information får inte förmedlas enbart med färg – ett rött fält räcker inte för att visa ett fel.

Allt som går att göra med mus ska gå att göra med tangentbord, eftersom många med motoriska nedsättningar inte använder mus. Det ska synas tydligt var på sidan fokus befinner sig, inget får blinka på ett sätt som kan utlösa epileptiska anfall, och funktioner som räknar ned eller loggar ut automatiskt måste gå att förlänga.

Menyer och återkommande delar ska bete sig likadant på hela webbplatsen. Ett formulär som avvisar en inmatning ska förklara vad som är fel och hur det rättas, och språket ska vara tydligt, vilket är särskilt viktigt för användare med kognitiva nedsättningar. Här möts tillgänglighet och klarspråk.

Koden ska fungera med hjälpmedel, nu och framöver. Det kräver semantisk HTML, där rubriker är rubriker och knappar är knappar, eftersom skärmläsare bygger sin förståelse på kodens struktur. Egenbyggda komponenter behöver dessutom korrekt märkning, till exempel med WAI-ARIA, för att tolkas rätt.

Nivå AA är den nivå lagen förutsätter. Nivå A räcker inte, och AAA är sällan ett realistiskt krav för en hel webbplats. WCAG 2.2 har funnits sedan 2023 och lägger till ytterligare kriterier, och även om lagen i dag utgår från 2.1 är 2.2 en rimlig nivå att bygga mot för den som vill slippa göra om arbetet.

Allt fler webbplatser byggs med en headless-arkitektur, där innehållet hanteras i ett CMS och visas via ett separat lager byggt med JavaScript-ramverk. Där är det utvecklaren som avgör om koden blir semantisk och tillgänglig, så egenbyggda interaktiva komponenter måste medvetet förses med märkning, fokushantering och tangentbordsstöd. En modern teknisk grund garanterar inte tillgänglighet, men i rätt händer gör den det lättare att bygga rätt från början.

När vi granskar och bygger om webbplatser återkommer samma problem, och de flesta är enkla att åtgärda när man väl ser dem:

• för svag kontrast i text, knappar och formulärfält, ofta för att den grafiska profilen aldrig testats mot WCAG
• bilder utan alt-text, eller med alt-texter som bara upprepar filnamnet
• formulärfält utan kopplade etiketter, så att en skärmläsare inte kan säga vad som ska fyllas i
• egenbyggda menyer, dialogrutor och karuseller som inte går att nå med tangentbord
• fokus som hamnar fel när en dialogruta öppnas, så att användaren tappar bort sig
• video utan undertexter
• rubriknivåer som används för utseendets skull, vilket gör strukturen obegriplig för skärmläsare

Automatiska testverktyg hittar kontrastfel och saknade alt-texter, men om en egenbyggd komponent går att använda med tangentbord måste testas manuellt. En trovärdig granskning kombinerar därför båda.

Ett vanligt missförstånd är att allt måste ha varit perfekt den 28 juni 2025. Från det datumet ska nya och uppdaterade produkter och tjänster som erbjuds konsumenter uppfylla kraven. För vissa befintliga tjänster finns övergångsregler fram till den 28 juni 2030, och självbetjäningsterminaler som togs i bruk före 2025 får i vissa fall användas till slutet av sin ekonomiska livslängd.

Varje ny funktion, sida eller uppdatering ska dock hålla kraven, så efterlevnaden är ett löpande åtagande. Övergångsreglerna är heller inget skäl att vänta: ju längre en otillgänglig plattform lever, desto dyrare blir den att rätta och desto längre stänger den ute kunder.

Granskningen är startpunkten för allt tillgänglighetsarbete, och en seriös granskning kombinerar tre nivåer. Automatiserad testning går snabbt igenom hela webbplatsen och fångar systematiska fel som kontrastproblem, saknade alt-texter och felaktig kodstruktur. Manuell expertgranskning, där någon testar med bara tangentbord, med skärmläsare och mot WCAG:s kriterier ett i taget, hittar de allvarliga brister som hindrar användare. Användartester med personer som använder hjälpmedel varje dag hittar det som varken verktyg eller experter fullt ut förutser.

Resultatet ska vara en prioriterad åtgärdslista: vad som är fel, hur allvarligt det är för användaren och vad som krävs för att rätta det. Det är den listan som gör arbetet möjligt att planera och budgetera.

Tillsynen över tillgänglighetslagen är fördelad på flera myndigheter beroende på tjänst. Post- och telestyrelsen samordnar arbetet och har tillsyn över elektroniska kommunikationstjänster, e-handel och banktjänster, Mediemyndigheten över tjänster som ger åtkomst till audiovisuella medietjänster, som strömning, och Myndigheten för tillgängliga medier över e-böcker. Konsumentverket och Transportstyrelsen delar på tillsynen över vissa passagerartransporttjänster, till exempel webbplatser och appar för tåg, buss, flyg och båt.

Digg har tillsyn över DOS-lagen, och de två lagarna blandas ofta ihop. Myndigheterna kan begära in uppgifter, förelägga om åtgärder och förena förelägganden med vite, och ett ärende börjar ofta med att en användare anmäler en brist.

Vitet är sällan den största risken. Ungefär en av sex människor lever med någon funktionsnedsättning, så en otillgänglig webbplats stänger ute en betydande del av marknaden varje dag den är i drift. En anmälan kan dessutom få större genomslag än själva vitet, och brister som rättas i efterhand innebär ofta att redan lanserade funktioner måste byggas om.

Ansvaret ligger hos den som erbjuder produkten eller tjänsten till konsumenten, även när webbplatsen är byggd av en extern leverantör, så det går inte att avtala bort till byrån. Däremot bör en kompetent leverantör bygga tillgängligt från början och kunna visa hur den arbetar med WCAG, och det är en av de viktigaste frågorna att ställa när ni upphandlar webb.

För ett företag som vill uppfylla lagen är det här en rimlig arbetsordning:

1. Gör en tillgänglighetsgranskning mot WCAG 2.1 AA, både automatiserad och manuell, så att resultatet blir en prioriterad lista.
2. Åtgärda först det som stänger ute användare: tangentbordsnavigering, kontraster, formulär och stöd för skärmläsare. Ett fel som gör det omöjligt att slutföra ett köp väger tyngre än en dekorativ detalj.
3. Bygg in tillgänglighet i design och utveckling, så att nya sidor och funktioner håller samma nivå utan en separat slutkontroll.
4. Utbilda redaktörerna. Rubrikstruktur, alt-texter och tydligt språk avgörs i det dagliga arbetet, och en enda felpublicerad artikel kan göra en välbyggd sida otillgänglig.
5. Informera om hur tjänsten uppfyller kraven, i de allmänna villkoren eller på annat lättåtkomligt sätt, ge användarna ett sätt att rapportera brister och håll informationen uppdaterad.

Tillgänglighetslagen kräver att den som erbjuder en tjänst informerar om hur tjänsten uppfyller tillgänglighetskraven, i de allmänna villkoren eller på annat lättåtkomligt sätt. Informationen ska beskriva hur tjänsten fungerar och vilka metoder för test eller kvalitetssäkring som har använts, och Post- och telestyrelsen har en vägledning för hur den kan utformas.

Den offentliga tillgänglighetsredogörelse som Digg beskriver är formellt ett krav i DOS-lagen, men den är en bra förebild för hur informationen kan ordnas. Enligt Diggs vägledning innehåller den bland annat:

• organisationens och tjänstens namn
• om tjänsten är helt, delvis eller inte förenlig med kraven
• vilket innehåll som ännu inte är tillgängligt, och varför
• eventuella tillgängliga alternativ till det innehållet
• datum för bedömningen och senaste uppdatering, och vilken utvärderingsmetod som använts
• ett sätt för användare att rapportera brister

En ärlig redovisning som medger kända brister ger mer förtroende än en sida som påstår att allt är felfritt.

Tillgänglighet drar åt samma håll som flera saker ni ändå vill uppnå. Att stänga ute var sjätte tänkbar kund är sällan en god affär, och tillgänglig design når också den växande gruppen äldre användare. Semantisk HTML, tydlig struktur, alt-texter och läsbar text gör det lättare för både sökmotorer och AI-tjänster att förstå sidan, och tydliga formulär, begripliga felmeddelanden och robust navigering hjälper alla besökare att slutföra det de kom för.

Därför fungerar tillgänglighet bäst som en del av att bygga en bra digital tjänst, och sämst som en kontroll i slutet.

I våra projekt väger vi in WCAG redan i designfasen: färger och kontraster testas innan de blir en grafisk profil, komponenter utformas för tangentbord från början och strukturen planeras så att den blir logisk både för användaren och för skärmläsaren. I utvecklingen bygger vi med semantisk kod och testar löpande, automatiskt och manuellt.

Eftersom mycket av tillgängligheten avgörs efter lansering hjälper vi också redaktörerna att arbeta tillgängligt, med alt-texter som fungerar, rubriker i rätt ordning och ett begripligt språk. Det är samma arbete som gör en webbplats snabb och lätt att hitta i sök, så de tre brukar förbättras tillsammans.

”Det gäller bara myndigheter.” Nej. Det är just det som skiljer tillgänglighetslagen från DOS-lagen: den gäller privata företag som säljer till konsumenter.

”Ett automatiskt testverktyg räcker.” Verktygen är ett bra första steg men fångar bara en del av kriterierna. Tangentbordsanvändning, fokushantering och begriplighet kräver manuell testning.

”Vi har lagt till en tillgänglighetsknapp, så vi är klara.” Så kallade overlays som lovar automatisk efterlevnad löser sällan de underliggande problemen och kan skapa nya, eftersom kraven gäller webbplatsens faktiska kod och innehåll.

”Det räcker att fixa det en gång.” Varje ny sida, funktion och publicerad artikel kan införa nya brister, så tillgängligheten behöver hållas löpande.

Vi hjälper er att kartlägga och åtgärda brister enligt WCAG 2.1 AA. Läs mer om vårt arbete med tillgänglighet och WCAG.

• Digg — Digital tillgänglighet (Myndigheten för digital förvaltning)
• European Accessibility Act, direktiv 2019/882 (EUR-Lex)
• WCAG 2.1 (W3C)
• Lag (2023:254) om vissa produkters och tjänsters tillgänglighet (Riksdagen)
• Post- och telestyrelsen — lagen om vissa produkters och tjänsters tillgänglighet (tillsynsmyndighet)
• Post- och telestyrelsen — information om tjänstens tillgänglighet (vägledning)

Artikeln är framtagen i informationssyfte och är inte juridisk rådgivning. Rådgör med juridisk kompetens för en bedömning i ert fall. Senast uppdaterad 3 november 2026.