2026-02-11 · Redaktionen Baduno · 6 blog.readMin · Blog & Kunskap
Tillgänglighetsstärkningslagen: Vad webbplatser nu måste uppfylla
Sedan juni 2025 gäller BFSG – och många företagswebbplatser omfattas. Skyldigheterna, förståeligt sorterade, utan panik.
Vem som omfattas
Lagen omfattar konsumentorienterade elektroniska tjänster – däribland webbutiker och många boknings- och kontaktvägar. Rena B2B-erbjudanden och mikroföretag är delvis undantagna; klassificeringen bör vid tveksamhet granskas juridiskt.
Vad som krävs
Praktiskt sett följer kraven WCAG: uppfattbar (kontraster, alternativtexter), hanterbar (tangentbord, fokus), begriplig (tydligt språk, felmeddelanden) och robust (ren HTML för hjälpmedelsteknologier).
Den goda nyheten
Tillgängliga webbplatser är nästan alltid snabbare, bättre strukturerade och sökmotorvänligare. Skyldigheten bidrar till kvalitet som ändå lönar sig – och når en stor, ofta ignorerad användargrupp.
Börja pragmatiskt
Först testa (automatiserat plus manuellt), sedan prioritera efter effekt: kontraster, alternativtexter, formulär och tangentbordsnavigering åtgärdar de flesta vardagliga hinder. En tillgänglighetsredogörelse dokumenterar läget ärligt.
Hreflang och tillgänglighet: ett ofta förbisett samspel
Flerspråkiga webbplatser står inför en extra utmaning: tillgänglighetskraven gäller för varje språkversion separat. Hreflang-attributet, som signalerar språk- och regiontillhörighet till sökmotorer, måste implementeras så att skärmläsare och andra hjälpmedel korrekt känner igen språkbyten. Om hreflang är felaktigt inställt eller saknas kan det avsevärt försvåra navigeringen för synskadade användare – till exempel om en sida plötsligt laddas på ett annat språk utan att användaren förväntar sig det. Rent praktiskt innebär det att varje språkvariant inte bara måste erbjuda översättningar utan också fullständigt tillgängliga strukturer. Detta inkluderar korrekta språkdeklarationer i HTML (lang-attribut) och konsekventa alternativtexter på alla språk. Hreflang-konfigurationen bör därför inkluderas i tillgänglighetsgranskningen från början.
Automatiserade testverktyg: styrkor och begränsningar
Verktyg som axe, Wave eller Lighthouse kan automatiskt upptäcka många tekniska barriärer, t.ex. saknade alternativtexter, otillräckliga kontraster eller felaktiga ARIA-attribut. De ersätter dock inte manuell granskning, eftersom exempelvis textförståelse, logisk ordning av innehåll eller användbarhet av formulär med hjälpmedel endast kan fångas genom verkliga användartester. Automatiserade kontroller ger en första, snabb feldiagnos och lämpar sig väl för kontinuerliga tester i CI/CD-pipelines. Resultaten måste dock alltid bedömas av en människa, eftersom verktyg producerar både falskt positiva och falskt negativa rapporter. En pragmatisk arbetsflöde: först automatiserade tester, sedan ett manuellt stickprov med skärmläsare och tangentbord, och slutligen ett avslutande användbarhetstest med berörda personer.
Rättsliga konsekvenser och övergångsperioder
BFSG föreskriver böter och anmärkningar om webbplatser inte uppfyller kraven. För produkter som togs i drift före den 28 juni 2025 finns en övergångsperiod fram till den 28 juni 2030 – men endast för de som var tillgängliga före datumet eller som bevisligen arbetar med detta. Den som lanserar en ny webbplats eller en omstart efter den 28 juni 2025 måste omedelbart uppfylla samtliga krav. Observera: Lagen gäller allt nytt innehåll; äldre innehåll (t.ex. arkivsidor) kan i vissa fall behöva anpassas mer omfattande. I praktiken rekommenderas en skriftlig dokumentation av framsteget för att vid anmärkningar kunna visa att tillgängligheten genomförs stegvis. En tillgänglighetsförklaring på webbplatsen är ändå obligatorisk.
Sedan juni 2025 gäller BFSG – och många företagswebbplatser omfattas. Skyldigheterna, förståeligt sorterade, utan panik.
Tillgänglighet som en del av den internationella SEO-strategin
Tillgängliga webbplatser uppfyller inte bara lagkrav utan även många kriterier som sökmotorer värderar positivt: semantisk HTML-struktur, tydliga rubrikhierarkier, informativa alt-texter och snabba laddningstider. Dessa faktorer är relevanta för SEO på alla språk. Dessutom kan sökmotorer uttryckligen straffa barriärer som omärkta knappar eller saknade rubriker, eftersom de försvårar indexering. Den som gör sin webbplats tillgänglig för alla användare förbättrar automatiskt användarupplevelsen och därmed indirekt rankningssignalerna. Särskilt för flerspråkiga webbplatser lönar det sig att integrera tillgänglighet från början i lokaliseringsarbetsflöden – till exempel genom checklistor för översättare för att skapa tillgängliga alternativtexter.
Testning med verkliga användare: Varför det är oumbärligt
Automatiserade verktyg upptäcker endast en del av hindren. Först testning med människor som faktiskt är beroende av hjälpmedel visar om din webbplats fungerar i vardagen. Blinda användare använder skärmläsare annorlunda än automatiserade tester simulerar; döva användare har andra krav på teckenspråksvideor; personer med motoriska funktionsnedsättningar navigerar utan mus. Ett strukturerat test med tre till fem deltagare från olika funktionsnedsättningsgrupper avslöjar problem som inget verktyg hittar – till exempel ologiska fokusordningar, saknad kontextinformation i ARIA-etiketter eller obegripliga felmeddelanden. Planera sådana tester helst under utvecklingsfasen, inte strax före lansering. Dokumentera resultaten i tillgänglighetsredogörelsen som en del av din kvalitetssäkring. Kom ihåg: Testerna måste genomföras separat för varje språkversion, eftersom översättningar kan skapa nya hinder – till exempel om alternativtexter inte passar målspråket eller formulärmeddelanden är grammatiskt felaktiga.
Content Management System och tillgänglighet: Fallgropar med plugins
Många webbplatser bygger på CMS som WordPress, TYPO3 eller Drupal. Dessa system erbjuder plugins eller tillägg som lovar tillgänglighet – till exempel overlay-verktyg som i efterhand justerar kontraster eller lägger till ARIA-attribut. Sådana lösningar är oftast otillräckliga och kan till och med skapa nya barriärer genom att skriva över befintliga semantiska strukturer. Istället bör du implementera tillgängligheten direkt i temat eller mallen: ren HTML-struktur, korrekta rubrikhierarkier, inbyggda formulärelement. När du väljer plugins, se till att de är WCAG-kompatibla och uppdateras regelbundet. Ett annat problem: Många redaktörer lägger in innehåll via den visuella redigeraren och ignorerar alt-texter eller rubrikformat. Utbilda dina redaktörer eller använd arbetsflöden som tvingar fram tillgänglig inmatning – till exempel obligatoriska fält för alternativtext vid bilder. Även valet av CMS-mall påverkar tillgängligheten: Testa varje mall före användning med ett automatiserat verktyg och ett manuellt urval.
Testning med personer med funktionsnedsättning: Det oumbärliga steget
Automatiserade verktyg och manuella checklistor avslöjar många tekniska barriärer, men de ersätter inte testning med verkliga användare. Personer med funktionsnedsättning använder olika hjälpmedelstekniker – skärmläsare som JAWS, NVDA eller VoiceOver, förstoringsprogram, röststyrning eller specialtangentbord. Varje kombination beter sig olika, så även en formellt överensstämmande sida kan vara oanvändbar för en blind användare. Planera därför regelbundna användartester med en heterogen grupp: synskadade, personer med motoriska begränsningar och kognitivt nedsatta. Låt dem utföra definierade uppgifter på din webbplats, till exempel ett produktköp eller ifyllande av ett kontaktformulär. Dokumentera problemen noggrant: Var stannar navigationen, vilka meddelanden är obegripliga, vilka element nås inte? Insikterna från dessa tester är guld värda, eftersom de inte bara visar barriärer utan även optimeringspotential för alla användare. Se till att genomföra testerna separat för varje språkversion, eftersom översättningar och komplexa meningar påverkar förståelsen olika. Integrera resultaten i din kontinuerliga förbättringsprocess – tillgänglighet är inget engångsprojekt utan en bestående uppgift.
Förankra tillgänglighet i innehållshanteringssystemet
Många tillgänglighetsbrister uppstår redan vid innehållsskapandet: Redaktörer glömmer alternativtexter, använder inte rubrikhierarki eller länkar till meningslösa ord som ”klicka här”. För att undvika detta bör du förankra tillgänglighet direkt i ditt innehållshanteringssystem (CMS). Utbilda dina redaktionsteam i grunderna i WCAG – och det för varje språkteam separat, så att kraven inte undermineras av kulturella skillnader i textutformning. Använd CMS-plugins eller tillägg som tvingar fram obligatoriska alt-textfält vid bildinfogning eller visar rubrikhierarki visuellt. Integrera automatiska kontroller i publiceringsarbetsflödet som före publicering varnar för vanliga fel som saknade etiketter eller för låga kontraster. Se också till att de CMS-mallar och teman du använder redan är tillgänglighetsanpassade – till exempel med korrekta ARIA-landmärken, tangentbordsfokus och semantisk HTML. För flerspråkiga webbplatser är det väsentligt att CMS:et stödjer lokalisering av tillgängliga strukturer, till exempel genom att hreflang-attribut och språkdeklarationer sätts korrekt automatiskt. En välintegrerad tillgänglighetsprocess i CMS:et minskar efterarbete och säkerställer konsekvent kvalitet över alla språkversioner.
blog.faqT
Vad händer om min webbplats bryter mot BFSG?
Vid överträdelser av BFSG kan böter utdömas. Dessutom kan konkurrenter eller konsumentorganisationer utfärda varningar. Bötesbeloppet bestäms utifrån överträdelsens allvarlighetsgrad och kan uppgå till 100 000 euro. En tillgänglighetsredogörelse med omfattning och status för åtgärderna är obligatorisk och fungerar som bevis.
Måste översättningar av min webbplats också vara tillgängliga?
Ja, varje språkversion måste uppfylla tillgänglighetskraven individuellt. Detta inkluderar korrekta språkattribut (lang), översatta alternativtexter samt tillgänglig navigation. Hreflang-attributet måste ställas in så att sökmotorer och hjälpmedel korrekt kan identifiera språkbyten. Även översättningsbyråer bör därför vara uppmärksamma på tillgängligheten i sina leveranser.
