European Accessibility Act (EAA) er en fælleseuropæisk lovgivning (direktiv 2019/882), der skal sikre, at digitale produkter og tjenester er tilgængelige for alle.
Loven er implementeret i den danske Tilgængelighedslov og er fra 28. juni 2025 gældende i alle EU-medlemslande.
Direktivet kræver tilgængelighed for de fleste "essentielle" produkter omfattende digitale produkter inden for bank, forsikringsselskaber, transport og e-handel. Det gælder både offentlige organisationer og alle private virksomheder, der sælger til EU-kunder.
Hvis du opererer i EU, skal dine produkter således opfylde EAA’s krav. Dog er mikrovirksomheder (defineret som “en virksomhed, der beskæftiger færre end ti personer, og som har en årlig omsætning eller en årlig balance, der ikke overstiger to millioner euro.”) undtaget - endnu.
Loven er for så vidt allerede tråd i kraft. Fristen for at overholde EAA/den danske Tilgængelighedslov er dog først den 28. juni 2025. Sanktioner inkluderer både bødestraf og forbud mod at markedsføre og sælge produkter eller løsninger, der ikke overholder .
I denne artikel gennemgår vi først lovgivningens sigte og krav – og kommer til sidst med 5 konkrete anbefalinger til, hvordan I bliver klar til at overholde den gældende lovgivning.
En gennemgang af lovgivningens krav
I Danmark er EAA implementeret i den danske Tilgængelighedslov, der trådte i kraft i 2022. Tilgængelighedsloven har til formål at sikre, at både offentlige og nu også private virksomheder og organisationer gør deres digitale produkter og tjenester tilgængelige for alle brugere – også dem med funktionsnedsættelser.
Det er krav, der er fastsat for at sikre, at websider, mobiltelefoner, smart-tv, e-bøger, parkeringsautomater, billetautomater, operativsystemer og mange andre produkter og tjenester, man køber i EU, kan bruges – uanset om man lever med en midlertidig eller permanent funktionsnedsættelse. Der er ikke kun tale om rent digitale produkter, men også fysiske enheder inden for de nævnte kategorier.
Alle brugere kan potentielt blive til betalende kunder, hvis de kan bruge din løsning. Med tilgængelige løsninger inkluderes alle.
Det anslås, at 20 procent af alle mennesker har gavn af tilgængelige løsninger. Det er ikke kun blinde, svagtseende eller døve brugere, men også folk med motoriske handicap, angst eller ADHD eller endda brugere, der er trætte eller distraherede i situationsbestemte øjeblikke. Ingen er ”den perfekte bruger” hele tiden.
For brugere med funktionsnedsættelser vil opfyldelse af lovkravene føre til:
- Øget mulighed for at deltage i det digitale samfund
- Øget selvstændighed
- Øget livskvalitet
For virksomheder vil de lovpligtige tiltag ikke blot medføre udgifter, men faktisk kunne føre til:
- Øget tilgængelighed af produkter og tjenester (større kundegrundlag)
- Øget positiv brandomtale (CSR)
- Øget kundetilfredshed
- Bedre muligheder for risikomitigering i udviklingsprojekter
- Reduktion af omkostninger
Private bliver omfattet af tilgængelighedskrav
Der har siden 2018 været krav til det offentlige om at borgerrettede selvbetjeningsløsninger på internettet skal være tilgængelige. På nuværende tidspunkt skal disse løsninger leve op til Web Consortium Assessibility Guidlines (WCAG) på et givet niveau (se næste afsnit).
EAA er en mere omfattende lovgivning, der dækker et bredere udvalg af digitale produkter og tjenester (ikke kun webbaserede løsninger), og det er ikke længere kun det offentlige, der skal leve op til anbefalingerne. Loven inkluderer nu også private udbydere, der har kunder i EU. Fokus er således ikke på organisationens hjemland, men på kundernes.
EAA og dermed den nye danske lov har desuden strengere krav til tilgængelighed. Ingen af de to henviser direkte til den hidtil gældende version af WCAG (2.1), men til ETSI-standarden EN 301 549, da EAA jo ikke kun fokuserer på webløsninger. ETSI-standarden, der lægger sig tæt op ad ver. 2.1 af WCAG, er endnu ikke opdateret til at inkludere de nye anbefalinger i den netop lancerede WCAG 2.2, men en opdatering forventes frem mod 2025. Så det sikre bud er at sigte mod at leve op til WCAG 2.2 på niveau AA eller tilsvarende.
Hvad betyder det så i praksis?
Det betyder, at det ikke længere er nok at sørge for at ens løsninger kan betjenes uden mus eller touch, understøtte anvendelsen af skærmlæsere og have nok kontrast mellem baggrund og tekst. Udviklingen af digitale løsninger inklusiv hardware skal i endnu højere grad foregå i et tværfagligt samarbejde.
De komponenter, der indgår i udvikling og interaktion, skal i højere grad arbejde sammen, for at løsningerne også bliver tilgængelige for brugere med funktionsnedsættelser. Disse komponenter omfatter:
Indhold - Oplysningerne på en webside eller i en digital løsning (tekst, billeder, lyde, kode eller opmærkning, der definerer struktur, præsentation osv.)
”Brugeragenter” - Webbrowsere, medieafspillere og andre ”brugeragenter”
Assisterende teknologi - Skærmlæsere, alternative tastaturer, kontakter, scanningssoftware mv.
Brugerne - Deres viden, erfaringer og i nogle tilfælde tilpasningsstrategier, når de anvender digitale løsninger
Udviklingsteams - Front- og backend udviklere, designere, forfattere samt software, der skaber kode
Evalueringsværktøjer - Evalueringsværktøjer til webtilgængelighed, HTML-validatorer, CSS-validatorer osv.
For, at alle disse komponenter kan gå op i en højere enhed, har Web Accessibility Initiative (WAI) under World Wide Web Consortium (W3C) udarbejdet en række anbefalinger for at sikre tilgængelige løsninger. Den hidtil gældende WCAG 2.1 har opridset en række succeskriterier, der kan opfyldes på flere niveauer afhængigt af brugerprofiler og ambitionsniveau. Succeskriterierne belyser i brede træk, hvordan man kan gøre sin løsning
- Synlig (perceivable),
- Funktionsdygtig (operable),
- Forståelig (understandable) og
- Stabil (robust)-
Som nævnt dækker WCAG kun webbaserede løsninger, men de 50 succeskriterier som ver. 2.1 har – fordelt på ovenstående principper på niveau A + AA (som er de niveauer, den nuværende lovgivning forlanger, at digitale løsninger skal leve op til) – er indarbejdet i den nuværende udgave af den mere generelle ETSI-standard. Med WCAG 2.2 er et enkelt succeskriterium bortfaldet, mens der er føjet seks nye til. For at give et indblik i omfang og type gennemgås de seks nye succeskriterier herunder (tak til Anne Thyme Nørregaard fra Inklusio for at bidrage til opsummeringen af de nye kriterier):
Tydeligt fokus (Focus Not Obscured)
Når et interaktivt element får tastaturfokus, må elementet ikke være helt skjult af andet indhold.
Det er fx relevant at tjekke, hvis der anvendes sticky header eller footer eller et cookie-banner, som dækker noget af siden, men hvor siden scroller ”inde bagved”.
Bevægelser for at trække (Dragging Movements)
Al funktionalitet, som kræver, at man laver en trækkebevægelse, kan også bruges med et enkelt berøringspunkt og uden at trække.
Hvis løsningen fx indeholder en liste, hvor man kan ændre rækkefølgen af elementer ved at trække dem op og ned, så skal der også stilles en menu til rådighed, hvor man kan vælge at flytte elementet op eller ned. Tilsvarende vil anvendelsen af en videoafspiller, hvor man kan spole i videoen ved at trække i et element på videoens tidslinje, også fx forudsætte, at man kan klikke på tidslinjen for at spole til det ønskede sted.
Størrelse af interaktionsområde (Target Size)
Størrelsen for målområdet for pegeinput (dvs. mus og berøring) er mindst 24 x 24 pixels. Hvis det er et lille mål på under 24 x 24 pixels, må det ikke overlappe andre målområder i et område på 24 pixels omkring det i alle retninger.
Kravet gælder dog ikke for målområder, som er inde i sætninger; eller hvis samme funktion kan opnås et andet sted på samme side/skærmbillede.
Mange vil genkende behovet, hvis man har forsøgt at betjene sin mobiltelefon med én hånd!
Konsistente hjælpefunktioner (Consistent Help)
Dette krav gælder for hjemmesider, som indeholder hjælpefunktioner såsom:
- kontaktinformationer til mennesker, fx telefonnummer eller e-mailadresse
- en mekanisme til at kontakte mennesker, fx en chat eller en kontaktformular
- selvhjælpsmuligheder, fx en FAQ, Help Center eller hjælpetekst, der foldes ud via ”?”-tool tips
- en fuldautomatisk kontaktmekanisme, fx chatbot
Hvis nogle af disse hjælpemekanismer findes på flere sider inden for en samling af websider/skærmbilleder, skal funktionerne findes i den samme relative rækkefølge i forhold til andet indhold på siden, medmindre brugeren selv laver en ændring.
Det kan fx betyde, at en chatfunktion altid skal findes på samme sted på siden, at linket til en kontaktside altid skal kunne findes på samme sted i footeren, eller at hjælpetekster i en formular altid skal kunne findes på samme sted i forhold til indtastningsfelterne, fx bag et ”?”-ikon.
Kriteriet betyder også, at der skal stilles en forståelig brugsanvisning på dansk til rådighed.
Overflødig indtastning (Redundant Entry)
Hvis samme information skal anvendes flere gange i en proces, skal den enten være auto-udfyldt efter første gang eller der skal gives mulighed for, at brugeren kan vælge at bruge den, hvis samme information skal bruges flere steder.
Et velkendt eksempel er webshops, hvor man med en tjekboks kan vælge, at leveringsadressen skal være den samme som faktureringsadressen, eller vælge at indtaste en ny leveringsadresse.
Kravet gælder ikke, hvis det er essentielt at udfylde informationen igen, fx for at bekræfte en e-mailadresse, hvis informationen er vigtig af sikkerhedshensyn.
Tilgængelig autentificering (Accessible Authentication)
En kognitiv funktionstest (såsom at huske et password eller løse et puslespil) må ikke være påkrævet i en autentifikationsproces.
Hvis en sådan anvendes, skal mindst én af følgende stilles til rådighed:
- Alternativ: Der er en alternativ autentifikationsmetode, som ikke er afhængig af en kognitiv funktionstest
- Mekanisme: Der er en mekanisme til rådighed, som kan hjælpe brugeren med at gennemføre den kognitive funktionstest
- Objektgenkendelse: Den kognitive funktionstest består i at genkende objekter
- Personligt indhold: Den kognitive funktionstest er at identificere ikke-tekstligt indhold, som brugeren selv har oplyst i løsningen på et tidligere tidspunkt
Et eksempel på indhold, som ville dumpe dette succeskriterium, er en kontaktformular, hvor man skal indtaste svaret på et tilfældigt genereret regnestykke for at kunne indsende formularen, og hvor der ikke stilles alternative muligheder til rådighed.
Konklusion og anbefalinger
I Trustworks mener vi, at EAA er en vigtig lovgivning, der vil have en positiv indvirkning på digitaliseringen i Danmark.
Tilgængelighed har ofte fået et dårligt ry, fordi det ikke er tænkt ind fra starten af løsningsdesignet. Når man forsøger at ”klistre det på” et ellers færdigt design, kommer det ofte til at ”skæmme” eller være dyrt at implementere.
Hvis den nye lovgivning medvirker til at tænke tilgængelighed ind tidligere, ender vi med at have løsninger, der er æstetisk tiltalende samtidig med at en større brugerskare kan anvende dem – og uden merpris! Men det er også vigtigt, at danske virksomheder forbereder sig på EAA's indførsel.
Her er Trustworks’ 5 anbefalinger til, hvordan danske virksomheder (og borgere) kan forberede sig på EAA's indførsel:
1. Sæt dig ind i de krav, der skal opfyldes
Læs op på EAA's krav: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32019L0882
Sæt dig ind i den danske Tilgængelighedslov: https://www.retsinformation.dk/eli/lta/2022/801
Sæt dig ind i WCAG 2.2: https://www.w3.org/TR/WCAG22
Tjek evt. ESTI-standarden EN 301 549: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
2. Evaluer dine eksisterende løsninger
Få testet dine eksisterende løsninger - både med de automatiske værktøjer, som finder 10-15 procent af problemerne, og med testere, der er vant til at bruge assisterende teknologier (fx skærmlæsere), for at finde resten.
Få indarbejdet rettelse af de fundne problemer i roadmappet for dine mest populære løsninger, så I i videst muligt omfang kan overholde lovgivningen pr. 28. juni 2025 (se også råd #5).
Al nyudvikling skal basere sig på overholdelse af WCAG 2.2 (AA). For eksisterende løsninger er der en transistionsperiode ind til 28. juni 2030 (eller max. 20 år efter den oprindelige introduktion på markedet).
3. Uddan din organisation
Sørg for, at dine udviklingsteams forstår de nye behov og afledte krav til jeres løsninger.
Opsæt klare retningslinjer for, hvordan EEA’s krav skal opfyldes hos jer. Både i forbindelse med nyudvikling, videreudvikling og test af løsningerne (inklusiv klagehåndtering efter ”test i produktion”).
Opdager du, at din løsning ikke overholder lovgivningen, skal du straks indberette det til den tilsynsførende myndighed – for digitale produkter vil det være Sikkerhedsstyrelsen, for digital kommunikation vil det være Energistyrelsen og for digitale løsninger relateret til personbefordring vil det være Trafikstyrelsen eller Søfartsstyrelsen afhængigt af transportmiddel.
4. Sæt realistiske mål for tilgængelighed
Ingen ved, hvor hårdt loven vil blive håndhævet efter juni 2025 (du kan måske huske usikkerheden, fra da GDPR trådte i kraft?), men et vist rimelighedsprincip er forventet. At gøre en eksisterende digital løsning tilgængelig kan være noget af en indsats. En indsats, der er for stor at bære for små virksomheder. Derfor behøver mikrovirksomheder ikke at overholde EAA i 2025 (eller 2030 for eksisterende løsninger).
Kan du demonstrere, at I har gjort en indsat - og i videst muligt omfang overholder lovgivningen (eller har en plan for, hvordan I kommer til det) - bliver der næppe slået (hårdt) ned.
5. Få hjælp fra eksperter på området
Hos Trustworks har vi i mange år arbejdet med tilgængelighed, diversitet og brugervenlighed i det hele taget. Vi har derfor en del erfaringer fra både offentlige og private kunder.
Der findes dog også en række andre eksperter i Danmark – fx Inklusio, Sensus og Aliro Docs – så der er ingen undskyldning for ikke at blive klar til 28. juni 2025.
Elvi's Linkedin: Følg Elvi her!
Nysgerring på flere artikler fra Trustworks? Se mere her!
Mere viden fra Trustworks? Følg os på Linkedin!
