Hoppa till innehåll
Compliance & lag

EAA / Tillgänglighetslagen 28 juni 2026 — slutchecklista

Senast uppdaterad: 2026-06-01

6 min läsningAv Simon Forsell, grundare av Northverify

Snabbsvar

Tillgänglighetslagen (EAA) träder i kraft den 28 juni 2026 — alla privata aktörer med digitala produkter och tjänster som riktar sig till konsumenter måste uppfylla WCAG 2.1 AA. Tre saker är absolut nödvändiga: publicerat tillgänglighetsutlåtande, tekniskt WCAG 2.1 AA-test utfört, och en återkopplingsmekanism på webbplatsen. PTS (Post och Telestyrelsen) är tillsynsmyndighet och kan utfärda vitesförelägganden från dag ett.

Tillgänglighetslagen träder i kraft 28 juni 2026

⏱ Nedräkning: 28 juni 2026. Tillgänglighetslagen (EAA) gäller från detta datum. Alla privata digitala tjänster riktade till konsumenter i EU måste uppfylla WCAG 2.1 AA.

Den europeiska tillgänglighetslagen (European Accessibility Act, EAA) implementerades i Sverige via Tillgänglighetslagen. Från och med 28 juni 2026 gäller lagen för privata aktörer med digitala produkter och tjänster — webbplatser, appar, e-handelsbutiker, digitala tjänster — riktade till konsumenter.

För offentlig sektor har WCAG-kraven gällt sedan 2019 (DOS-lagen). Nu är det de privata aktörernas tur. PTS (Post och Telestyrelsen) är utsedd tillsynsmyndighet och kan utfärda vitesförelägganden från dag ett.

Det finns ingen officiellt kommunicerad nådeperiod. Läs det som att fristen är riktig.


Vad MÅSTE vara klart 28 juni?

Tre saker är juridiskt obligatoriska från 28 juni 2026 och kan inte skjutas upp:

1. Tillgänglighetsutlåtande — En skriftlig självdeklaration om din webbplats/apps tillgänglighet, publicerad på en permanent URL, länkad från footern. Utlåtandet ska dokumentera kända brister, när de ska åtgärdas, och en återkopplingskanal. Generera ditt på /verktyg/tillganglighetsutlatande.

2. Återkopplingsmekanism — Webbplatsen måste ha ett sätt för användare att rapportera tillgänglighetsproblem och begära alternativa format. Det kan vara ett formulär, en e-postadress, eller en länk — men det måste finnas och faktiskt fungera.

3. Grundläggande WCAG 2.1 AA-efterlevnad — Inte nödvändigtvis 100 % felfri (det är sällsynt), men du ska kunna visa att du aktivt arbetar med tillgänglighet och att de grövsta bristerna är identifierade och på väg att åtgärdas. Dokumentation av testning och åtgärdsplan är avgörande.


Slutchecklista — 12 punkter att bocka av

Arbeta igenom dessa i ordning. De kritiska punkterna (1–6) är minimikraven — resten är viktiga men kan pågå efter 28 juni om du har en dokumenterad åtgärdsplan.

Juridiskt obligatoriska (klart 28 juni):

  1. ☐ Tillgänglighetsutlåtande publicerat — Länkat från footern, med datum, ansvarig kontakt, och förteckning av kända brister. Generera: /verktyg/tillganglighetsutlatande.

  2. ☐ WCAG 2.1 AA-test utfört och dokumenterat — Spara testresultaten. Du behöver kunna visa för PTS att testning genomförts. Snabbtest: /verktyg/wcag-test.

  3. ☐ Återkopplings-mekanism på plats — E-postadress, formulär, eller länk där användare kan rapportera tillgänglighetsproblem. Länk i tillgänglighetsutlåtandet och gärna i footern.

  4. ☐ Alt-text på alla informativa bilder — Dekorativa bilder ska ha tomt alt-attribut (alt=""). Informativa bilder ska ha beskrivande alt-text. Logotyp i header: alt-text = företagsnamnet.

  5. ☐ Formulär har synliga etiketter (labels) — Alla formulärfält (namn, e-post, telefon, sökfält) måste ha ett HTML label-element kopplat via for-attributet eller aria-label. Placeholder-text räknas inte som etikett.

  6. ☐ Tangentbordsnavigering fungerar — Testa: tryck Tab genom webbplatsen. Alla interaktiva element (knappar, formulär, navigering, modaler) ska vara nåbara och användbara med enbart tangentbord. Fokus-indikatorn (blå ring) ska alltid synas.

