Tillgänglighet och lagkraven: vad din webbplats måste klara

Sedan 28 juni 2025 är webbtillgänglighet ett lagkrav för stora delar av den privata sektorn i Sverige. Det är inte längre en branschrekommendation eller ett frivilligt kvalitetsmärke. Den här guiden ger en klar bild av vad lagen faktiskt kräver, vad tillgänglighet innebär i praktiken och hur valet av teknisk plattform påverkar hur svårt det är att uppfylla kraven.

Vad lagen kräver

EU:s tillgänglighetsdirektiv, European Accessibility Act, trädde i kraft i Sverige den 28 juni 2025 och gäller nu privata företag som erbjuder konsumentinriktade digitala tjänster. Bland de verksamheter som omfattas finns e-handel, banktjänster, e-böcker, transporttjänster och ett antal andra kategorier. Mikroföretag kan i vissa fall vara undantagna för specifika tjänster, men gränsdragningen är inte självklar och bör inte gissas till utan juridisk rådgivning.

Den standard som i praktiken ska uppfyllas är WCAG 2.1 nivå AA. WCAG, som står för Web Content Accessibility Guidelines, är det internationella regelverket för webbtillgänglighet och anger konkreta krav på kontrast, navigering, struktur och innehåll. Nivå AA är den mellersta av tre nivåer och den som lagstiftningen pekar på.

Tillsynsmyndighet är DIGG, Myndigheten för digital förvaltning. Tillsynen är fortfarande under uppbyggnad, men lagen gäller redan och förelägganden kan utfärdas. Att avvakta och se hur noggrant tillsynen bedrivs är en riskbedömning, inte ett undantag.

Vad tillgänglighet faktiskt innebär

Tillgänglighet handlar om att fler människor ska kunna använda din webbplats, oavsett hur de interagerar med den. Det rör sig om en betydande andel av befolkningen: personer med nedsatt syn, kognitiva funktionsnedsättningar, motoriska svårigheter eller hörselnedsättning.

Skärmläsare är program som läser upp innehållet på skärmen högt för den som inte kan se det. För att en skärmläsare ska fungera måste sidans innehåll finnas som riktig text i koden, i rätt ordning. En knapp som ser ut som en knapp men saknar en textbeteckning i koden är osynlig för skärmläsaren.

Tangentbordsnavigering innebär att hela sajten ska gå att använda utan mus. Alla menyer, formulär och interaktiva element behöver kunna nås och aktiveras med tangentbordet. Det är viktigt för personer med motoriska svårigheter och också för de som av andra skäl undviker musen.

Färgkontrast är ett mätbart krav. WCAG AA kräver ett kontrastförhållande på minst 4,5:1 mellan text och bakgrund. Ljusgrå text på vit bakgrund, ett vanligt designval, klarar ofta inte detta krav.

Semantisk struktur handlar om att koden berättar vad innehållet är: att rubriker är märkta som rubriker, att formulärfält har synliga och kopplade etiketter, att bilder har alternativtexter som beskriver vad de visar. Utan den strukturen tappar skärmläsare och andra hjälpmedel orienteringen.

Hur Next.js hjälper

Next.js renderar HTML på servern, det vill säga att sidans innehåll byggs färdigt och skickas till besökaren som riktig text redan vid första laddningen. Det är en viktig fördel för tillgänglighet. Skärmläsare kan läsa innehållet direkt och tillförlitligt, till skillnad från applikationer som enbart renderar i webbläsaren och där innehållet dyker upp först efter att webbläsaren kört igenom en stor mängd kod.

Välbyggda Next.js-komponenter ger semantisk HTML-struktur som standard. Rubriker är rubriker, listor är listor och knappar är knappar i den faktiska koden, inte bara i utseendet.

Next.js hanterar också fokus vid sidbyten automatiskt. När en besökare navigerar till en ny sida inom sajten placeras fokus korrekt, vilket är avgörande för den som rör sig med tangentbordet och förlitar sig på tydliga fokusmarkeringar för att förstå var på sidan de befinner sig.

Jämfört med en WordPress-sajt med många tillägg, där tillgängligheten beror på kvaliteten i varje enskilt tillägg och hur de samspelar, byggs en Next.js-sajt som en sammanhållen kodbas. Det gör det möjligt att bygga in tillgänglighet från grunden och upprätthålla konsistens genom hela sajten.

Vad ramverket inte löser åt er

Next.js ger en bra teknisk grund, men inget ramverk garanterar tillgänglighet. En dåligt byggd Next.js-sajt kan vara lika otillgänglig som vilken annan plattform som helst.

Design är utvecklarens och designerns ansvar: färgkontraster behöver kontrolleras mot WCAG-kraven, fokusmarkeringar (den ram som visar vilket element som är aktivt) får inte tas bort för estetikens skull, och layouten behöver vara begriplig också utan att man ser den i sin helhet.

Innehåll är redaktionens ansvar: bilder behöver alternativtexter, filmer behöver textning, och texter bör vara skrivna på ett sätt som är begripligt också för den med kognitiva svårigheter.

Interaktiva element behöver märkas korrekt av den som skriver koden. En anpassad meny eller ett formulär som ser bra ut visuellt kan vara helt oanvändbart för en skärmläsare om den semantiska märkningen saknas.

Tillgänglighet är ett arbetssätt, inte en kryssruta vid lansering. Det behöver integreras i design, utveckling och redaktionellt arbete löpande.

Så testar ni

Ingen enskild testmetod fångar allt. Kombinera tre nivåer.

Automatiska verktyg som Lighthouse, inbyggt i Chrome, och axe, ett webbläsartillägg, kan snabbt identifiera en del vanliga problem: saknade alternativtexter, otillräcklig kontrast, felaktig rubrikstruktur. De är ett bra första steg men fångar uppskattningsvis ungefär 30 till 40 procent av faktiska tillgänglighetsproblem.

Manuell test kompletterar verktygen. Använd hela sajten med enbart tangentbordet: kan du nå varje meny, fylla i varje formulär och aktivera varje länk utan mus? Ladda sedan ned en skärmläsare, NVDA för Windows och VoiceOver för Mac finns inbyggt eller gratis, och lyssna dig igenom de viktigaste sidorna.

Riktiga användare med funktionsnedsättning fångar det som verktyg och välmenande utvecklare missar. Att inkludera faktiska användare i testfasen ger insikter som ingen teknisk kontroll kan ersätta.

Är ni redo?

Om er verksamhet driver en konsumentinriktad digital tjänst som omfattas av direktivet är tillgänglighet inte ett alternativ. Risken är dubbel: dels möjliga förelägganden från DIGG, dels förlorade kunder. En otillgänglig sajt stänger ute en betydande andel besökare, varav många har köpkraft och lojalitet om de väl kan använda tjänsten.

När Next.js är rätt val: om ni ska bygga nytt eller genomföra en större ombyggnad är Next.js ett tekniskt fundament som förenklar tillgänglighetsarbetet. Serverrenderad HTML, semantisk struktur och korrekt fokushantering ger ett bättre utgångsläge än många alternativa plattformar.

När det inte räcker: ett ramverk löser inte ett bristande medvetande om tillgänglighet i teamet. Oavsett plattform behöver design, utveckling och redaktion arbeta med tillgänglighet som ett genomgående krav, inte som en eftertanke.

Konkret nästa steg är att granska nuläget innan ni planerar nytt. Kör Lighthouse, testa med tangentbord och notera vad som brister. Det faktaunderlaget avgör om er befintliga plattform kan bringas i ordning eller om ett teknikbyte är det rimliga valet.