WCAG

Lars Michael Sørensen, CPWA

Den europæiske lov om tilgængelighed: Værd at vide om EAA

Resume: Det er ikke for tidligt at blive klar til Den europæiske lov om tilgængelighed. Loven gør det lettere for alle at handle i webshops og anvende digitale og elektroniske tjenester. Loven træder i kraft i 2025. [Artiklen er opdateret den 23. oktober, 2024]

Det europæiske flag er blåt og har 12 stjerner i en cirkel

Når Tilgængelighedsloven træder i kraft den28. juni 2025, bliver internettet for alvor åbent for alle.

Den nye lov stiller både krav til en række helt eller delvist digitale, brugerrettede tjenester, for eksempel:

  • webshops,
  • billetsystemer og transporttjenester,
  • informationsskærme og selvbetjeningsterminaler,
  • banktjenester som er forbrugerrettede,
  • e-bøger og smartphones
  • Styresystemer

Loven omfatter også visse fysiske produkter, som har en digital grænseflade.

Det er det europæiske tilgængelighedsdirektiv, der i daglig tale kendes som Den europæiske lov om tilgængelighed (European Accessibility Act), eller EAA, som udstikker rammerne for, hvordan leverandører og virksomheder skal gøre deres tjenester og produkter tilgængelige.

I Danmark er direktivet blevet omsat til Lov om tilgængelighedskrav for produkter og tjenester, og den kan godt være en mundfuld at læse, så nu er du advaret.

Ikke for tidligt at komme i gang

Den 28. juni 2025 skal alle produkter og tjenester, som er omfattet af loven, overholde kravene. Måske tænker I, at det er langt ude i fremtiden? Det er det ikke.

Webtilgængelighed kan tage lang tid at implementere. Der vil være mange små ændringer. Og der vil være enkelte store, som kan kræve opgradering af styresystemer eller frameworks og måneders arbejde.

I betragtning af, at offentlige websteder havde 12 år til at blive webtilgængelige og alligevel måtte kæmpe for at nå i mål til tiden, så er det ikke spor for tidligt at komme i gang med at se på, hvordan I selv kan inkludere de 15-20 procent af befolkningen, for hvem det er svært eller umuligt at anvende digitalt indhold på en ordentlig måde.

Ikke alt eller alle er omfattet af EAA

Tilgængelighedsloven kommer til at omfatte de fleste digitale og elektroniske tjenester, men direktivet er ikke uden undtagelser:

  • Forudindspillede medier som video, animationer og lydproduktioner er undtaget, hvis de er produceret før skæringsdatoen 28. juni 2025,
  • Dokumenter (PDF og lignende), som er offentliggjort før 28. juni 2025,
  • Onlinekort og korttjenester, med mindre de bruges til navigation
  • Tredjepartsindhold, som for eksempel medieafspillere på sociale medier (YouTube og andre), som virksomheden ikke har betalt for eller udviklet på,
  • Arkiveret indhold, der ikke er opdateret eller redigeret efter 28. juni 2025.

Mikrovirksomheder er også undtaget: Har man mindre end 10 ansatte og omsætter man for mindre end 2 millioner Euro om året, er man ikke omfattet (§12, stk 2).

En uforholdsmæssig stor byrde

Tilgængelighedsloven har også kattelemmen om “uforholdsmæssig stor byrde”, som vi også kender fra webtilgængelighedsloven, men i en noget strammere udgave:

Specifikke tilgængelighedskrav finder anvendelse på alle produkter og tjenester, der er omfattet af lovgivningen, i det omfang at overholdelse ikke medfører en grundlæggende ændring af produktets eller tjenestens grundegenskab eller en uforholdsmæssig stor byrde for de pågældende erhvervsdrivende. 

I Tilgængelighedsloven er Bilag 5 dedikeret til “Kriterier for vurdering af uforholdsmæssig stor byrde”. Her kan man systematisk gennemgå kravene og undersøge om et produkt eller en ydelse falder ind under kravet.

En af udfordringerne med webtilgængelighedsloven har altid været, at tolkningen af “Uforholdsmæssig stor byrde” i høj grad har været op til myndigheden selv.

Samtidig, har kontrollen med webtilgængelighedserklæringen ikke været god nok. Rigsrevisionen gik ind i sagen, og det endte med kritik fra Statsrevisorerne.

Konsekvensen af ikke at være klar

