WCAG 2.2 – ny anbefaling

Forfatter: Tommy Olsson

Ekspert på universell utforming av ikt

tommy.olsson@useit.se

Publisert 6 oktober 2023

Lesetid 20 minutter

Artikkel

Web Content Accessibility Guidelines (WCAG) kan sammenlignes med steintavlene som Moses angivelig bar ned fra Sinai-fjellet for en god stund siden, men for den digitale verden. WCAG utgjør grunnlaget for mye av lovgivningen om universell utforming av ikt rundt om i verden. Her i Europa henviser standarden EN 301 549 til WCAG, og i Norge henviser loven om universell utforming av nettsteder og mobilapplikasjoner til EUs webdirektiv (WAD) – og – snart love om felles regulering av krav til tilgjengelighet for visse produkter og tjenester (EUs tilgjengelighetsdrektiv, EAA).

Versjon 1 av WCAG ble utgitt i 1999. Versjon 2.0 kom i 2008, og i 2018 ble den oppdatert til versjon 2.1. Nå er det på tide med en ny oppdatering, mens vi venter på en fremtidig versjon 3.0, som har fått navnet WCAG 2.2.

WCAG 2.2 introduserer 9 nye krav, som kalles kriterier i WCAG, i tillegg til at det fjerner et krav som har vært med siden 1999.

Kriteriene i WCAG er delt inn i tre ulike nivåer, som kalles A, AA (dobbelt-A) og AAA (trippel-A). En nettside, et dokument eller en app kan oppfylle et bestemt nivå. Å oppfylle AA-nivået (som kreves av EN 301 549) innebærer at man oppfyller alle kriteriene på nivåene A og AA, men ikke nødvendigvis alle kriteriene på nivå AAA.

De nye kravene omfatter blant annet:

• hjelpefunksjoner
• fyll inn informasjon bare én gang
• alternativer til å dra med musen eller berøringsskjermen
• minimumsstørrelse for klikkbare objekter
• fokuseringsmarkering (3 kriterier)
• autentisering (2 kriterier).

Krav som er fjernet i WCAG 2.2

Det tidligere kravet, 4.1.1 Parsing (nivå A), som tidligere krevde at nettsider skulle følge bestemte aspekter av HTML-spesifikasjonen, er nå fjernet. Tidligere kunne man bruke en valideringstjeneste (som fungerer som en slags stave- og grammatikkkontroll for HTML-koden) for å sjekke om koden overholdt spesifikasjonen. Feil i koden kunne føre til at hjelpemidler, som skjermlesere, ikke kunne formidle innholdet på en korrekt måte til brukeren.

Noen kan argumentere for at en nettredaktør eller nettutvikler burde ha god kjennskap til HTML. Dette er en grunnleggende ferdighet som en gjennomsnittlig person kan lære seg på en eller to dager. Imidlertid jobber mange redaktører i dag med pek-og-klikk-grensesnitt som begrenser deres evne til å gjøre endringer. Mange som kaller seg utviklere, tror også at HTML er «gammeldags» og kopierer dårlig JavaScript fra Stackoverflow i stedet.

Derfor består det meste av HTML-spesifikasjon nå beskrivelser av hvordan ugyldig kode skal tolkes. Nettlesere og hjelpemidler må nå kunne gjette hva en uerfaren redaktør eller utvikler egentlig mente med koden, i stedet for hva de faktisk skrev.

WCAG 2.2 har derfor fjernet kravet om gyldig HTML, med begrunnelsen at moderne hjelpemidler ikke lenger tolker HTML-koden direkte, men heller samhandler med nettleserens grensesnitt. Ansvaret er dermed skiftet fra redaktør og utviklere til nettleseren, og dette legaliserer «taggsuppe» (HTML uten en klar og meningsfull struktur).

HTML-spesifikasjonen (på engelsk).

Nye krav i WCAG 2.2

Hjelpefunksjoner (3.2.6)

Det nye kriteriet, 3.2.6 Consistent Help (nivå A), betyr at visse typer hjelpefunksjoner som finnes på flere sider, må ha den samme relative rekkefølgen i forhold til annet innhold (med mindre brukeren angir noe annet).

