Allt om lagen om vissa produkter och tjänsters tillgänglighet (LPTT)

En tydlig guide till LPTT, lagen som säkerställer att digitala produkter och tjänster är tillgängliga för alla.

Lagen i korthet

Lagen om vissa produkter och tjänsters tillgänglighet (LPTT) är en svensk lag som bygger på EU:s tillgänglighetsdirektiv. Syftet är att säkerställa att digitala produkter och tjänster är tillgängliga för alla användare, oavsett funktionsförmåga.

Syfte

Lagen säkerställer att digitala produkter och tjänster är tillgängliga för alla användare, oavsett funktionsförmåga.

Krav

Digitala tjänster ska uppfylla WCAG 2.1 nivå AA och följa principerna om uppfattningsbarhet, hanterbarhet, begriplighet och robusthet.

Övervakning

Post- och telestyrelsen (PTS) kontrollerar efterlevnad och kan kräva korrigerande åtgärder eller utfärda viten vid brister.

Tidsplan

Nya och ombyggda digitala tjänster ska vara tillgängliga senast 28 september 2025. Övriga tjänster senast 30 juni 2028.

Vem omfattas av lagen?

Lagen gäller för aktörer som erbjuder digitala produkter eller tjänster till konsumenter. Detta inkluderar:

Offentlig sektor

  • Myndigheter
  • Kommuner
  • Regioner
  • Offentligt finansierade organisationer

Privata aktörer

  • E-handelsplattformar
  • Banktjänster
  • Streamingtjänster
  • Mobilapplikationer
  • Andra digitala tjänster riktade till allmänheten

Produkter och tjänster som omfattas

  • Datorer och operativsystem
  • Bankomater och betalterminaler
  • E-böcker och läsplattor
  • E-handelstjänster
  • Banktjänster för konsumenter
  • Digitala böcker och e-läsare
  • Persontransporttjänster
  • Mobilapplikationer relaterade till dessa tjänster

Komma igång med LPTT - En steg-för-steg guide

Att börja med tillgänglighetsarbetet kan kännas överväldigande. Den här guiden ger er en konkret handlingsplan i fyra steg för att starta resan mot att uppfylla lagen och skapa mer inkluderande tjänster.

Steg 1: Inventera och identifiera

Börja med att skapa en överblick. Vilka av era produkter och tjänster som riktar sig till konsumenter omfattas av lagen?

  • Skapa en lista över alla era webbplatser, mobilappar och e-handelstjänster.
  • Identifiera eventuella fysiska produkter som självbetjäningsterminaler eller e-läsare.
  • Undersök om ni räknas som ett mikroföretag (färre än 10 anställda och under 2 miljoner EUR i omsättning), då ni kan vara undantagna från vissa krav.
  • Dokumentera vilka system som är utvecklade internt och vilka som är från tredjepartsleverantörer.

Steg 2: Genomför en nulägesanalys

När ni vet *vad* som ska granskas är det dags att ta reda på *hur* tillgängligt det är idag. Detta behöver inte vara en fullständig revision från start.

  • Använd automatiserade verktyg som WAVE eller axe DevTools för en snabb första koll.
  • Genomför enkla manuella tester: Kan du navigera hela tjänsten med enbart tangentbordet? Fungerar den bra om du zoomar in 200%?
  • Dokumentera de största och mest uppenbara bristerna i en enkel lista.
  • Fokusera på de viktigaste användarflödena, som att logga in, söka information eller genomföra ett köp.

Steg 3: Skapa en handlingsplan

Med en lista på brister kan ni skapa en prioriterad handlingsplan. Allt måste inte lösas på en gång.

  • Prioritera bristerna. Börja med det som är helt blockerande för användare (t.ex. "går inte att logga in med tangentbord").
  • Bryt ner arbetet i mindre, hanterbara uppgifter och lägg in dem i er befintliga arbetsprocess (t.ex. Jira, Trello).
  • Sätt upp realistiska mål och en tidsplan. Vad ska ni ha åtgärdat inom 3, 6 och 12 månader?
  • Tilldela ansvar för uppgifterna till rätt roller i teamet.

Steg 4: Implementera, testa och förankra

Nu börjar det praktiska arbetet. Se till att hela organisationen är med på tåget.

  • Börja åtgärda bristerna enligt er plan.
  • Testa varje åtgärd för att säkerställa att den faktiskt löste problemet.
  • Utbilda era team i grunderna för tillgänglighet för att undvika att nya barriärer skapas.
  • Kommunicera era framsteg internt för att bygga engagemang och medvetenhet.