I modsætning til webtilgængelighedsloven for offentlige websteder, så er der alvorlige konsekvenser, hvis man ikke overholder tilgængelighedskravene:

  1. Produktet eller tjenesten fjernes fra markedet og må ikke sælges eller markedsføres
  2. Man får en bøde.

1: Produktet må ikke sælges eller markedsføres

Virksomheder, der ikke har gjort deres arbejde færdigt inden loven træder i kraft kan få et problem. Loven er nemlig meget klar i mælet:

Produkter og tjenester må kun bringes i omsætning eller leveres, hvis de opfylder de relevante tilgængelighedskrav i bilag 1, jf. §§ 5 og 6.

2: Man får en bøde

Ligesom med webtilgængelighed i det offentlige, vil der være kontrol af tjenesterne. Og overholder man ikke kravene kan der falde bøder (Kapitel 11, § 57).

Den præcise bødestørrelse i Danmark er ikke meldt officielt ud, men i oktober 2024 er svaret, at de forventes at ligge i størrelsesordenen kr. 50.000,-

Det er billigt sluppet. Tyskland og Irland har begge ikke-ubetydelige bøder i størrelsesordenen € 100.000. Irland har desuden fængselsstraf på programmet. Ja. Fængselsstraf.

Sådan kommer I i gang

Det er her, den dårlige nyhed kommer: Sikkerhedsstyrelsen har tovholderiet for loven. De har skrevet en kort vejledning om EAA og den danske lovgivning. Men der ud over er det forbavsende lidt information, det er muligt at finde om de præcise krav og forventninger.

Det er dog ikke noget, som forhindrer jer i at gå i gang med det samme, ud fra det vi ved nu. Min forventning er, at standarderne ikke kommer til at ændre sig væsentligt fra det, vi allerede arbejder med, når offentlige websteder skal gøres tilgængelige.

I praksis skal I kende følgende standarder:

  • WCAG 2.1, helst WCAG 2.2
  • EN 301 549 (som tidligst er færdigrevideret i december 2025)
  • EN 17161, Design for Alle (Universelt Design)

I kan også bare kontakte mig.

Slå til nu, hvis I vil have en konkurrencefordel og en bid af kagen, når hver 6. dansker pludselig får nemmere adgang til at købe og anvende jeres produkter og tjenester.

Skaf jer den nødvendige viden om webtilgængelighed og få lavet en tilgængelighedsevaluering, der giver jer det nødvendige overblik til at få rettet fejl og mangler og gør det muligt for jer at få 5 års forspring fra konkurrenterne!

Får I brug for hjælp? (Det gør I nok)
Ring eller skriv til Netvenlig: Telefon 40 93 21 98 lmsoren@netvenlig.dk
Lars Michael Sørensen, CPWA

WCAG 2.2 – på forståeligt dansk

Resume: [OPDATERET november 2024] Lær de nye succeskriterier i WCAG 2.2 at kende. Læs om dem på forståeligt dansk og få en forklaring på, hvad de betyder.

Efter et års forsinkelse og utallige nær-ved publiceringer, lykkedes det endelig W3C at udgive WCAG 2.2 i starten af oktober 2023.

Det har givet os i alt ni nye kriterier, fordelt således:

Her får du en gennemgang af kriterierne på niveau A og AA, og hvad de i store træk betyder.

Kriterierne er ikke oversat til dansk endnu, så den præcise ordlyd kender ingen. Men her er min egen oversættelse, og har du kommentarer eller rettelser så er du velkommen til at skrive til mig

(Note: Der er tale om en manuel oversættelse, ikke maskinoversættelse. AI har ikke været involveret, på noget tidspunkt).

Niveau A: (Det essentielle niveau)

Niveau A er det vigtigste af WCAG’s tre niveauer. Der er nu to nye kriterier i WCAG 2.2, som skal gøre det lettere at finde hjælp og undgå overflødige indtastninger.

3.2.6 Consistent Help (“Konsekvent hjælp”)

“Hvis en webside indeholder nogen af de følgende hjælpemekanismer, og disse mekanismer gentages på flere websider i et sæt af websider, optræder de i samme relative rækkefølge, med mindre en ændring er foretaget af brugeren:

  • Kontaktoplysninger til et menneske
  • Kontaktmekanisme til et menneske
  • Mulighed for selvhjælp
  • Fuldautomatiseret kontaktmekanisme”