De hjelpefunksjonene som dette kriteriet gjelder for, inkluderer:

• kontaktopplysninger som e-postadresse og telefonnummer
• kontaktmuligheter for menneskelig hjelp
• FAQ (ofte stilte spørsmål), hjelpeguider, brukerstøtte og dokumentasjon
• chatbots og lignende automatiserte hjelpefunksjoner.

Kriteriet betyr ikke nødvendigvis at du må ha alle disse hjelpefunksjonene, og heller ikke at de må være tilgjengelige på alle sider. Men hvis noen av dem finnes på flere sider, skal de altså være plassert på samme sted i forhold til annet innhold, slik at de er enkle å finne.

For eksempel kan det bety at kontaktopplysningene alltid vises i bunnteksten, at en lenke til FAQ alltid finnes i toppmenyen, og at en ikon som starter en chatbot alltid er å finne på slutten av artikkelen.

Kontaktmuligheter for menneskelig hjelp kan for eksempel være et kontaktskjema der du får svar via e-post, eller en chatfunksjon der du kan kommunisere med en ekte person (ikke en chatbot).

Kravet betyr heller ikke at funksjonene alltid må være på nøyaktig samme sted visuelt sett. De kan variere avhengig av faktorer som skjermstørrelse, bruk av forstørrelse, og så videre. Men så lenge betingelsene er de samme, skal funksjonene alltid være plassert på samme måte i forhold til annet innhold. For eksempel bør ikke chatikonet være i starten av én side og i slutten av en annen.

For de fleste nettsider vil dette kravet trolig ikke ha noen stor innvirkning, da de allerede har plassert hjelpefunksjonene på en konsekvent måte.

Fyll inn informasjon bare én gang (3.3.7)

Det nye kriteriet 3.3.7 Redundant Entry (nivå A) innebærer at brukere skal unngå å måtte fylle ut de samme opplysningene flere ganger i løpet av samme prosess. Informasjon som brukeren allerede har angitt én gang og som trengs senere i samme prosess, bør enten fylles ut automatisk av tjenesten eller tilbys som forslag.

Dette gir en bedre opplevelse for brukere som kan ha vanskeligheter med å taste inn informasjon, for eksempel på grunn av dysleksi, begrenset finmotorikk eller fordi trenger alternative måter å taste inn tekst på, noe som ofte kan være tidkrevende og utfordrende (som øyestyring).

Dette kriteriet hjelper også brukere med å unngå å måtte huske nøyaktig hva de har skrevet tidligere, noe som er spesielt nyttig for de som har utfordringer knyttet til korttidsminnet eller andre kognitive utfordringer.

Det er viktig å merke at kravet gjelder kun for én prosess - det betyr ikke at tjenester må lagre informasjon for senere bruk i en annen økt eller i en annen tjeneste.

Det finnes noen unntak fra dette kravet:

• Dersom det er en nødvendig del av tjenesten at brukeren må angi informasjonen på nytt, for eksempel i tilfelle spill som er avhengige av brukerens hukommelse.
• Av sikkerhetsgrunner, for eksempel når man oppretter et nytt passord og må skrive det inn to ganger for å redusere risikoen for feiltasting når man ikke ser hva man skriver.
• Dersom den tidligere inntastede informasjonen ikke lenger er gyldig.

Kravet fastsetter ikke hvilke felt som skal benyttes, og det er ikke nødvendigvis forbudt å kreve dobbelt inntasting av visse opplysninger, men det er viktig å vurdere nødvendigheten og brukervennligheten i slike tilfeller.

Selv om dette kravet potensielt kan føre til visse begrensninger i enkle tjenester, bør det ikke medføre betydelige tekniske utfordringer, da kravet er avgrenset til å gjelde innenfor samme prosess.

Alternativ til å dra med musen eller berøringsskjermen (2.5.7)

