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.
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:
- Brugeren trykker på startpunktet for at aktivere trækkebevægelsen
- 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:
- Understøttelse af adgangskodehuskere for at reducere behovet for at huske, og
- 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.
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.
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.