Det betyder 3.2.6 Consistent Help (“Konsekvent hjælp”)

En “mekanisme” er et af de der dejlige WCAG-ord, som man altid studser lidt over. Men den formelle definition af “Mekanisme” er: “En proces eller teknik til at opnå et resultat”. Typiske “mekanismer” er knapper, links eller andre interaktive elementer. Altså noget, som kan få et eller andet til at ske.

Dette kriterie har samme formål som 3.2.3  Konsekvent navigation og 3.2.4 Konsekvent identifikation, nemlig at sikre, at hjælp og vejledning altid har den samme relative placering på et websted, når det vises med den samme skærmbredde.

På andre skærmbredder er hjælpen et andet sted på siden, men den beholder den samme relative rækkefølge og placeringen flytter sig ikke ved sideskift.

3.3.7 Redundant Entry (“Overflødig indtastning”)

“Information der tidligere er indtastet eller leveret af brugeren, og som kræver genindtastning i den samme proces, er enten:

  • Automatisk udfyldt eller
  • tilgængelig for brugeren som en valgmulighed

Undtagen når:

  • Genindtastning af informationen er essentiel
  • Informationen er påkrævet af hensyn til sikkerheden i indholdet, eller
  • den tidligere indtastede information ikke længere gælder”

Det betyder 3.3.7 Redundant Entry (“Overflødig indtastning”)

Det vigtigste formål med kriteriet er at nedsætte den kognitive belastning, så brugeren ikke skal huske så meget og indtaste oplysninger, der allerede er indtastet tidligere.

Her taler vi ikke så meget om personoplysninger, der allerede er dækket af 1.3.5 Identificering af inputformål, men om andre typer information, som det af forskellige årsager er nødvendigt at indtaste igen.

Kriteriet forhindrer gentagne indtastninger og siger, at enten skal systemet selv udfylde informationerne eller de skal være tilgængelige som for eksempel en drop downliste, en liste af checkbokse eller noget tilsvarende.

Tilbage til oversigten

Niveau AA: (Det vigtige niveau)

Hvis indhold skal kunne fungere tilfredsstillende for alle, så er kriterierne i niveau AA nødvendige at få med. Det er derfor, at man generelt anbefaler at overholde niveau AA.

De fire nye kriterier i WCAG 2.2 skal gøre det lettere at læse, anvende og få adgang til indhold.

2.4.11 Focus Not Obscured (Minimum) (“Fokus er ikke skjult (Minimium)”)

“Når en brugergrænsefladekomponent modtager tastaturfokus, er komponenten ikke fuldstændig skjult på grund af forfatterskabt indhold.

Note 1: Hvor indhold i en konfigurerbar grænseflade kan omplaceres af brugeren, så skal kun den oprindelige position af det bruger-flytbare indhold tages i betragtning ved test og overholdelse af dette Succeskriterium.

Note 2: Indhold som åbnes af brugeren må skjule komponenten som modtager fokus. Hvis brugeren kan finde komponenten i fokus uden at skifte tastaturfokus, anses komponenten ikke for at være skjult på grund af forfatterskabt indhold.”

Det betyder 2.4.11 Focus Not Obscured

De typiske årsager til at fejle dette kriterium er hvis tastaturafhængige brugere ikke kan se hvor de har tastaturfokus, fordi noget andet indhold dækker for links eller kontroller.

Problemet opstår meget ofte med det man på godt dansk kalder “sticky” indhold: En header eller et banner, der bliver siddende (“klistrer”) på siden og kommer til at dække for andet indhold, når man scroller op eller ned ad den.

Visse navigationsbjælker, cookiebannere og chatvinduer er eksempler på den slags indhold.

Note 1 handler om, at hvis man kan flytte på den komponent, som dækker for indholdet, så er det komponentens oprindelige placering, der er afgørende for om kriteriet er overholdt.

Note 2 Siger, at ting som for eksempel en dropdown-menu ikke er omfattet af kriteriet, fordi den godt nok falder ned foran andet indhold, men forsvinder så snart fokus ændres.

2.5.7 Dragging Movements (“Trækkebevægelser”)

“Al funktionalitet, som bruger en trækkebevægelse i anvendelsen, kan opnås med et enkelt kontaktpunkt uden træk, med mindre træk er nødvendigt eller funktionaliteten er bestemt af brugeragenten og ikke ændret af forfatteren.