Det nye kriteriet 2.5.7 Dragging Movements (nivå AA) innebærer at funksjoner der brukeren normalt skal dra et objekt med musen eller bruke berøringsskjermen med fingrene, må kunne utføres på en alternativ måte med musen eller en finger, uten behov for å dra objekter.

Brukere med redusert bevegelighet eller finmotorikk kan oppleve vanskeligheter med å utføre dra-handlinger. Slike handlinger krever flere grep; først trykke eller klikke for å angi startpunktet, deretter å holde fingeren eller museknappen nede mens man flytter markøren, for til slutt å slippe opp når man når sluttpunktet. De som bruker forstørrende hjelpemidler, kan kanskje ikke engang se både start- og sluttpunktene samtidig.

En funksjon for å panorere en virtuell tavle kan for eksempel tilby knapper som brukeren kan klikke på for å panorere oppover, nedover, høyre og til venstre i stedet for å dra. En sortérbar-liste eller tabell kan ha knapper som lar brukeren flytte en markert rad oppover eller nedover. En glidebryter kan inkludere knapper for å øke eller redusere verdien.

Det er verdt å merke seg at det allerede tidligere har vært krav om at funksjoner for mus og berøringsskjerm også må kunne utføres med tastaturet. Men dette er ikke tilstrekkelig for å oppfylle 2.5.7, som krever at funksjonene skal kunne utføres med mus eller berøringsskjerm, men uten å dra.

Et annet kriterium som har eksistert i noen år, er 2.5.1 Pekerbevegelser (nivå A), som omhandler at innhold på nettsiden skal kunne brukes med enkel pekerinput. Dra-handlinger faller ikke inn under 2.5.1, siden det kun er start- og sluttpunktene som er relevante for funksjonen, ikke selve bevegelsen mellom dem.

Unntakene fra dette kriteriet gjelder funksjoner som er essensielle og ikke kan realiseres uten dra-handlinger, samt funksjoner som er innebygd i nettleseren eller operativsystemet, for eksempel å rulle på en berøringsskjerm.

Dette kriteriet kommer til å medføre ekstra arbeid for tjenester som har dra-og-slipp-funksjoner. Samtidig lukker det gapet som 2.5.1 etterlot åpent, og det er positivt.

Minimumsstørrelse for klikkbare objekter (2.5.8)

Det nye kriteriet, 2.5.8 Target Size (Minimum) (nivå AA) innebærer at elementer som brukeren kan klikke på med musen eller berøringsskjermen, skal være minst 24x24 CSS-piksler (px). Dette er for å gjøre det enklere for brukere med redusert finmotorikk, men også for å forenkle bruken med berøringsskjerm, hvor presisjonen ikke er den samme som med en mus.

Kravet om størrelse betyr at en firkant med sider på 24 px må kunne plasseres innenfor elementet uten å gå utenfor elementets grenser. Elementet vist på bildet nedenfor oppfyller derfor ikke kravet, selv om det har et større overflateareal enn en slik firkant.

Det er fem unntak fra dette kriteriet:

• Hvis de klikkbare elementene er mindre enn 24x24 px, men er plassert slik at det er tilstrekkelig avstand mellom dem, slik at sirkler med en diameter på 24 px, som er sentrert på hvert element, ikke overlapper.
• Hvis samme funksjon kan utføres med en annen mekanisme på siden som oppfyller kravet.
• Hvis det klikkbare objektet er en del av løpende tekst eller på annen måte begrenses av linjehøyden. For eksempel lenker i brødtekst (men ikke i menyer).
• Hvis elementets visuelle utseende er kontrollert av nettleseren.
• Hvis spesifikk visuell utforming er nødvendig, eller hvis det er et juridisk krav, for den viste informasjonen.

Bildet nedenfor viser et eksempel med to runde knapper som har en diameter på 20 px - altså mindre enn minimumskravet. Hvis avstanden mellom knappene er minst 4 px, oppfyller de det første unntaket. Hvis de derimot ligger uten tilstrekkelig avstand, vil test-sirklene overlappes, og dermed vil ikke 2.5.8 kravet bli oppfylt.

