2026-02-11 · Redaktion Baduno · 6 blog.readMin · Blog & Viden
BFSG-loven: Hvad hjemmesider nu skal opfylde
Siden juni 2025 gælder BFSG – og mange virksomhedshjemmesider er omfattet. Pligterne, forståeligt sorteret, uden panik.
Hvem der er omfattet
Loven omfatter forbrugerrettede elektroniske tjenester – herunder online shops og mange bookings- og kontaktforløb. Rene B2B-tilbud og mikrovirksomheder er delvist undtaget; klassificeringen bør i tvivlstilfælde vurderes juridisk.
Hvad der kræves
Praktisk set følger kravene WCAG: opfattelig (kontraster, alternativtekster), betjenbar (tastatur, fokus), forståelig (tydeligt sprog, fejlmeddelelser) og robust (rent HTML til hjælpeteknologier).
Den gode nyhed
Tilgængelige hjemmesider er næsten altid også hurtigere, bedre strukturerede og mere søgemaskinevenlige. Pligten investerer i kvalitet, der alligevel betaler sig – og åbner op for en stor, ofte overset brugergruppe.
Start pragmatisk
Først test (automatiseret plus manuelt), derefter prioriter efter effekt: Kontraster, alternativtekster, formularer og tastaturbetjening løser de fleste daglige barrierer. En tilgængelighedserklæring dokumenterer status ærligt.
Hreflang og tilgængelighed: Et ofte overset samspil
Flersprogede hjemmesider står over for en ekstra udfordring: Tilgængelighedskravene gælder for hver sprogversion separat. Hreflang-attributten, som signalerer sprog- og regionssammenhængen for søgemaskiner, skal implementeres sådan, at skærmlæsere og andre hjælpeteknologier korrekt registrerer sprogskifterne. Hvis hreflang er forkert indstillet eller mangler, kan det i høj grad vanskeliggøre navigationen for synshæmmede brugere – for eksempel hvis en side pludselig indlæses på et andet sprog uden at brugeren forventer det. Praktisk betyder det: Hver sprogvariant skal ikke kun tilbyde oversættelser, men også fuldt tilgængelige strukturer. Dette inkluderer korrekte sprogdeklarationer i HTML (lang-attribut) og konsistente alternativtekster på alle sprog. Hreflang-konfigurationen bør derfor inddrages i tilgængelighedstestningen fra starten.
Automatiserede testværktøjer: Styrker og begrænsninger
Værktøjer som axe, Wave eller Lighthouse kan automatisk opdage mange tekniske barrierer, f.eks. manglende alternativtekster, utilstrækkelige kontraster eller fejlagtige ARIA-attributter. De erstatter dog ikke manuel testning, da forståeligheden af tekster, den logiske rækkefølge af indhold eller anvendeligheden af formularer med hjælpeteknologier kun kan fanges gennem rigtige brugertests. Automatiserede checks leverer en første, hurtig fejlanalyse og egner sig godt til kontinuerlig testning i CI/CD-pipelines. Resultaterne skal dog altid vurderes af et menneske, da værktøjerne både producerer falsk positive og falsk negative meldinger. En pragmatisk arbejdsgang: Først automatiserede tests, derefter en manuel stikprøve med skærmlæser og tastatur, og til sidst en afsluttende brugbarhedstest med berørte.
Juridiske konsekvenser og overgangsperioder
BFSG fastsætter bøder og advarsler, hvis hjemmesider ikke opfylder kravene. For produkter, der blev taget i brug før 28. juni 2025, er der en overgangsperiode indtil 28. juni 2030 – men kun for dem, der allerede var tilgængelige før deadline eller dokumenterbart arbejder på det. Hvis man lancerer en ny hjemmeside eller en relancering efter 28. juni 2025, skal man straks opfylde alle krav. Bemærk: Loven gælder for alt nyt indhold; ældre indhold (f.eks. arkivsider) kan i nogle tilfælde kræve mere omfattende tilpasninger. I praksis anbefales en skriftlig dokumentation af fremskridtene, så man ved eventuelle indsigelser kan dokumentere, at man gradvist implementerer tilgængelighed. En tilgængelighedserklæring på hjemmesiden er under alle omstændigheder obligatorisk.
Siden juni 2025 gælder BFSG – og mange virksomhedshjemmesider er omfattet. Pligterne, forståeligt sorteret, uden panik.
Tilgængelighed som en del af den internationale SEO-strategi
Tilgængelige hjemmesider opfylder ikke kun lovkrav, men også mange kriterier, som søgemaskiner vurderer positivt: semantisk HTML-struktur, tydelige overskriftshierarkier, beskrivende alt-tekster og hurtige indlæsningstider. Disse faktorer er relevante for SEO på alle sprog. Derudover kan søgemaskiner direkte straffe barrierer som ikke-annoterede knapper eller manglende overskrifter, da de vanskeliggør indeksering. Ved at gøre sin hjemmeside tilgængelig for alle brugere forbedrer man automatisk brugeroplevelsen og dermed indirekte også ranking-signalerne. Især ved flersprogede hjemmesider er det værd at integrere tilgængelighed fra starten i lokaliseringsworkflows – f.eks. gennem tjeklister til oversættere om udarbejdelse af tilgængelige alternativtekster.
Test med rigtige brugere: Hvorfor det er uundværligt
Automatiserede værktøjer opdager kun en del af barriererne. Først når testen udføres med mennesker, der rent faktisk er afhængige af hjælpeteknologier, viser det, om din hjemmeside fungerer i hverdagen. Blinde brugere bruger skærmlæsere anderledes end automatiserede tests simulerer; døve brugere har andre krav til tegnsprogsvideoer; motorisk handicappede navigerer uden mus. En struktureret test med tre til fem deltagere fra forskellige handicapgrupper afslører problemer, som intet værktøj finder – f.eks. ulogiske fokusrækkefølger, manglende kontekstinformation i ARIA-etiketter eller uforståelige fejlmeddelelser. Planlæg sådanne tests ideelt set i udviklingsfasen, ikke lige før lanceringen. Dokumenter resultaterne i tilgængelighedserklæringen som en del af din kvalitetssikring. Husk: Testene skal udføres separat for hver sprogversion, da oversættelser kan skabe nye barrierer – f.eks. hvis alternativtekster ikke passer til målsproget, eller formularhenvisninger er grammatisk forkerte.
Content Management Systemer og tilgængelighed: Faldgruber ved plugins
Mange websites er baseret på CMS som WordPress, TYPO3 eller Drupal. Disse systemer tilbyder plugins eller udvidelser, der lover tilgængelighed – fx overlay-værktøjer, der efterfølgende justerer kontraster eller indsætter ARIA-attributter. Sådanne løsninger er ofte utilstrækkelige og kan endda skabe nye barrierer ved at overskrive eksisterende semantiske strukturer. I stedet bør du implementere tilgængeligheden direkte i temaet eller skabelonen: ren HTML-struktur, korrekte overskriftshierarkier, native formular-elementer. Vær opmærksom på, at de plugins du vælger er WCAG-konforme og regelmæssigt opdateres. Et andet problem: Mange redaktører tilføjer indhold via den visuelle editor og ignorerer alt-tekster eller overskriftsformater. Uddan dine redaktører eller brug workflows, der tvinger tilgængelige input – fx obligatoriske felter til alternativtekster ved billeder. Også valget af CMS-skabelonen påvirker tilgængeligheden: Test hver skabelon før brug med et automatiseret værktøj og en manuel stikprøve.
Test med mennesker med handicap: Det uundværlige skridt
Automatiserede værktøjer og manuelle tjeklister afdækker mange tekniske barrierer, men de erstatter ikke test med rigtige brugere. Mennesker med handicap bruger forskellige hjælpeteknologier – skærmlæsere som JAWS, NVDA eller VoiceOver, forstørrelsessoftware, stemmestyring eller specielle tastaturer. Hver af disse kombinationer opfører sig forskelligt, så selv en formelt konform side kan være ubrugelig for en blind bruger. Planlæg derfor regelmæssige brugertests med en heterogen gruppe: synshandicappede, motorisk handicappede og kognitivt svækkede personer. Lad dem udføre definerede opgaver på din hjemmeside, fx et produktkøb eller udfyldelse af et kontaktformular. Dokumenter præcist de problemer, der opstår: Hvor stopper navigeringen, hvilke meddelelser er uforståelige, hvilke elementer nås ikke? Indsigterne fra disse tests er guld værd, for de viser ikke kun barrierer, men også optimeringspotentiale for alle brugere. Sørg for at udføre testene separat for hver sprogversion, da oversættelser og indlejrede sætninger påvirker forståeligheden forskelligt. Integrer resultaterne i din løbende forbedringsproces – tilgængelighed er ikke et engangsprojekt, men en varig opgave.
Forankring af tilgængelighed i content management-systemet
Mange tilgængelighedsfejl opstår allerede ved indholdsoprettelse: Redaktører glemmer alternativtekster, bruger ikke overskrifter hierarkisk eller linker til intetsigende ord som 'klik her'. For at undgå dette bør du forankre tilgængelighed direkte i dit content management-system (CMS). Uddan dine redaktionsteams i grundlaget for WCAG – og det for hvert sprogteam separat, så kravene ikke undermineres af kulturelle forskelle i tekstudformning. Brug CMS-plugins eller udvidelser, der tvinger obligatoriske alt-tekst-felter ved indsættelse af billeder eller visuelt viser en overskriftshierarki. Integrer automatiserede kontroller i godkendelsesworkflowet, der før offentliggørelse påpeger hyppige fejl som manglende etiketter eller for lav kontrast. Sørg også for, at de CMS-skabeloner og temaer, du bruger, allerede er tilgængelige – fx med korrekte ARIA-landmarks, tastaturfokusstyring og semantisk HTML. For flersprogede websites er det afgørende, at CMS understøtter lokalisering af tilgængelige strukturer, fx ved at hreflang-attributter og sprogdeklarationer sættes korrekt automatisk. En godt integreret tilgængelighedsproces i CMS reducerer efterbearbejdningsarbejde og sikrer ensartet kvalitet på tværs af alle sprogversioner.
blog.faqT
Hvad sker der, hvis mit websted overtræder BFSG?
Ved overtrædelser af BFSG kan der pålægges bøder. Derudover må man forvente advarsler fra konkurrenter eller forbrugerorganisationer. Bødens størrelse afhænger af overtrædelsens alvor og kan være op til 100.000 euro. En tilgængelighedserklæring med omfang og status for foranstaltningerne er obligatorisk og tjener som dokumentation.
Skal oversættelser af min hjemmeside også være tilgængelige?
Ja, hver sprogversion skal individuelt opfylde tilgængelighedskravene. Dette omfatter korrekte sprogattributter (lang), oversatte alternativtekster samt tilgængelig navigation. hreflang-attributten skal indstilles, så søgemaskiner og hjælpeteknologier korrekt genkender sprogskiftene. Også oversættelsesbureauer bør derfor være opmærksomme på tilgængeligheden af deres leverancer.