Note: Dette krav er beregnet på webindhold som tolker pegehandlinger (det vil sige, at det ikke anvendes på handlinger der er krævet for at anvende brugeragenten eller en hjælpeteknologi).”

Det betyder 2.5.7 Dragging Movements

At trække et element hen over en skærm fra A til B, er mere end bare en smart måde at engagere brugeren på. Det kan også være en sikkerhed for, at brugeren faktisk mener at gennemføre den handling man er i gang med. MobilePay har for eksempel en vandret trækkebevægelse som den sidste handling, inden man sender pengene. På den måde, er det svært at komme til at sende dem ved en fejl.

Men ikke alle har kræfter, syn eller præcision nok til at kunne udføre trækkebevægelser. Andre kan slet ikke udføre handlingen, fordi de anvender hjælpeteknologier som pegepind, øjenbevægelser eller stemmestyring.

Derfor er der nødt til at være en alternativ måde at udføre trækkebevægelsen på. Samtidig er det et krav fra 2.1.1 Tastatur, at alternativet er tilgængeligt ved hjælp af tastatur.

Det kunne for eksempel være:

  1. Brugeren trykker på startpunktet for at aktivere trækkebevægelsen
  2. Brugeren trykker på slutpunktet (destinationen) for at fuldføre den

Hvis du synes det lyder lidt bekendt, så er det nok fordi du tænker på 2.5.1 Pegebevægelser (Pointer Gestures). Men det kriterie handler om stibaserede bevægelser og tager hele ruten fra A til B i betragtning. Det handler også om flerpunktsbevægelser – det vi på dansk kalder gestik eller “Gestures” på engelsk, altså når vi swiper, roterer eller zoomer med fingrene på en skærm.

2.5.8 Target Size Minimum (“Minimum målstørrelse”)

Størrelsen på mål til pegeinput skal være mindst 24 x 24 CSS pixel. Undtagen hvis:

  • Afstand: Hvis flere små mål (under 24 x 24 CSS pixel) er placeret sådan, at hvis en cirkel med 24 CSS Pixel i diameter er placeret i centrum af afgrænsningskassen for hvert mål, så overlapper cirklerne ikke andre mål eller andre små mål
  • Ekvivalent: Målets funktion kan opnås gennem en kontrol på den samme side, der opfylder dette kriterium
  • Indlejret (Inline): Målet er i en sætning eller dets størrelse på anden måde er begrænset af linjehøjden på tekst, som ikke er i målet.
  • Kontrolleret af brugeragenten: Målets størrelse er bestemt af brugeragenten og er ikke ændret af forfatteren
  • Essentiel: En bestemt præsentation af målet er essentielt eller et lovkrav for den information, der formidles.

Note 1: Mål, hvis værdier kan vælges rumligt efter en position inde i målet, anses for at være et enkelt mål i forhold til dette succeskriterium. Eksempler inkluderer skydeknapper, farvevælgere med en farveskala eller redigerbare områder, hvor man placerer en markør.

Note 2: I indlejrede mål skal linjehøjden tolkes som vinkelret i forhold til den retning teksten flyder. For eksempel i et sprog, som vises lodret, vil linjehøjden være vandret.

Det betyder 2.5.8 Target Size Minimum

Dette er et af de nyttigste kriterier i hele WCAG 2.2. Det løser nemlig et problem som alle der taster på en skærm jævnligt oplever.

Jeg taler om “Fat Finger”-syndromet: den superirriterende oplevelse det er at ramme en forkert tast eller knap, fordi flere elementer sidder for tæt op ad hinanden. Tænk “Mobiltastatur” og du ved, hvad jeg mener.

Måden kriteriet skal forstås er, at det klikbare område i et interaktionselement er mindst 24 x 24 CSS pixel, altså lodret og vandret.

Hvis elementerne er mindre end 24 CSS pixel skal afstanden mellem to elementer svare til, at man kan lave en cirkel med en radius på 24 CSS-pixel i centrum af elementernes klikbare område, uden at cirklerne overlapper.

Dermed får man tilstrækkelig luft både lodret og vandret mellem to elementer til at reducere risikoen for fejltryk.

3.3.8 Accessible Authentication Minimum (“Minimum tilgængelig godkendelse”)