Viktigt att tänka på

  • Börja nu: Vänta inte! Genom att starta tidigt minskar ni stress och kostnader.
  • Det är en process: Tillgänglighet är ett kontinuerligt arbete, inte ett engångsprojekt. Sikta på ständig förbättring.
  • Dokumentera ert arbete: Skriv ner vad ni har gjort, vilka beslut ni har tagit och varför. Det är värdefullt vid en eventuell tillsyn.
  • Involvera användare: Det bästa sättet att hitta verkliga problem är att testa med personer med funktionsnedsättningar.

Skillnader mellan tillgänglighetslagar och standarder

De fem regelverken hänger ihop i ett tydligt flöde från övergripande juridisk ramverk till detaljerade tekniska testmetoder:

Jämförelse av regelverk för digital tillgänglighet
Lag/Standard Omfattning Tekniska krav Myndighet Deadline
EU-direktiv 2016/2102 Offentlig sektor i EU WCAG 2.1 AA EU-kommissionen 2018
DOS-lagen
(SFS 2018:1937)
Statliga myndigheters interna webbplatser och appar WCAG 2.1 AA DIGG Nya webbplatser: 23 september 2019.
Befintliga webbplatser: 23 september 2020.
Mobila applikationer: 23 juni 2021.
LPTT
(SFS 2023:254)
Offentliga & privata digitala produkter/tjänster för konsumenter WCAG 2.1 AA PTS, Mediemyndigheten, Konsumentverket, Transportstyrelsen, Myndigheten för tillgängliga medier 28 juni 2025
WCAG 2.1 Webbinnehåll globalt A, AA, AAA W3C Löpande
EN 301 549 Digitala produkter & e-tjänster i EU WCAG 2.1 AA + extra krav ETSI Löpande

Förklaring av lagar och standarder

Det finns flera lagar och standarder som berör digital tillgänglighet. Nedan jämförs dem med fokus på omfattning, tekniska krav, ansvarig myndighet och deadline för efterlevnad.

  • EU-direktiv 2016/2102: Sätter den övergripande ramen i hela EU: offentliga webbplatser och appar måste uppfylla WCAG 2.1 AA. Direktivet trädde i kraft för medlemsstaterna 2018.
  • DOS-lagen (SFS 2018:1937): Sveriges första implementering av direktivet, riktad mot statliga myndigheters interna webbplatser och appar. Speglar samma WCAG 2.1 AA-krav.
  • LPTT (SFS 2023:254): Utvidgar och förankrar direktivet i svensk lag för alla aktörer (offentliga & privata) som erbjuder digitala produkter eller tjänster till konsumenter. Ställer krav på WCAG 2.1 AA med deadlines 28 sep 2025 och 30 jun 2028.
  • WCAG 2.1: Den tekniska standarden från W3C som alla jurdiska dokument pekar på. Definierar kriterier på nivåerna A, AA och AAA för webbinnehåll.
  • EN 301 549: Europeisk standard (ETSI) som paketerar WCAG 2.1 AA plus ytterligare tekniska krav och testmetoder, för enhetlig tillämpning och verifiering i hela EU.

Viktiga verktyg

För att säkerställa att dina digitala produkter och tjänster uppfyller tillgänglighetskraven finns flera användbara verktyg:

Automatiserade testverktyg

WAVE

Identifierar tillgänglighetsproblem direkt i webbsidor

axe DevTools

Webbläsartillägg för tillgänglighetstestning

Accessibility Insights

Verktyg från Microsoft för att testa tillgänglighet

Manuella testverktyg

NVDA

Gratis skärmläsare för Windows

Lighthouse

Inbyggt i Chrome för att testa tillgänglighet

Color Oracle

Simulerar färgblindhet

För olika roller

Tillgänglighet är ett lagarbete där olika roller har olika ansvar. Här hittar du specifik information för din roll:

För produktägare

Så integrerar du tillgänglighet i produktstrategin

Ditt ansvar

Som produktägare har du ansvar för att säkerställa att tillgänglighet prioriteras genom hela produktutvecklingsprocessen, från planering till lansering.

  • Inkludera tillgänglighetskrav i produktspecifikationer
  • Avsätta resurser för tillgänglighetstestning
  • Säkerställa att tillgänglighet är en del av definition of done
  • Förstå affärsnyttan med tillgänglighet

