Det har tatt lang tid, men nå er versjon 2.2 av Web Content Accessibility Guidelines (WCAG) snart her! Nei, denne gangen mener vi det virkelig. Den 20. juli WCAG 2.2 flyttet til Foreslått anbefaling fra W3C stadium. En foreslått anbefaling betyr at W3C har akseptert den, og W3C-medlemmene vil nå stemme over publisering av dokumentet som en W3Cs anbefaling. Selv om avstemningen avsluttes 19. august 2023, og håpet er at den vil være klar til publisering kort tid etter det, er det viktig å merke seg at W3C-medlemmenes innspill under avstemningsprosessen kan kreve mer arbeid. Planen er imidlertid at vi skal ha en ny oppdatering av WCAG innen utgangen av august.
Hva er endringene?
WCAG 2.2 bygger på WCAG 2.1, på samme måte som WCAG 2.1 bygger på 2.0, og utvider WCAG 2.x-serien av retningslinjer. Den inneholder alle WCAG 2.1-kriteriene, minus 4.1.1 Parsing (mer om dette senere), pluss ni nye kriterier. Av disse er to på nivå A, fire på nivå AA og tre på nivå AAA suksesskriterier (SC).
De fleste organisasjoner har som mål å oppfylle WCAG til nivå AA, noe som betyr at de vil legge til seks nye kriterier på listen sin. Ettersom de nye suksesskriteriene vil være tillegg til de eksisterende retningslinjene, vil de beholde eksisterende bakoverkompatibilitet og den samme samsvarsmodellen.
I likhet med de nye kriteriene i 2.1 vil disse ha som mål å hjelpe brukere med nedsatt syn, kognitive og kognitive lærevansker og brukere med motoriske funksjonsnedsettelser, med fordeler for brukere som har funksjonsnedsettelser på mobile enheter.
Nye suksesskriterier
La oss se nærmere på hva hver av disse nye SC-ene innebærer, hva de heter, hvilke nivåer de ligger på og hvilke konsekvenser de har for sluttbrukerne.
Retningslinje 2.4 Farbar
Under retningslinje 2.4 Navigerbar ligger tre av de nye SC. Her finner vi 2.4.11 Fokus ikke tildekket (minimum), et kriterium på nivå AA. For personer som bruker tastatur eller tastaturlignende enheter, er det viktig å vite hvor fokuset ligger. Dette nye kriteriet sier at hvis annet innhold overlapper med et fokusert element, kan ikke det fokuserte elementet skjules.
Typiske typer innhold som kan overlappe fokuserte elementer og forårsake et tilgjengelighetsproblem, er klissete bunntekster eller overskrifter. Når en bruker blar gjennom siden, skjuler for eksempel en klistret bunntekst deler av det fokuserte elementet.
2.4.12 Fokus ikke tildekket (Forbedret) er nivå AAA-versjonen av den forrige og sier ganske enkelt at når du tabber nedover på siden, skal det fokuserte elementet ikke overlappes av annet innhold i det hele tatt.
Den andre SC-en som ligger under Navigable Guideline, er 2.4.13 Focus Appearance. Det har vært mye diskusjon om denne, og den har blitt endret et par ganger i løpet av utkastfasen, men arbeidsgruppen mener at de nå har funnet den rette balansen.
Debatten og inkonsekvensen rundt hvordan synlig fokus for tastaturfokusindikatorer bestemmes som tilgjengelige eller ikke, har pågått så lenge jeg har vært i bransjen (som er 10 år). Selv om det er på nivå AAA, setter denne nye SC endelig en stopper for debatten, og det er ærlig talt et svært velkomment tillegg!
Viktigst av alt er at dette suksesskriteriet vil ta hensyn til fargekontrastforhold. Når du angir fokus, må du ha et kontrastforhold på minst 3:1 og en omkrets på minst 2 CSS-piksler. Dette bidrar til å sikre at tastaturbrukere enkelt kan se hvilket interaktivt element som har fokus.
Retningslinje 2.5 Inndatamodaliteter
Inndatamodaliteter har fått to nye SC med Drabevegelser og en nivå AA-versjon av Målstørrelse.
2.5.7 Drabevegelser er fastsatt til å være et AA-kriterium på nivå AA, som skal sikre at drabevegelser kan betjenes med en enkelt peker uten å dra, selvfølgelig med mindre det er helt nødvendig å dra. Det ligner på pekerbevegelser, der det er snakk om retningsbestemte banebaserte bevegelser og flerpunktsbevegelser. Forskjellen her er definisjonen av hva som er en drabevegelse. Når du drar, er det bare start- og sluttpunktet for bevegelsen som betyr noe, ikke banen. Konseptet er imidlertid det samme, og dette er en god forsikring om at det finnes alternativer for brukere som ikke kan dra i det hele tatt, eller som ikke kan dra nøyaktig.
2.5.8 Målstørrelse (minimum) er et annet kriterium på AA-nivå. Her er hensikten å sørge for at mål som knapper eller koblede ikoner enkelt kan aktiveres uten at man ved et uhell aktiverer et nærliggende mål. Ved å sørge for tilstrekkelig størrelse og/eller avstand mellom målene reduseres sannsynligheten for at feil kontroll aktiveres ved et uhell. Kravet her er at målstørrelsen skal være minst 24 x 24 CSS-piksler. Dette kan inkludere hvit plass rundt målet.
Retningslinje 3.2 Forutsigbar
En SC er lagt til i retningslinjen om forutsigbarhet i 3.2.6 Konsistent hjelp, som sier at hvis det finnes tilgjengelige hjelpealternativer, for eksempel chat, kontaktinformasjon for en person eller et selvhjelpsalternativ, for et sett med sider, skal tilgang til minst ett alternativ inkluderes i samme relative rekkefølge på hver side i dette settet.
Det betyr at hvis du har et chat-alternativ, bør det være lett å finne på samme sted på hver side i reisen, for eksempel nederst i høyre hjørne, slik at det er lett å finne hjelpealternativene. Dette vil være et nivå A-krav.
Retningslinje 3.3 Bistand til innspill
Det er noen flotte tilføyelser til Input Assistance. Her er det et betydelig fokus på å ta hensyn til kognitiv belastning i forbindelse med utfylling av skjemaer og autentisering.
La oss begynne med 3.3.7 Overflødig inntasting, som er planlagt å være et nivå A-kriterium. Når du fyller ut et skjema der du blir bedt om å oppgi data som allerede er skrevet inn tidligere i skjemaet, må gjentatte data være tilgjengelige gjennom autoutfylling eller kunne velges. Dette reduserer den kognitive innsatsen når det blir bedt om informasjon mer enn én gang i løpet av en prosess. Det reduserer også behovet for å huske informasjon som er gitt i et tidligere trinn. Det finnes unntak for bekreftelse av passord og forlatte skjemaer.
3.3.8 Tilgjengelig autentisering (minimum), et kriterium på nivå AA, sier at det ikke skal være nødvendig med en kognitiv test i en autentiseringsprosess. Gode nyheter for biometri! Ikke få panikk; du kan fortsatt bruke brukernavn (eller e-post) og passord som autentiseringsmetode så lenge nettlesere og passordbehandlere ikke er blokkert og kan brukes til å fylle ut feltene automatisk, eller du tillater kopiering og liming for å redusere den kognitive byrden ved å skrive inn på nytt.
3.3.9 Accessible Authentication (Enhanced) er nivå AAA er det samme som minimumsversjonen ovenfor, men uten unntak for objektgjenkjenning og brukertilpasset innhold. Igjen er hensikten å sikre at det finnes en tilgjengelig, brukervennlig og sikker metode for innlogging, tilgang til innhold osv.
Hva med parsing?
For første gang i WCAG 2-serien har arbeidsgruppen bestemt at en SC er foreldet og fjernet 4.1.1 Parsing. Det er flere faktorer som ligger til grunn for denne beslutningen.
Arbeidsgruppen har konkludert med at eventuelle reelle problemer som påvirker brukere med nedsatt funksjonsevne, og som ville blitt fanget opp i 4.1.1, ville/burde blitt fanget opp av andre suksesskriterier som 1.3.1 Info og relasjon eller 4.1.2 Navn, rolle og verdi. De andre parsingproblemene som ofte oppstår, skaper ikke lenger tilgjengelighetsfeil basert på hvordan dagens nettlesere og hjelpeteknologier gjengir koden.
Det er verdt å påpeke at parsing faller inn under det robuste prinsippet i WCAG. Robust fokuserer på å sikre at nettinnholdet er kompatibelt med ulike teknologier og hjelpemidler. Dette innebærer bruk av koding og nettutviklingspraksis som støtter tilgjengelighetsfunksjoner og kan brukes av en rekke ulike brukeragenter.
Nå er det et par samtaleemner for denne, og det har forårsaket noen robuste (pun intended) samtaler. Et par av mine tanker om dette:
- Manglende parsing hindrer organisasjoner i å kreve samsvar, men hvis det ikke har noen innvirkning i den virkelige verden - er det da en god bruk av noens tid?
- WCAG 2.2 er ment å være bakoverkompatibel, men det er fortsatt en del uklarheter rundt hvordan den skal fungere for WCAG 2.1 og 2.0 og eldre standarder som brukes av lovgivende og styrende organer internasjonalt. Dette er ikke uløselig, men det krever litt mer ettertanke og diskusjon. Arbeidsgruppen vurderer allerede dette, men det er verdt å nevne det inntil en løsning er funnet.
- Jeg har alltid brukt analogien om at vi ikke lager ny teknologi, verken hjelpemidler eller annet, basert på elendig kode (eller alfabetsuppe, som jeg liker å kalle det), så ved å droppe parsing, senker vi HTML-standarden i det hele tatt?
- Gjør vi antagelser om hvor mange hjelpemiddelbrukere som holder nettlesere og hjelpemidlene sine oppdaterte og aktuelle? Er dette et eksempel på at vi fokuserer for mye på nordamerikansk eller europeisk statistikk om bruk av hjelpemidler?
Støttende dokumenter
Arbeidsgruppen fortsetter å utvikle teknikker som dokumenterer tilstrekkelige og feilaktige eksempler for WCAG 2-serien med retningslinjer, med hovedvekt på å utvikle teknikker for de nye kriteriene i WCAG 2.2. Ytterligere støttedokumenter, inkludert How to Meet WCAG 2.2 og Forståelse av WCAG 2.2, er tilgjengelig for gjennomgang nå.
Fremtidige versjoner
Til slutt er det lite sannsynlig at det kommer en WCAG 2.3, men som jeg lærte for lenge siden, skal man aldri si aldri. Etter utgivelsen av versjon 2.2 forventes det at mesteparten av arbeidsgruppens arbeid vil bli lagt ned i en fremtidig versjon av retningslinjene for universell utforming, som WCAG 3.0, eller Silver, som den fortsatt kalles i enkelte tilgjengelighetskretser. 3.0 vil være en betydelig revisjon av WCAG-retningslinjene og vil ikke være bakoverkompatibel. Dette ligger imidlertid fortsatt mange år frem i tid, noe som gjør at alles forståelse av 2.2 har høy prioritet nå og i nær og mellomlang fremtid.