“En kognitiv funktionstest (så som at huske en adgangskode eller løse en gåde) er ikke krævet i noget trin i en godkendelsesproces, med mindre trinnet stiller mindst en af de følgende muligheder til rådighed:

  • Alternativ: En anden godkendelsesmetode, som ikke benytter en kognitiv funktionstest
  • Mekanisme: Der er en mekanisme til stede, som kan hjælpe brugeren med at løse den kognitive funktionstest
  • Objektgenkendelse: Den kognitive funktionstest går ud på at genkende et objekt
  • Personligt indhold: Den kognitive funktionstest går ud på at identificere ikke-tekstbaseret indhold, som brugeren afgiver til webstedet.

Note 1: “Objektgenkendelse” og “Personligt indhold” må repræsenteres af billeder, video eller lyd.

Note 2: Eksempler på mekanismer, der opfylder dette kriterie omfatter:

  1. Understøttelse af adgangskodehuskere for at reducere behovet for at huske, og
  2. Kopiere og indsætte (“Copy and paste”) for at reducere den kognitive belastning ved at genindtaste.”

Det betyder 3.8.8 Accessible Authentication Minimum

3.8.8 er godt nyt til alle os, som har prøvet at glemme en adgangskode.

En vigtig detalje ved kriteriet er nemlig, at det forudsætter, at brugeren ikke behøver at skulle huske et login til et websted, men kan godkende sig ved hjælp af andre metoder.

Kriteriet rammer også CAPTCHA: Det er de meget svært læselige bogstaver, som du skal indtaste i et felt, for at bevise, du ikke er en bot. De er svære at løse for mange, men for nogle er de nærmest umulige at komme igennem.

3.8.8. forudsætter, at der er mindst et alternativ til den type tests, som for eksempel, at der slet ikke er en kognitiv funktionstest, som fingeraftryk eller ansigtsgenkendselse.

Man kan også gøre det muligt at bruge adgangskodehuskere som Bitwarden, Keepass eller browsernes indbyggede tjenester. Det kan alle almindelige loginformularer allerede, hvis de overholder 1.3.5 Identificering af Inputformål og 4.1.2 Navn, Rolle, Værdi.

En tredje mulighed er, at brugeren skal genkende et objekt, som for eksempel “Tryk på billedet af et æble”.

Endelig, må man også benytte personligt indhold. Nogle genkendelsessystemer gør det muligt for brugeren at uploade et billede, for eksempel af sig selv. Når brugeren logger ind, bliver man bedt om at vælge det billede, man selv har uploadet, ud fra en liste af billeder.

Tilbage til oversigten

Niveau AAA: (Det nyttige niveau)


Endelig er der kommet tre kriterier på niveau AAA.

De er gode at kende, men deres vigtigste formål er at udvide andre kriterier på niveau AA. De er:

Og mere vil jeg egentlig ikke sige om dem. For nu.

Tilbage til oversigten

WCAG 2.2 siger farvel til 4.1.1

Et enkelt kriterium fra WCAG 2.1 – nemlig 4.1.1 Parsing er fjernet fra WCAG 2.2.

I version 2.1 er kriteriet opdateret til “forældet” og har fået to noter, som forklarer, at vi dybest set ikke længere behøver forholde os til, om koden kan validere efter HTML-standarderne.

Og det er udmærket, for den har altid været en sikker taber i stort set alle websteder jeg har evalueret, har kostet mange udviklertimer, og de senere år har det stort set ikke været til gavn for ret mange.

Tilbage til oversigten

Brug for at blive klogere?
Jeg holder både åbne kurser og specialtilpassede firmakurser over hele landet. Ring eller skriv til Netvenlig: Telefon 40 93 21 98 lmsoren@netvenlig.dk
Lars Michael Sørensen, CPWA

107 tryk: Regionerne fejler egen coronatest

Resume: Det tager absurd mange tabulatortryk at nå den nye corona-chatbot, der skal lette presset på sundhedsvæsenet. Ingen af regionerne har prioriteret testen, så den får hurtigt fokus for tastaturafhængige brugere.

Knappen til Regionernes Corona-selvtest. Knapteksten siger: Test her Coronavirus-sygdom
“Test her – Coronavirus-sygdom” Knapteksten er i sig selv en artikel værd. Men det bliver en anden gang.

Danske Regioner har udgivet en digital chatbot, som gør det muligt selv at undersøge, om man måske kan være smittet med Coronavirus.