Viktiga verktyg

  • Tillgänglighetsbudget i projektplanen
  • Användarundersökningar med personer med funktionsnedsättningar
  • Tillgänglighetspolicy för organisationen

Vanliga frågor för produktägare

Om tillgänglighet integreras från början behöver det inte ta mycket extra tid. Räkna med 10-15% extra i början, men detta minskar när teamet blir mer vant.

Att se tillgänglighet som en "extra funktion" eller något som kan läggas till i slutet av projektet. Tillgänglighet bör vara en integrerad del av hela utvecklingsprocessen.

Börja med WCAG 2.1 A-kriterier, följt av AA. Prioritera krav som påverkar stora användargrupper eller är lagstadgade.

Mät ökad användarbas, minskad supportkostnad, förbättrad SEO, och minskad risk för rättsliga åtgärder.

Vid projektstart för att sätta upp riktlinjer, vid större designbeslut, och för att genomföra granskningar innan lansering.

För designers

Så skapar du tillgängliga designlösningar

Ditt ansvar

Som designer har du ansvar för att skapa gränssnitt som är tillgängliga för alla användare, oavsett funktionsförmåga.

  • Säkerställa tillräcklig kontrast mellan text och bakgrund
  • Designa för olika inmatningsmetoder (mus, tangentbord, röst)
  • Skapa tydliga fokustillstånd för tangentbordsnavigering
  • Använda tydliga och konsekventa designmönster

Viktiga verktyg

  • Kontrastcheckers (WebAIM, Stark)
  • Färgblindhetssimulering (Color Oracle)
  • Tillgängliga designsystem och komponenter

Vanliga frågor för designers

WCAG 2.1 AA kräver en kontrastkvot på minst 4,5:1 för normal text och 3:1 för stor text (18pt eller 14pt bold).

Säkerställ tydliga fokustillstånd för alla interaktiva element. Fokusordningen ska följa en logisk ordning, vanligtvis från vänster till höger, uppifrån och ned.

Undvik att enbart använda färg för att förmedla information. Kombinera alltid färg med text, form eller mönster för att säkerställa att information är tillgänglig för färgblinda.

Minst 44x44 pixlar för att vara tillgängliga för personer med motoriska svårigheter, enligt WCAG 2.1 AAA.

Använd tydliga etiketter, gruppera relaterade fält, ge tydlig felhantering och tillräckligt med utrymme mellan fält.

För utvecklare

Så implementerar du tillgänglig kod

Ditt ansvar

Som utvecklare har du ansvar för att implementera tillgänglig kod som fungerar med olika hjälpmedel och följer standarder.

  • Använda semantisk HTML
  • Implementera ARIA-attribut korrekt
  • Säkerställa tangentbordsnavigering
  • Testa med skärmläsare

Viktiga verktyg

  • ESLint med tillgänglighetsregler
  • Skärmläsare (NVDA, VoiceOver)
  • axe DevTools för automatiserad testning

Vanliga frågor för utvecklare

Använd ARIA endast när semantisk HTML inte räcker till. Följ principen "No ARIA is better than bad ARIA". Använd ARIA för att förtydliga roller, tillstånd och egenskaper för komplexa komponenter.

Koppla bort musen och navigera genom hela webbplatsen med endast tangentbordet. Säkerställ att alla interaktiva element kan nås och användas, och att fokusordningen är logisk.

Saknade alt-texter för bilder, felaktig rubrikstruktur, avsaknad av etikett för formulärfält, och otillräcklig kontrastkvot är några av de vanligaste felen.

Använd ARIA live regions (aria-live) för att meddela skärmläsare om dynamiska ändringar. Använd olika värden (polite, assertive) beroende på hur viktigt meddelandet är.

Använd role="dialog", aria-modal="true", och hantera fokus korrekt (fånga och behåll fokus inom dialogen). Säkerställ att dialogen kan stängas med både Escape-tangenten och en stängknapp.

För testare

Så testar du för tillgänglighet

Ditt ansvar

Som testare har du ansvar för att verifiera att produkten uppfyller tillgänglighetskraven och fungerar med olika hjälpmedel.

  • Genomföra automatiserade tillgänglighetstester
  • Utföra manuella tester med hjälpmedel
  • Dokumentera och prioritera tillgänglighetsproblem
  • Verifiera att åtgärder faktiskt löser problemen

