WCAG 2.2

Forslag om nye suksesskriterier.

Hentet fra W3C

WCAG (Web Content Accessibility Guidelines) er en standard som skal hjelpe til med å sikre at mennesker med ulike forutsetninger og behov kan bruke apper og nettsider. Versjon 1 av standarden kom i 1999, versjon 2 kom i 2008 og deretter versjon 2.1. WCAG 2.0 er lovpålagt i Norge, og alt tyder på at WCAG 2.1 snart overtar. Suksesskriteriene i WCAG er det som testes. Suksesskriteriene i WCAG 2.0 er identiske med de du finner i WCAG 2.1, men i WCAG 2.1 er det flere suksesskriterier.

WCAG 2.2 er foreløpig ikke en vedtatt standard. Også i denne versjonen er det kun snakk om tillegg (bortsett fra at suksesskriterie 2.4.7 er flyttet fra nivå AA til A). Det er en endring jeg er enig i.

Her er litt om de nye suksesskriteriene, men vær klar over at jeg ikke har lagt mye jobb i oversettelse. Jeg har brukt Google translate, og når disse suksesskriteriene eventuelt blir godkjente kommer det sannsynligvis en offisiell oversettelse med mye høyere kvalitet.

2.4.11 Focus Appearance (Minimum) (AA)

Har du noen gang prøvd å bruke en nettside med kun tastatur? Da vet du at visuelt tastaturfokus er viktig: altså at du hele tiden vet hva som er aktivt (feks. når du trykker Tab). Etter min mening er det på høy tid at WCAG forbedres mht. akkurat dette og her er forslaget.

Følgende gjelder for det visuelle tastaturfokuset for hvert element i brukergrensesnittet:

• Minimumsareal: Fokusindikasjonsområdet er større enn eller lik 1 CSS-pikselramme for den fokuserte kontrollen, eller har en tykkelse på minst 8 CSS-piksler langs den korteste siden av elementet.
• Endring av kontrast: Fargeendringen for fokusindikasjonsområdet har et kontrastforhold på minst 3: 1 med fargene i den ufokuserte tilstanden.
• Tilstøtende kontrast: Fokusindikasjonsområdet har et kontrastforhold på minst 3: 1 mot alle tilstøtende farger for minimumsarealet eller større, eller har en tykkelse på minst 2 CSS-piksler.
• Uhindret: Elementet med fokus er ikke helt skjult av innhold laget av forfatteren.

En indikator for tastaturfokus som har et mønster eller en gradient, kan ha deler som ikke oppfyller 3: 1 kontrastforhold for endring av kontrast, så lenge et område lik minimum oppfyller kontrastforholdet.
Hvis kontrollen har en synlig grense som er mindre enn treffområdet, blir størrelsesmålet tatt fra den synlige grensen.

2.4.12 Focus Appearance (Enhanced) (AAA)

For mange viktige WCAG-suksesskriterier finnes det to versjoner. Det strengeste kravet finner vi da oftest på nivå AAA som ikke er lovpålagt. Det betyr ikke at kravet er uvesentlig, og alle som vil kan velge å følge de strengeste kravene (eller noen av de strengeste kravene).

For indikatoren for tastaturfokus for hver brukergrensesnittkomponent, gjelder alt:

• Minimumsareal: Fokusindikasjonsområdet er større enn eller lik en 2 CSS-piksler med solid kant rundt kontrollen.
• Endring av kontrast: Fargeendringer som brukes for å indikere fokus, har et kontrastforhold på minst 4,5: 1 med fargene endret fra den ufokuserte kontrollen.
• Ubeskyttet: Ingen del av fokusindikatoren er skjult av innhold som er laget av forfatteren.

2.4.13 Fixed Reference Points (A)

WCAG har i liten grad omtalt innhold som går over flere nettsider (bortsett fra skjemaer/prosesser som skal vurderes i sin helhet). Publikasjoner og navigering i publikasjoner er en utfordring for mange, og selv om dette suksesskriteriet ikke løser alle disse utfordringene er effektiv og konsistent navigering viktig.

Når en webside eller et sett med websider er en elektronisk publikasjon med sideskift, er det en mekanisme tilgjengelig for å navigere til hver lokaliseringsenhet, og hver locator opprettholder sin plass i flyten av innhold, selv når formateringen eller plattformen endres.

2.5.7 Dragging (AA)

Dette kravet bør nok presiseres bedre, men det gis et eksempel. I en liste der du kan dra elementer kan det også lages en funksjon der du kan klikke på et element og så få piler for å flytte opp/ned.

All funksjonalitet som bruker en drabevegelse for operasjon, kan betjenes av en enkelt peker uten å dra, med mindre det er viktig å dra.