Kravet i seg selv er bra. Å klikke med musen eller berøre svært små elementer er vanskelig for mange. 24 px kan likevel være litt i minste laget, spesielt på berøringsskjermer. Forklaringen med unntakene knyttet til sirkler som ikke overlapper, kan imidlertid virke noe komplisert, spesielt hvis elementene har uvanlige former.

Fokusmarkering (2.4.11, 2.4.12, 2.4.13)

En tydelig og synlig indikasjon på hvilket element på siden som har tastaturfokus er avgjørende for synshemmede brukere som ikke kan bruke musen, berøringsskjermen eller lignende metoder.

Selv om det allerede finnes retningslinjer som krever synlig fokusmarkering som oppfyller kontrastkrav mot bakgrunnen, innfører tre nye kriterier ytterligere krav for å tette hullene i de gamle kravene.

Ikke skjul elementer med fokus (2.4.11, 2.4.12)

De nye kriteriene 2.4.11 Focus Not Obscured (Minimum) (nivå AA) og 2.4.12 Focus Not Obscured (Enhanced) (nivå AAA) innebærer at elementer som mottar tastaturfokus, ikke kan være helt (2.4.11) eller delvis (2.4.12) skjult av annet innhold på siden.

Et vanlig problem disse kriteriene tar sikte på å løse, er for eksempel "falske modaler". Dette handler om dialogbokser, for eksempel informasjonskapselvarsler, som ser ut som modale dialogbokser, men egentlig ikke er det. Dette fører til at fokus kan flyttes ut av dialogboksen ved hjelp av tabulator-tasten. Slikte dialogbokser skjuler ofte elementer på den underliggende siden når de får tastaturfokus.

2.4.11 setter spørsmål ved hva som anses som helt skjult, og dette kan føre til diskusjoner. Kravet sier at elementet med fokus ikke skal være helt skjult. Men hvor går grensen for hvor mye som må være synlig? Det er ikke tydelig angitt. En tolkning er at brukeren må kunne gjenkjenne elementet. En annen tolkning er at det kan være tilstrekkelig hvis bare én enkelt piksel er synlig.

Forhåpentligvis vil dette få utviklere til å innse at det er brukere som navigerer med tastaturet også, og at noe som ser ut som en modal dialogboks også skal oppføre seg som en, uansett hvordan brukeren velger å navigere.

Minstestørrelse for fokusmarkering (2.4.13)

Det nye kriteriet 2.4.13 Focus Appearance (nivå AAA) stiller krav til størrelsen på fokusmarkeringen og hvordan den skal se ut.

Kravet sier at fokusmarkeringen må ha minst samme overflate som en 2 CSS-piksler (px) tykk omkrets rundt den ufokuserte komponenten. I tillegg må det være et kontrastforhold på minst 3:1 mellom hver piksel i det fokuserte og ufokuserte tilstanden.

Kravet om overflate gjelder altså selve fokusmarkeringens, ikke området rundt den. For eksempel, en 2 px tykt rektangel som måler 100x30 px, har en overflate på 520 px² (2x2x100 + 2x2x30 px). Dette er betydelig mindre enn området den omgir, som er 3000 px². Beregningen av overflaten for fokusmarkeringer med uvanlige former kan være utfordrende. For eksempel har en 2 px tykk sirkel med en diameter på 40 px en overflate på 251 px².

Bildet nedenfor viser to knapper med en fokusmarkering som er 2 px tykk. Den første knappen er plassert 2 px utenfor knappen og oppfyller derfor kravet til størrelse. Den andre knappen er plassert 2 px inne i knappen og oppfyller derfor ikke kravet om størrelse - den må være minst 3 px tykk for å oppfylle kravet.

Kravet om kontrast gjelder for hver piksel som inngår i fokusmarkeringen sammenlignet med samme piksel før markeringen vises - noe som ofte er bakgrunnsfargen rundt komponenten hvis fokusmarkeringen omgir komponenten, som den første knappen i bildet over. I den andre knappen er det kontrasten mellom fokusmarkeringen (rød) og knappens bakgrunnsfarge (lysegrå) som må være minst 3:1.