Viktiga verktyg

  • Automatiserade testverktyg (axe, WAVE)
  • Skärmläsare (NVDA, VoiceOver)
  • Tangentbordstestning
  • Checklistor baserade på WCAG

Vanliga frågor för testare

Automatiserade tester kan hitta cirka 30-40% av tillgänglighetsproblemen. Resten kräver manuell testning. Använd automatiserade verktyg som en första kontroll, men förlita dig inte enbart på dem.

Tangentbordsnavigering, skärmläsartester, zoom/förstoring upp till 200%, och tester med olika färginställningar är grundläggande manuella tester.

Prioritera efter: 1) Lagkrav, 2) Blockerande problem för användare med funktionsnedsättningar, 3) Vanliga användningsfall, 4) Mindre problem som påverkar få användare.

Testa med minst NVDA på Windows och VoiceOver på macOS/iOS. Om möjligt, testa även med JAWS (Windows) och TalkBack (Android).

Kontrollera att alla fält har associerade etiketter, att felmeddelanden är tydliga och kopplade till rätt fält, och att formuläret kan fyllas i och skickas med endast tangentbordet.

Rapportera era tillgänglighetsbrister till PTS

Som företag eller organisation kan ni proaktivt rapportera kända tillgänglighetsbrister i era produkter och tjänster till Post- och telestyrelsen (PTS). Detta visar på transparens och ansvarstagande.

Rapportera brister i era tjänster

Har ni identifierat tillgänglighetsproblem i era digitala tjänster som webbplatser, mobilappar, e-handelslösningar eller andra digitala tjänster? Rapportera dessa till PTS.

Exempel på brister att rapportera:

  • Bristande kontrast på webbplatsen
  • Problem med tangentbordsnavigering
  • Saknade alternativtexter för bilder
  • Otillgängliga formulär eller funktioner
  • Kompatibilitetsproblem med hjälpmedel

Rapportera brister i era produkter

Tillverkar eller säljer ni fysiska produkter som bankomater, betalterminaler, e-läsare eller andra produkter som omfattas av lagen? Rapportera kända tillgänglighetsbrister.

Exempel på brister att rapportera:

  • Bankomater utan talsyntes eller taktila funktioner
  • Betalterminaler som inte är tillgängliga
  • E-läsare med bristande tillgänglighetsfunktioner
  • Datorer eller operativsystem med tillgänglighetsproblem
  • Andra fysiska produkter enligt LPTT

Varför rapportera era egna brister?

Proaktiv rapportering av tillgänglighetsbrister visar att ert företag tar ansvar och arbetar aktivt för att förbättra tillgängligheten.

Fördelar med proaktiv rapportering:

  • Visar på transparens och ansvarstagande gentemot PTS
  • Kan minska risken för sanktioner vid tillsyn
  • Skapar en konstruktiv dialog med tillsynsmyndigheten
  • Hjälper PTS att förstå branschens utmaningar och behov
  • Demonstrerar att ni arbetar aktivt med tillgänglighetsfrågor
  • Kan ge er tid att planera och genomföra åtgärder

PTS tar emot er rapport och kan komma att följa upp med er om åtgärdsplaner och tidsramar. Proaktiv rapportering visar på ert engagemang och kan påverka hur PTS hanterar eventuella tillsynsärenden positivt.

Beskriv bristerna detaljerat, ange vilka produkter eller tjänster som berörs, hur allvarliga bristerna är, och om möjligt era planer för att åtgärda problemen. Inkludera även tidsramar för när åtgärder planeras.

Det finns ingen laglig skyldighet att rapportera egna brister, men det är starkt rekommenderat. Fokusera på allvarligare brister som påverkar användarnas möjlighet att använda era produkter eller tjänster.

Proaktiv rapportering och tydliga åtgärdsplaner kan visa på ert engagemang för tillgänglighet, vilket PTS kan ta hänsyn till vid bedömning av eventuella sanktioner. Det är dock ingen garanti för att undvika påföljder.

Det finns ingen fast frekvens, men det är bra att rapportera när ni identifierar nya allvarliga brister eller när ni har genomfört större förändringar i era produkter eller tjänster. Regelbunden kommunikation bygger förtroende.

Informera era kunder om tillgänglighet

Som företag eller organisation har ni skyldighet att informera era kunder om tillgänglighetsfunktioner och eventuella brister i era produkter och tjänster enligt LPTT.