Et fint initiativ der måske kan lette presset på landets hospitaler og de privatpraktiserende læger, som lige nu er superhårdt spændt for.

Desværre fejler regionerne stort, når det gælder implementeringen af tjenesten.

Tusindvis anvender tastaturet som navigation

For at forstå årsagen er vi nødt til at have baggrunden med: Det er nemlig langt fra alle borgere, som er i stand til at anvende en mus.

En mus er et præcisionsinstrument, som kræver en høj grad af finmotorik, for at fungere optimalt. Kan man ikke anvende en mus, er alternativet ofte at anvende tastaturet, typisk Tabulator-tasten, piletaster, mellemrumstasten og så videre.

Spektret af helt eller delvist tastaturafhængige brugere er faktisk ganske bredt. I flæng kan nævnes:

  • Blinde (cirka 25.000)
  • Nedsat motorik (cirka 250.000)
  • Gigtramte (cirka 700.000)
  • Personer med tremor eller Parkinsons (cirka 100.000)

Og det er bare de grupper, jeg først kom i tanke om. Det er cirka 1 million danskere, som i større eller mindre grad er tastaturdominante.

Det er mange mennesker, og det er derfor, at WCAG 2.1 har en hel sektion, der udelukkende handler om tastaturbrug.

Retningslinje 2.1  hedder “Tilgængelig via tastatur” og siger kort og godt: “Alle funktionaliteter skal kunne benyttes via et tastatur.”

107 tryk fra start til mål

Jeg tog et kig på, hvordan regionerne har implementeret knappen. Det viser sig, at det i gennemsnit tager 107 tryk at nå det link, der starter chatbotten.

Lad mig lige gentage: 107 tryk, i gennemsnit. Et Nul Syv!

Antal tryk til Selvtest-knappen:
Region Antal tryk
Hovedstaden 114
Sjælland 101
Nordjylland 174
Syddanmark 51
Midtjylland 98

Tallene er beregnet som antal tryk fra adressefeltet til browseren havde fokus på knappen.

Hvor der var skiplinks har jeg ikke aktiveret dem, ud fra det argument, at man som blind ikke har nogen chance for at vide, hvor på siden selvtesten befinder sig: Springer man navigationen over, kan man også risikere at springe linket til testen over. Man er derfor nødt til at tabulere sig gennem junglen af links og håbe på det bedste.

174 Tabulatorklik til Region Nordjyllands Coronatest-knap
Region Nordjylland sætter muligvis danmarksrekord for længst vej til et element. 174 tryk på TAB-tasten, inden man er fremme ved målet.

Skiplinks kan også kun gøre så meget, i den aktuelle situation. Tager man region Nordjylland kan man godt nok spare 99 klik ved at bruge skiplinket, javel. For nogle vil det naturligvis betyde noget. Men der er altså stadig 75 klik til målet, så vi er stort set lige vidt.

To nemme løsninger på problemet:

1: Flyt knappen op i toppen af koden

Alle regionerne har sat koden ind som det sidste element på siden. Det betyder, at hvis man ikke gør noget for at ændre det, så bliver det også det sidste element som får fokus, når man tabulerer.

Derfor bør knappen flyttes op i toppen af koden. Kan den ikke det, bør den rettes til, så det kan lade sig gøre at give den fokus som det første element i rækkefølgen.

2: Lav en rigtig knap, ikke et pænt link

Regionerne havde faktisk en sidste mulighed for at redde lidt af æren: Skærmlæsere er nemlig supergode til at identificere forskellige elementer og præsentere dem på genvejssider for nem adgang.

Det er for eksempel ikke nogen stor kunst at åbne en elementliste undersøge, om adgangen til coronatesten måske skulle foregå via en knap, og så gå til den den vej.

Visuelt fremstår knappen jo også som en knap. Men i virkeligheden er det bare et link, der er stylet som en knap.

Den letteste løsning er naturligvis at bruge <button>-elementet og så style det, så det ligner, hvad man nu gerne vil have det til at ligne.

Men kan man virkelig ikke komme uden om at anvende et link, så tilføjer man i det mindste en ARIA role=”button”. Det er desværre en grundlæggende tilgængelighedsfejl og jeg håber, at den snart forsvinder, for det er faktisk til at undgå.