Unntak fra 2.4.13 inkluderer tilfeller der markeringen styres av nettleseren og ikke kan endres, eller der man bruker nettleserens fokusmarkering og ikke endrer bakgrunnsfargen som indikatoren vises mot. Å stole på nettleserens fokusmarkering er derfor bare tillatt hvis bakgrunnen ikke endres.

Dette kravet er svært viktig for alle som navigerer med tastaturet. Dessverre har det blitt nedgradert til nivå AAA i det siste forslaget, noe som sannsynligvis vil føre til at de fleste neglisjerer det, siden det ikke blir et lovpålagt krav. Dette blir heller ikke bedre av at reglene er så kompliserte at forklaringen fyller 16 A4-sider!

Autentisering (3.3.8, 3.3.9)

Autentisering innebærer til prosessen med å bekrefte ens identitet som den personen man hevder å være. Dette kan variere fra enkle brukernavn og passordfelt til mer avanserte trinn som tofaktorautentisering eller biometrisk gjenkjenning av fingeravtrykk, netthinne, ansikt eller stemme.

De nye kriteriene 3.3.8 Accessible Authentication (Minimum) (nivå AA) og 3.3.9 Accessible Authentication (Enhanced) (nivå AAA) krever at autentiseringstrinn ikke bør inneholde trinn som tester kognitive ferdigheter. Eksempler på slike tester inkluderer bruk av passord (kognitivt minne), løse matematiske problemer, svare på kunnskapsspørsmål eller løse CAPTCHA-utfordringer som innebærer å tolke forvrengt tekst (kognitive ferdigheter).

Begge kriteriene gir muligheter for unntak hvis det finnes alternative autentiseringsmetoder som ikke krever bruk av kognitive ferdigheter.

Et annet unntak gjelder hvis det finnes en måte å hjelpe brukere med å utføre kognitive oppgaver. Dette kan inkludere å tillate brukere å kopiere og lime inn passord fra en passordbehandlingstjeneste.

For 3.3.8 er det to ekstra unntak. Det første gjelder gjenkjenning av objekter, hvor brukeren må identifisere visse bilder eller figurer. Det andre unntaket gjelder situasjoner der brukeren må identifisere en bilde-, video- eller lydfil som de selv har lastet opp til tjenesten.

Separate autentiseringssystemer, som for eksempel e-legitimasjon (BankID og lignende), betraktes ikke som oppgaver som tester kognitive ferdigheter i henhold til disse kriteriene. Dette gjelder selv om slike løsninger kan inneholde elementer som krever brukerens kognitive ferdigheter.

CAPTCHA – funksjoner som skal forsøke å skille mellom mennesker og automatiserte roboter, har vist seg å være problematiske. Dette systemet legger ofte byrden på brukerne for å løse nettstedets sikkerhetsutfordringer, og de fleste CAPTCHA-løsninger har mangler når det gjelder universell utforming. Kravet om å tilby alternative løsninger for slike utfordringer er positivt, men unntaket knyttet til gjenkjenning av objekter i kriterium 3.3.8 kan potensielt svekke dette kravets effektivitet. Det ser ut til at dette unntaket er lagt inn for å tillate bruk av Googles reCAPTCHA, som er i bruk på mange nettsteder, til tross for at det skaper problemer for mange brukere. Kriterium 3.3.9 har ikke dette unntaket, men det er på nivå AAA, som vanligvis ikke er lovpålagt. Dette kan bety at kravet ikke vil være bindende for de fleste tilfeller før det blir en standard praksis.

Når blir disse kravene lovpålagte?

Uutilsynet bemerker at implementeringen og omfanget av de nye kravene vil avhenge av EU sin beslutning om å inkludere WCAG 2.2 i revisjonen av EN 301 549, som er den harmoniserte standarden for EUs webdirektiv (WAD).

Dersom det blir nødvendig å oppdatere forskriftene i henhold til disse endringene, vil det gjennomføres gjennom en nasjonal reguleringsprosess, som vanligvis tar noen år.

WCAG 2.2 – les mer på W3Cs nettisde (på engelsk).