Vad ska ni informera om?

Obligatorisk information:

  • Vilka tillgänglighetsfunktioner som finns i produkten eller tjänsten
  • Kända tillgänglighetsbrister och begränsningar
  • Hur kunder kan rapportera tillgänglighetsproblem
  • Kontaktinformation för tillgänglighetsfrågor
  • Information om alternativa lösningar när det är möjligt

Var ska informationen finnas?

  • På er webbplats, gärna på en dedikerad tillgänglighetssida
  • I produktdokumentation och användarguider
  • I mobilappar, helst i inställningar eller hjälpsektion
  • Vid försäljningsställen för fysiska produkter

Exempel på information

För digitala tjänster:

  • "Vår webbplats stöder skärmläsare och tangentbordsnavigering"
  • "Alla videor har undertexter tillgängliga"
  • "Känd brist: Vissa PDF-dokument är inte fullt tillgängliga"
  • "Kontakta oss på tillganglighet@företag.se för hjälp"

För fysiska produkter:

  • "Bankomaten har talsyntes och taktila knappar"
  • "E-läsaren stöder textförstoring och högkontrast"
  • "Betalterminalen har höjdjusterbar skärm"
  • "Instruktioner finns i punktskrift på begäran"

Rapportering från kunder

Ni ska informera era kunder om hur de kan rapportera tillgänglighetsproblem. Kunder kan också rapportera direkt till PTS.

Vad kunder kan rapportera:

  • Tillgänglighetsproblem de stöter på
  • Funktioner som inte fungerar med hjälpmedel
  • Brister i tillgänglighetsinformation
  • Problem med alternativa lösningar

Resurser och mallar för tillgänglighetsinformation

Här hittar ni användbara resurser och mallar för att skapa er egen tillgänglighetsinformation som uppfyller LPTT:s krav.

Inspiration från svenska företag:

Se hur andra svenska företag har skrivit sina tillgänglighetsredogörelser:

Tips för att skriva bra tillgänglighetsinformation:

  • Använd tydligt och enkelt språk
  • Var konkret om vilka funktioner som finns
  • Erkänn kända brister och berätta om era planer
  • Ge tydlig kontaktinformation
  • Uppdatera informationen regelbundet

Informationen ska vara tillräckligt detaljerad för att kunder ska förstå vilka tillgänglighetsfunktioner som finns och eventuella begränsningar. Använd tydligt och begripligt språk, undvik teknisk jargong.

Ja, informationen ska hållas aktuell. När ni förbättrar tillgängligheten eller identifierar nya brister ska informationen uppdateras. Det är god praxis att revidera informationen minst en gång per år.

Bristfällig information till kunder kan ses som en överträdelse av LPTT. PTS kan kräva att ni förbättrar informationen och i värsta fall utfärda sanktioner.

Om ni erbjuder era produkter eller tjänster på flera språk bör tillgänglighetsinformationen också finnas på dessa språk. Detta säkerställer att alla kunder kan ta del av informationen.

Ni bör ha rutiner för att ta emot, dokumentera och hantera kundrapporter. Svara snabbt, undersök problemen och informera kunden om vilka åtgärder ni planerar. Detta visar på professionalism och engagemang.

Tredjepartslösningar och kravställning

Många digitala tjänster byggs med komponenter från externa leverantörer, som chattfunktioner, betallösningar eller inbäddade videospelare. En vanlig fråga är: vem har ansvaret för tillgängligheten? Svaret är tydligt – det är ni som tillhandahåller tjänsten till slutkunden som har det yttersta ansvaret.

Ditt ansvar upphör inte

Även om en funktion levereras av en tredje part, är den en del av er tjänst. Enligt LPTT kan ni inte friskriva er från ansvaret bara för att ni inte har byggt komponenten själva. Om en tredjepartskomponent är otillgänglig, är er tjänst i sin helhet inte fullt tillgänglig.

Vad innebär detta i praktiken?

  • Inköpsprocessen: Tillgänglighet måste vara ett grundkrav när ni väljer nya system och leverantörer.
  • Befintliga avtal: Granska era nuvarande avtal och inled en dialog med era leverantörer om deras planer för att möta LPTT.
  • Riskminimering: Att använda en otillgänglig tredjepartslösning utgör en juridisk och affärsmässig risk.

Så kravställer du på leverantörer