ARIA-roller kan omdanne links til knapper i en skærmlæser
Hvad angår skærmlæsere, så fremstår linket til testen nu som en knap og kan derfor identificeres som en knap – og derfor hurtigt findes i skærmlæserens elemenliste. Klassisk tilgængelighed! Bemærk i øvrigt, den noget lamme tekst: Open Chatbot… Helt ærligt!

Overholder regionerne så WCAG? Ja, teknisk set gør de jo. Man KAN jo godt nå linket med tastaturet. Man skal bare stå op i god tid og smøge ærmerne op. Og hey – vi har jo alligevel ikke andet at lave i disse dage.

Lær om webtilgængelighed
Firmakursus: Lær om webtilgængelighed og WCAG 2.1 Afholdes online eller hos jer. Priser fra 15.400,- eks moms. Du kan også tage et åbent kursus i WCAG 2.1
Lars Michael Sørensen, CPWA

Guide: Angiv sidens sprog korrekt

Resume: Som webredaktør er det vigtigt at kunne skifte en sides sprog helt, eller delvist. Lær at overholde WCAG 3.1.1 og 3.1.2, og gør dit indhold tilgængeligt på alle sprog.

Når du udgiver indhold, der er i et andet sprog end sidens standardsprog, skal du huske at fortælle kompenserende teknologier som skærmlæsere og oplæsningssoftware, at her kommer noget tekst, som er i fremmedsprog.

Guide til at skifte sprog midt i en tekst

Du skifter sproget sådan her:

Find den tekst, der skal ændres og tilføj sproget således:

<p lang="en">This text will be read aloud in english</p>

Nu har du givet afsnittet, der er omkranset med <p>-koden et nyt sprog, og skærmlæsere kan tolke det korrekt.

Bonus: Egenskaben virker på alle koder.

Mere er der ikke i det, men hvis du virkelig vil, så kan du faktisk også skifte dialekt. For eksempel vil du kunne skifte til Britisk Engelsk med “en-GB” eller amerikansk engelsk med “en-US”.

Et forbehold: Du har nu gjort, hvad du kan og skal. Men det er ingen garanti for, at alle teknologier også forstår din hensigt: Jeg har personligt bøvlet en del med den nye oplæser i Microsoft Chromium Edge, og har stadig ikke fundet ud af, hvordan jeg får den til at skifte sprog frem og tilbage.

Hvorfor det er vigtigt at skifte sprog

Det sker kun sjældent, at websider kan slå folk ihjel, men vi har tidligere kigget på et eksempel fra Sundhedsstyrelsen, som i en periode havde angivet det forkerte sprog på siden om Coronavirus, og dermed gjort indholdet utilgængeligt for personer, der anvender skærmlæser.

I den aktuelle situation, kunne det få alvorlige konsekvenser for nogle borgere, og det vil vi som regel gerne undgå.

Det siger WCAG om sprog på siden

At undlade at angive en sides korrekte sprog er en overtrædelse af WCAG 3.1.1 (A), som siger:

3.1.1 Sproget på siden

Det menneskelige sprog, som er standard for hver webside, kan bestemmes programmeringsmæssigt.

Kildekoden til en webside, hvor sidens sprog er angivet til dansk
Sproget sættes en gang for alle i html-tagget. Det gøres med koden lang=”da” og er en triviel opgave for en webudvikler.

For at angive sidens globale sprog, anvender vi nøjagtig den samme egenskab, på nøjagtig samme måde. Den sidder bare på det yderste element i HTML-koden og gælder derfor på alt indhold, indtil det ændres.

Det er en teknisk ting og som webredaktør har du sjældent indflydelse på den del af koden.

Det har du der i mod på det indhold, du selv lægger op. Og derfor er det vigtigere for dig at kende WCAG succeskriteium 3.1.2 (AA):

3.1.2 Sprog, der anvendes til dele af indhold

Det menneskelige sprog, der anvendes i hver passage eller frase i indholdet, kan bestemmes programmeringsmæssigt. Undtaget herfra er egennavne, tekniske termer, ord med ubestemmelig sproglig baggrund samt ord eller vendinger, der er blevet en del af sprogbrugen i den tekst, de umiddelbart indgår i.

Nu ved du hvordan, du skal gøre det. Og hvorfor. Tillykke med det!

Lær om webtilgængelighed
Firmakursus: Lær om webtilgængelighed og WCAG 2.1 Afholdes online eller hos jer. Priser fra 15.400,- eks moms. Du kan også tage et åbent kursus i WCAG 2.1