Dette kravet gjelder nettinnhold som tolker pekerhandlinger (dvs. dette gjelder ikke handlinger som kreves for å betjene brukeragenten eller hjelpeteknologien).

2.5.8 Pointer Target Spacing (AA)

Det er vrient med kontroller som er alt for små, enten du bruker pekeskjerm eller for eksempel hvis du skjelver på hendene. Det har eksistert krav til størrelse på interaktive elementer også tidligere (2.5.5 Target size, nivå AAA), men her altså forslag til et obligatorisk krav.

For hvert mål er det et område med en bredde og høyde på minst 44 CSS-piksler som inkluderer det, og ingen andre mål, bortsett fra når:

• Forstørr: En mekanisme er tilgjengelig for å endre CSS-pikselstørrelsen til hvert mål, eller dets avstand, så det er et område med en bredde og høyde på minst 44 CSS-piksler som inkluderer det, og ingen andre mål;
• Inline: Målet er i en setning eller tekstblokk;
• Brukeragent: Målets størrelse kontrolleres av brukeragenten og endres ikke av forfatteren;
• Viktig: En bestemt presentasjon av målet er viktig for informasjonen som formidles.

3.2.6 Findable Help (A)

Det er på høy tid at flere kognitive krav tas med i WCAG. Det er imidlertid veldig utfordrende fordi forutsetninger og behov er så ulike hos oss mennesker. En relativt opplagt vei å gå er å innføre krav til hjelp (i tillegg til kriteriene som alt finnes på nivå AAA). Men, om det er testbart at eventuell hjelp er til hjelp for de som trenger det er utfordrende. Tipper Wave får litt utfordringer med denne.

For enkeltsideprogrammer eller ethvert sett med websider, hvis ett av følgende er tilgjengelig, er tilgang til minst ett alternativ inkludert i samme relative rekkefølge på hver side:

• Menneskelige kontaktdetaljer
• Menneskelig kontaktmekanisme
• Selvhjelp alternativ
• En helautomatisk kontaktmekanisme

Tilgang til hjelpemekanismer kan gis direkte på siden, eller kan gis via en direkte lenke til en annen side som inneholder informasjonen.

3.2.7 Hidden Controls (AA)

De som kjenner meg vet at jeg har en del kjepphester, hehe. En av de tingene jeg misliker mest er skjult funksjonalitet (for eksempel Hopp til lenker som vises når de får tastaturfokus). Min mening er at kontroller som kan brukes skal vises, og jeg synes derfor dette WCAG-kravet er supert.

Kontrollene som trengs for å komme videre eller fullføre en prosess, er synlige på det tidspunktet de trengs uten at du peker på bestemte steder eller tastaturfokuset kreves, eller en mekanisme er tilgjengelig for å gjøre dem vedvarende synlige.

3.3.7 Accessible Authentication (A)

Kognitive funksjonstester er ikke særlig vanlige på de nettstedene jeg bruker, så kanskje noe jeg har gått glipp av. Jeg har riktignok sett slike tester (matteoppgaver etc), men her er jeg veldig usikker på hva som regnes som en kognitiv funksjonstest: captcha? Eksemplet som gis er heller ikke til stor hjelp synes jeg. En som ikke skjønner hvilke tegn som skal inn får et alternativ ved å skrive inn epost-adressen, får så en epost og kan velge en lenke i eposten. Ttror det bør noe mer kjøtt på beinet her for det er helt garantert reelle behov som ligger bak forslaget til suksesskriterie.
Vegard Haugstvedt tipset meg om at det også kunne være brukernavn/passord. Det var tema i forbindelse med utforming av WCAG 2.1. Passord er ganske vrient, så Haugstvedt har nok rett! Heldigvis begynner det å komme på plass ganske gode passordløsninger både fra Apple og andre, men en mekanisme for innlogging uten passord er selvsagt bra. Dette og mange andre suksesskriterier kunne med fordel ha vært skrevet noe mer “rett på beinet”. Skjønner at de ønsker å dekke ulike alternativer, men det er jammen viktig at WCAG er kognitivt forståelig når det kreves at alt nettinnhold skal være det (WCAG ligger på web, hehe).

Hvis en autentiseringsprosess er avhengig av en kognitiv funksjonstest, må minst en annen metode også være tilgjengelig som ikke er avhengig av en kognitiv funksjonstest.

3.3.8 Redundant Entry (A)

Et krav alle nok gir tommelen opp for! Viktig for noen og bra for alle.

For trinn i en prosess er informasjonen som tidligere er angitt av eller gitt til brukeren og som kreves i påfølgende trinn, enten:

• automatisk lagt inn, eller

tilgjengelig for brukeren å velge.

Unntak: Det er viktig å legge inn informasjonen på nytt.
Sikkerhetsverifisering, for eksempel å gjenta et passord, anses å være viktig.

Relaterte saker