Använd er position som kund för att driva på för bättre tillgänglighet. Inkludera tydliga krav i era upphandlingar och avtal. Detta skyddar er juridiskt och hjälper hela marknaden att bli mer tillgänglig.

Exempel på krav att ställa:

  • Produkten/tjänsten ska uppfylla alla relevanta kriterier i WCAG 2.1 nivå AA.
  • Leverantören ska kunna uppvisa en tillgänglighetsredogörelse eller VPAT (Voluntary Product Accessibility Template) som beskriver kända brister.
  • Leverantören ska ha en tydlig handlingsplan (roadmap) för att åtgärda kända brister.
  • Tillgänglighet ska vara en del av leverantörens ordinarie testprocess.

Kopiera och använd: Kravtext för avtal

Här är ett förslag på text som ni kan inkludera i era avtal och upphandlingar för att säkerställa att leverantörer tar ansvar för tillgänglighet. Anpassa den efter era behov.

Krav på tillgänglighet enligt Lagen om vissa produkter och tjänsters tillgänglighet (SFS 2023:254)

Leverantören garanterar att den erbjudna produkten/tjänsten, inklusive all tillhörande dokumentation och support, uppfyller samtliga tillämpliga krav i standarden EN 301 549 (senaste versionen), vilket inkluderar samtliga kriterier på nivå A och AA i Web Content Accessibility Guidelines (WCAG) 2.1, eller senare version som refereras i standarden.

Leverantören ska på begäran kunna tillhandahålla en detaljerad tillgänglighetsredogörelse (Accessibility Conformance Report) baserad på VPAT-formatet (Voluntary Product Accessibility Template) eller motsvarande, som tydligt redovisar produktens/tjänstens efterlevnad av nämnda krav.

Eventuella avvikelser från kraven ska dokumenteras och åtföljas av en bindande handlingsplan med tidsatta åtgärder för att uppnå full efterlevnad. Denna handlingsplan ska godkännas av kunden.

Underhåll av tillgänglighet vid uppdateringar och support

Leverantören förbinder sig att bibehålla minst samma nivå av tillgänglighet vid samtliga framtida uppdateringar, releaser och ändringar av produkten/tjänsten. Nya funktioner som introduceras under avtalsperioden ska från start uppfylla samma tillgänglighetskrav som specificerats ovan.

Om kunden eller slutanvändare rapporterar en tillgänglighetsbrist ska denna hanteras av leverantören med samma prioritet som en funktionskritisk bugg, om inte annat avtalats. Leverantören ska inom [X] arbetsdagar återkomma med en analys och en plan för åtgärd.

Vanliga frågor

Här hittar du svar på de vanligaste frågorna om lagen om vissa produkter och tjänsters tillgänglighet.

LPTT implementerar EU:s tillgänglighetsdirektiv i svensk lag. Syftet är att alla oavsett funktionsförmåga ska komma åt digitala produkter och tjänster. Tillgänglighet gynnar fler användare, stärker varumärket och minskar juridiska risker.

Lagen gäller digitala produkter och tjänster riktade till konsumenter, t.ex. webbplatser, mobilappar, e-handel, bank- och betaltjänster, e-böcker, audiovisuell media samt självbetjäningsterminaler som bankomat.

Se fullständig lista över produkter och tjänster på sektionen “Vem omfattas”.

DOS-lagen (Lagen om tillgänglighet till digital offentlig service) gäller endast offentliga aktörer och deras webbplatser och appar. LPTT har ett bredare omfång och omfattar både offentliga och privata aktörer samt fler typer av produkter och tjänster, inklusive e-handel, banktjänster och e-böcker.

WCAG är tekniska riktlinjer från W3C som anger hur webbinnehåll och mobilappar ska göras tillgängliga, indelade i nivåerna A, AA och AAA, och fokuserar främst på webbinnehåll.

EN 301 549 är en europeisk standard som bygger på WCAG 2.1 nivå AA men utökar omfattningen till all ICT-teknik - inklusive hårdvara, programvara, dokument och telekomutrustning - och lägger till specifika testmetoder för offentlig upphandling inom EU.

Medan WCAG är en global riktlinje används EN 301 549 som referensram för juridisk efterlevnad i EU och vid offentliga upphandlingar, där den fungerar som WCAG med extra kriterier för olika ICT-komponenter.

Nya och ombyggda digitala tjänster ska vara tillgängliga senast 28 juni 2025. Det är dock klokt att börja arbeta med tillgänglighet så snart som möjligt.

