WCAG 2.2 – på forståeligt dansk

Resume: 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 du får min oversættelse, og har du kommentarer eller rettelser så er du velkommen til at skrive til mig

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 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 være mindste 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 i 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 vigtig 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.2 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

Mobile websider: Danske sider er blandt de langsommeste

Resume: Danske mobilsider ligger i bund, når det gælder indlæsningstider. Det er ikke godt, i en tid hvor tålmodigheden er mindre end nogensinde. I kan selv gøre noget for at optimere hastigheden. (opdateret 4. december 2017 med en ekstra graf)

3 sekunder. Så lang tid har I til at få noget på skærmen, når kunder eller brugere går på mobilen for at løse en opgave. Går der længere tid, så forlader de jer med stor sandsynlighed igen.

Det er de barske tal. Hvordan er virkeligheden så? Nedslående.

Danske mobilsider har faktisk nogle af de langsommeste indlæsningstider i Europa, viser en analyse fra Google.

En oversigt over indlæsningtider i Europa. Danske mobilsider er i gennemsnit 9,5 sekunder om at læse ind.
Danmark har nogle af de langsommeste mobilsider i Europa, viser en analyse fra Google.

Langsomme mobilsider frastøder folk

Når indlæsningstiden overstiger 3 sekunder, er der 53 procent sandsynlighed for, at en bruger forlader sitet.

5 sekunder og sandsynligheden stiger til 90 procent. You do the math.

Konverteringsraten stiger, når indlæsningstiden holder sig under 3 sekunder. Derefter falder den drastisk i takt med, at folk opgiver at vente på, at sitet skal læse ind.
Indlæsningstiden har stor betydning for hvor længe besøgende holder ud at vente på jer. Allerede ved 3 sekunder er konverteringsraten for nedadgående. Det betyder færre kunder i butikken, færre læsere eller flere opkald til supportlinjen. Grafik: LukeW.com

Og læg så oven i, at vi i stigende grad anvender mobilen til at gå på nettet med. Både derhjemme, på arbejde og i forretningerne. Så har vi en seriøs udfordring.

Optimer jeres indhold til mobil, teknisk og indholdsmæssigt

Hvis indlæsningstiden skal ned kræver det sandsynligvis en tur til teknikeren, da en del af processen vil involvere optimering af html, css og javascript-filer.

En overhaling af htmlkoden er som regel aldrig forkert. Mange hjemmesider er bygget efter forældede metoder med unødig meget kode. Det skal væk.

Hvis teknikerne pludselig begynder at snakke om at “gzippe”, “minificere” og “sprites”, så skal I ikke gå i panik. Det betyder nok bare, at de ved, hvad de taler om

I vil også gerne høre dem tale om Progressive Web Apps (PWA) og Accelerated Mobile Pages (AMP), men få det lige forklaret ordentligt.

Komprimer billeder og illustrationer

Der er heldigvis rigtig meget, I selv kan gøre for at komme i gang.

Komprimer jeres billeder så meget, det er muligt. Der er forskel på at downloade 700 kb eller 140 kb, især på en langsom forbindelse.

Derfor må I at vælge det mest optimale billedformat.

Om det skal være JPEG, GIF eller PNG afhænger af flere ting. GIF bruger I udelukkende til grafik og lignende, men om et foto er mest optimalt i JPG eller PNG er ikke altid til at gennemskue på overfladen.

Content Delivery Network (CDN): Send indholdet fra en server tæt på

Hvis jeres website er hostet i udlandet, eller I henvender jer til et internationalt publikum, så få et Content Delivery Network – CDN.

Et CDN kopierer webindhold ud til flere webservere, spredt over hele internettet. Når en webside kaldes, får brugeren altid den version, som er tættest på, hvor man er. Det vil nedsætte indlæsningstiden væsentligt, især hvis I har indhold, som fylder meget.

Der findes masser af udbydere og prisen er som regel ganske rimelig.

Bruger I WordPress, er det oplagt at undersøge WordPress.com’s gratis CDN, som man forbinder til gennem Jetpack.

Brug html fremfor andre teknologier

Nettet er hypertekst. Det fungerer mest effektivt når indholdet er i html. Undgå så vidt det overhovedet er muligt at lægge jeres indhold ud som PDF.

PDF er dårligt på så mange måder, men især på mobil, fordi et PDF-dokument som regel er optimeret til print og ikke til små skærme.

Så lad være med at falde for fristelsen, brug html.

Skriv til nettet – og til små skærme

Optimer jeres indhold til modtagerne. Har I mange mobile brugere, så skal I naturligvis skrive, så det kan læses på små skærme. Overhold de grundlæggende regler for godt netindhold: Skriv kort, skriv skanbart og undgå unødigheder.

Jeg kan lære jer at skrive til nettet.

Test din egen mobilhastighed

Google har et fint værktøj til at undersøge jeres indlæsningshastighed.

Du indtaster din webadresse og får en grafik som nedenstående. Men er du som de fleste, når pilen altså op i det røde område.

Netvenlig.dk kan læses ind på 3 sekunder
Indlæsningstiden for Netvenlig.dk er 3 sekunder. Det er væsentligt lavere end andre sider i it- og teleindustrien og resten af Danmark. Artikler på Netvenlig.dk indlæses via Google AMP-projekt og kan ses næsten øjeblikkeligt, når de søges i Google.

Dårlig streaming på mobilen stresser

Vi bruger mobil til stort set hvad som helst, nu om dage. Men især video er vi rigtig glade for at streame ned. Så når forbindelsen ind i mellem ryger en tur, så bliver vi stressede. Rigtig stressede.

En undersøgelse fra Ericsson ConsumerLab i 2015 viser, at det faktisk kan være mere beroligende at se en skrækfilm, end at opleve et stop i en Youtube-video.

Billedteksten læser: The level of stress caused by mobile delays was comparable to watching a horro movie
“Kognitiv belastning” er betegnelsen for mængden af information, vi kan håndtere i visse dele af hjernen. Når den kognitive belastning overstiger 0,7 anses det for meget højt og stressende. Kilde: Ericsson ConsumberLab, 2015

Blot 2 sekunders ventetid på en Youtube-video kan øge den kognitive belastning målbart, mens en ufrivillig pause når videoen er gået i gang, vil næsten fordoble stressniveauet, viser undersøgelsen.

Undersøgelsen blev i øvrigt foretaget i København, og omfattede smartphonebrugere mellem 18 -52 år.

Kilde: Ericsson Mobility Report “The Stress of Streaming Delays”, 2016 (Ikke tilgængelig på nettet)