Guider

Uppföljning av tillgänglighetslagen: Tips för långsiktig framgång

Lästid

5 min

Publicerad

14 sep. 2025

Tillgänglighet är inget engångsprojekt. Du kan inte scanna sajten en gång, fixa alla fel, och sedan glömma det. Varje ny funktion, varje designuppdatering, varje innehållsändring kan introducera nya tillgänglighetsproblem.

Den svenska tillgänglighetslagen (som implementerar EU:s tillgänglighetsdirektiv) kräver inte bara att produkter är tillgängliga vid lansering – de måste förbli tillgängliga under hela sin livstid.

I denna guide går vi igenom hur du sätter upp processer och rutiner som säkerställer att tillgänglighetsarbetet fortsätter långt efter den första granskningen.

Varför tillgänglighet kräver kontinuerligt arbete

Tänk på alla sätt en webbplats förändras över tid:

•Nya funktioner – Varje sprint lägger till nya komponenter, formulär, flöden

•Innehållsuppdateringar – Redaktörer publicerar bilder utan alt-texter, lägger till PDFer som inte är tillgängliga

•Tredjepartsintegrationer – Chatbotar, analyser, cookie-banners – ofta otillgängliga

•Ramverksuppdateringar – En React- eller Angular-uppgradering kan bryta tillgänglighetsfunktioner

•Designändringar – En ny färgpalett som inte testats för kontrast

Utan systematisk uppföljning växer teknisk skuld. Det som tog en vecka att fixa vid lansering tar tre månader ett år senare.

En studie visade att webbplatser tappar i genomsnitt 3% av sin tillgänglighetsscore per månad utan aktiv uppföljning.

Bygg in tillgänglighet i sprintcykeln

Den mest effektiva strategin är att göra tillgänglighetskontroller till en naturlig del av utvecklingsprocessen:

Definition of Done:

Lägg till tillgänglighetskriterier i er Definition of Done. En feature är inte klar förrän:

•Automatiska tillgänglighetstester passerar

•Komponenten är tangentbordsnavigerbar

•Skärmläsartest genomfört på nya interaktioner

Code review checklist:

•Har bilder alt-texter?

•Har formulärfält etiketter?

•Används semantisk HTML?

•Fungerar fokusordningen logiskt?

Sprint retrospektiv:

Granska tillgänglighetsincidenter. Varför missades problemet? Hur förhindrar vi det nästa gång?

Automatisera vad som går att automatisera

Automatiska verktyg hittar cirka 30-40% av tillgänglighetsproblem. Det låter kanske lite, men det täcker de mest frekventa felen.

CI/CD-integration:

Kör automatiska tillgänglighetstester i er build-pipeline. Om testerna misslyckas, blockera deploy. Verktyg som fungerar:

•axe-core – Kan integreras i Jest, Cypress, Playwright

•Pa11y – CLI-verktyg för CI/CD

•Lighthouse CI – Inkluderar tillgänglighetskontroller

Kontinuerlig övervakning:

Schemalägg regelbundna skanningar med Xrayd. Få larm när nya fel dyker upp, inte bara vid release.

Linting:

Lägg till eslint-plugin-jsx-a11y (React) eller liknande för ditt ramverk. Fånga problem redan i editorn.

Det manuella arbetet försvinner aldrig

Automatiska verktyg räcker inte. Vissa saker kräver mänsklig bedömning:

•Alt-texter – Verktyg kan se att alt saknas, men inte om texten är meningsfull

•Fokusordning – Går fokus i logisk ordning genom sidan?

•Skärmläsarupplevelse – Fungerar interaktioner som förväntat?

•Kognitiv belastning – Är instruktioner tydliga? Är felmeddelandena hjälpsamma?

Planera för regelbundna manuella granskningar – kvartalsvisa djupdykningar av experter, månatliga stickprov av teamet.

Vem äger tillgänglighetsarbetet?

Det farligaste är när 'alla' är ansvariga – då är ingen det. Definiera tydliga roller:

Tillgänglighetsansvarig (Accessibility Lead):

En person med dedikerat ansvar för att driva arbetet, utbilda teamet, och rapportera status till ledningen.

Utvecklare:

Ansvariga för att skriva tillgänglig kod, följa checklistor, och fixa buggar i sitt område.

Designers:

Ansvariga för att leverera designs som är möjliga att implementera tillgängligt. Kontrast, fokusmarkeringar, interaktionsmönster.

Innehållsskapare:

Ansvariga för alt-texter, rubriker, länktexter, och dokument (PDF, Word).

QA:

Inkludera tillgänglighet i testplaner. Testa med tangentbord och skärmläsare.

Dokumentera och spåra

Utan dokumentation börjar ni om från noll varje gång. Skapa:

Tillgänglighetspolicy:

Ett dokument som beskriver er målnivå (WCAG 2.1 AA), vem som ansvarar, och processer för rapportering.

Tillgänglighetsutlåtande:

Offentlig deklaration (krävs för offentlig sektor) som beskriver status, kända problem, och kontaktväg för feedback.

Buggspårning:

Tagga tillgänglighetsbuggar i Jira/GitHub. Möjliggör rapportering: hur många öppna A11y-buggar har vi? Vilka är kritiska?

Historik:

Spara rapporter från tidigare granskningar. Visa att ni arbetar aktivt med förbättringar.

Utbilda teamet kontinuerligt

Kunskap är färskvara. Nya teammedlemmar behöver onboarding, och befintliga behöver uppdateringar:

•Onboarding: Alla nya utvecklare och designers går igenom grundläggande tillgänglighetsutbildning

•Lunch & Learn: Månatliga sessioner om specifika ämnen (ARIA, tangentbord, etc.)

•Verktygsträning: Se till att alla vet hur man använder skärmläsare, kontrastverktyg, och Xrayd

•Externa kurser: Certifieringar som IAAP CPACC eller WAS för nyckelpersoner

Gör tillgänglighet till något teamet är stolta över, inte en börda.

Testa din webbplats tillgänglighet

Gratis skanning, ingen registrering

Vanliga frågor

Hur ofta bör vi göra en fullständig tillgänglighetsgranskning?+

Rekommendationen är minst en gång per år, samt efter större omdesigner eller funktionslanseringar. Automatisk övervakning bör ske löpande (dagligen eller veckovis).

Vad händer om vi inte följer tillgänglighetslagen?+

Tillsynsmyndigheten kan utdöma sanktionsavgifter och i allvarliga fall kräva att produkten tas bort från marknaden tills bristerna åtgärdats. För offentlig sektor kan det också påverka upphandlingar.

Kan vi outsourca tillgänglighetsarbetet helt?+

Granskningar och audits kan outsourcas, men det dagliga arbetet måste göras av teamet som bygger produkten. Extern expertise är bra för djupdykningar och utbildning, men intern kompetens är nödvändigt för hållbart arbete.