Post- och telestyrelsen (PTS) kan utfärda förelägganden och viten mot aktörer som inte följer lagen. Storleken på vitet beror på överträdelsens allvarlighet och företagets storlek.

Här är de viktigaste punkterna från lagtexten om sanktionsavgifter:

  • Avgiftens storlek: Sanktionsavgiften är på minst 10 000 kronor och högst 10 000 000 kronor.
  • Bedömning: Beloppet bestäms med hänsyn till överträdelsens allvar och omfattning. Avgiften kan sänkas eller tas bort helt om det finns särskilda skäl eller om det skulle vara oskäligt att ta ut den.
  • Undantag för ringa fall: Om överträdelsen anses vara ringa (mindre allvarlig) ska ingen sanktionsavgift beslutas.
  • Vite och sanktionsavgift: En sanktionsavgift får inte beslutas för en överträdelse som redan ligger till grund för en ansökan om att döma ut ett vite. Man kan alltså inte straffas med båda för samma sak.
  • Betalning: Avgiften ska betalas inom 30 dagar efter att beslutet vunnit laga kraft. Om den inte betalas lämnas den för indrivning hos Kronofogden.
  • Preskriptionstid: En sanktionsavgift kan inte beslutas om det har gått mer än fem år sedan överträdelsen upphörde.

Sanktionsavgiften tillfaller staten.

Lagen hänvisar till WCAG 2.1 nivå AA som minimikrav. WCAG 2.2 innehåller ytterligare krav som inte är obligatoriska enligt lagen, men som kan förbättra tillgängligheten ytterligare. Det är dock en god idé att implementera WCAG 2.2 eftersom det representerar den senaste standarden.

Ja, det finns vissa undantag. Till exempel omfattas inte innehåll som tillhandahålls av tredje part som inte finansieras eller utvecklas av den berörda aktören. Det finns också undantag för oproportionerlig börda, men detta måste motiveras och dokumenteras noggrant.

Om din organisation erbjuder digitala produkter eller tjänster till konsumenter, omfattas ni sannolikt av lagen. Detta inkluderar e-handelssajter, banktjänster, e-böcker, mobilappar och andra digitala tjänster. Vid osäkerhet, kontakta PTS för vägledning.

"Oproportionerlig börda" innebär att kostnaden eller arbetsinsatsen för att göra en produkt eller tjänst tillgänglig är orimligt stor i förhållande till nyttan. Detta måste dock motiveras och dokumenteras noggrant. Faktorer som organisationens storlek, resurser och karaktären på produkten eller tjänsten vägs in i bedömningen.

Till skillnad från DOS-lagen kräver inte LPTT en formell tillgänglighetsredogörelse. Dock är det god praxis att dokumentera tillgänglighetsarbetet och eventuella kända brister. Detta kan vara värdefullt vid en eventuell granskning från PTS.

Börja med en nulägesanalys av era produkter och tjänster. Identifiera vilka som omfattas av lagen och genomför en tillgänglighetsgranskning. Utbilda personal, särskilt utvecklare, designers och innehållsskapare. Skapa en handlingsplan med prioriterade åtgärder och tidsplan.

WCAG har tre nivåer av tillgänglighetskrav:

  • Nivå A: Grundläggande tillgänglighetskrav som måste uppfyllas.
  • Nivå AA: Mer omfattande krav som adresserar de största hindren för användare med funktionsnedsättningar. Detta är den nivå som krävs enligt LPTT.
  • Nivå AAA: Den högsta nivån med mycket detaljerade krav. Denna nivå är inte ett lagkrav men kan vara relevant för vissa specialiserade tjänster.

PTS gör stickprov, granskar anmälningar och kan kräva korrigerande åtgärder eller utfärda viten. Om du vill anmäla brister, besök rapporteringstjänsten.

Om sajten

Allt om LPTT är skapad av Amin Amini som är tillgänglighetsspecialist på Axess Lab.

Syftet med sidan är att sprida kunskap om lagen om vissa produkter och tjänsters tillgänglighet (LPTT) och hjälpa organisationer att förstå och uppfylla kraven.

Kontakta mig

Har du frågor om LPTT eller behöver du hjälp med tillgänglighetsarbetet? Kontakta mig, Amin Amini.

Skicka e-post

För frågor och funderingar, kontakta mig på:

Följ mig

Följ mig på Linkedin för uppdateringar och nyheter om tillgänglighet.