Viktiga tekniska krav (åtgärda omgående om inte klart):

  1. ☐ Färgkontrast minst 4.5:1 för brödtext — Ljusgrå text på vit bakgrund klarar sällan kravet. Testa med Colour Contrast Analyser eller Northverify WCAG-scan. För stor text (18pt+): minst 3:1.

  2. ☐ Headings i logisk ordning — h1 → h2 → h3 utan hopp. Använd inte headings för styling — CSS tar hand om utseendet.

  3. ☐ ARIA-roller för dynamiskt innehåll — Modaler ska ha role="dialog" och aria-modal="true". Live-regioner för statusmeddelanden ska ha role="status" eller aria-live.

  4. ☐ Captions (textning) på videor — Alla videos med tal eller viktigt ljud behöver undertexter/captions. Auto-captions från YouTube räcker inte — de innehåller för många fel. Kräver manuell kontroll.

  5. ☐ Skip-link till main content — En länk som hoppar förbi navigationen, synlig vid fokus. Placeras som det allra första elementet i body-taggen med länk till webbplatsens huvudinnehåll.

  6. ☐ Kontaktuppgifter tillgängliga för accessibility-issues — Telefon, e-post, eller formulär som användare med tillgänglighetsbehov kan använda. Länk i footern och i tillgänglighetsutlåtandet.


Vad kan vänta?

Det finns WCAG 2.1 AA-krav som är komplexa att implementera och som, om du saknar dem men har en dokumenterad åtgärdsplan, troligen inte leder till omedelbar åtgärd från PTS:

  • Komplex tabell-markup (ARIA-headers i datatabeller)
  • Avancerat skärmläsarstöd för SPA-navigering (single-page applications)
  • Fullt WCAG 2.2-stöd (9 nya kriterier som ännu inte är formellt krav under EAA)
  • Teckentolkningstjänst för realtidskommunikation (sällan aktuellt för statiska webbplatser)

Nyckeln är att dokumentera: vad du vet saknas, när du planerar att åtgärda det, och vilka resurser du avsatt. Ett tillgänglighetsutlåtande med en konkret åtgärdsplan är väsentligt starkare skydd än inget utlåtande alls.


Hur testar du?

Automatiserat (snabbt, tar 5 minuter):

  • Northverify WCAG-test: /verktyg/wcag-test — axe-core API, 60 sekunder
  • Google Lighthouse (inbyggt i Chrome DevTools, fliken Accessibility)
  • WAVE Browser Extension (wave.webaim.org)

Manuellt (kritiskt för fullständig täckning):

  • Tangentbordstest: navigera hela webbplatsen med enbart Tab/Shift+Tab/Enter/Space
  • Skärmläsartest: NVDA + Chrome (gratis, Windows), VoiceOver (inbyggt macOS/iOS)
  • Zoomtest: zooma till 400 % — innehållet ska inte kräva horisontell scrollning

Automatiserade verktyg hittar ca 30–40 % av WCAG-brister. Manuell testning av de kritiska flödena (navigering, formulär, checkout) är nödvändig för att nå juridiskt tillräcklig nivå.


Vad händer om du inte är redo 28 juni?

PTS övertar tillsynsansvaret för EAA den 28 juni 2026. Tillsyn kan utlösas av:

  1. Privatperson anmäler brister till PTS — den vanligaste utlösaren baserat på erfarenheten från DOS-lagens tillämpning i offentlig sektor
  2. PTS:s egna proaktiva granskningar — myndigheten har kommunicerat att branschtillsyn planeras under H2 2026
  3. Klagomål via EU:s centraliserade klagomålssystem

PTS kan utfärda vitesförelägganden: krav på att åtgärda specifika brister vid vite. Vitesbeloppet sätts proportionerligt till bristens allvar och organisationens storlek.

Det primära skyddet är att ha påbörjat arbetet, kunna dokumentera testning, och ha ett tillgänglighetsutlåtande med en realistisk åtgärdsplan publicerat.


Kom igång nu — det tar 30 minuter att bocka av det kritiska

  1. Generera tillgänglighetsutlåtandet: /verktyg/tillganglighetsutlatande — 10 minuter
  2. Kör WCAG-snabbtest: /verktyg/wcag-test — 5 minuter
  3. Publicera utlåtandet och länka från footern — 5 minuter
  4. Skapa återkopplingskanal (en e-postadress räcker) — 5 minuter
  5. Åtgärda de kritiska bristerna från WCAG-testets rapport — börja med alt-text och formuläretiketter

Vår kompletta guide till EAA och WCAG finns på /kunskapsbas/eaa-tillganglighet-guide-sverige.

Skanna din webbplats — gratis

Northverify hittar GDPR-, säkerhets- och tillgänglighetsproblem på 60 sekunder. Inget konto krävs för att köra första skanningen.

Kör en gratis scan

Relaterade artiklar