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 W3Cs foreslåtte anbefaling stadium. Et forslag til anbefaling betyr at W3C har akseptert det, 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, 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 vil være suksesskriterier (SC) på nivå AAA.
De fleste organisasjoner tar sikte på å oppfylle WCAG på nivå AA, noe som betyr at de vil legge til seks nye kriterier på listen. Ettersom de nye suksesskriteriene vil være tillegg til de eksisterende retningslinjene, vil de beholde den eksisterende bakoverkompatibiliteten og den samme samsvarsmodellen.
I likhet med kriteriene som ble lagt til i 2.1, tar disse sikte på å hjelpe brukere med nedsatt syn, kognitive funksjonshemninger, lærevansker og motoriske funksjonshemninger, med fordeler for brukere med funksjonshemninger på mobile enheter.
Nye suksesskriterier
La oss se nærmere på hver av disse nye SC-ene, hva de heter, hvilke nivåer de befinner seg på og hvordan de påvirker sluttbrukerne.
Retningslinje 2.4 Navigerbar
Under retningslinje 2.4 Navigable ligger tre av de nye SC. Her finner vi 2.4.11 Focus Not Obscured (Minimum), et kriterium på nivå AA. For personer som bruker tastatur eller en tastaturlignende enhet, er det viktig å vite hvor fokuset er. 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 klebrige bunntekster eller topptekster. Når en bruker blar gjennom siden, skjuler for eksempel en klebrig bunntekst deler av det fokuserte elementet.
2.4.12 Focus Not Obscured (Enhanced) er nivå AAA-versjonen av den forrige og sier ganske enkelt at det fokuserte elementet ikke overlappes av annet innhold i det hele tatt når du tabber nedover på siden.
Den andre SC-en som ligger under Navigable Guideline, er 2.4.13 Focus Appearance. Det har vært mye snakk om denne, og den har blitt endret et par ganger i løpet av utkastfasen, men arbeidsgruppen mener at de har funnet den rette balansen nå.
Debatten, og ikke minst inkonsekvensen i hvordan synlig fokus for tastaturfokusindikatorer avgjøres som tilgjengelig eller ikke, har pågått så lenge jeg har vært i bransjen (10 år). Selv om denne nye standarden er på nivå AAA, setter den endelig punktum for debatten, og ærlig talt er det et svært velkomment tillegg!
Det viktigste med dette suksesskriteriet er at det tas hensyn til fargekontrastforholdet. Når du angir fokus, må du ha et kontrastforhold på minst 3:1 og en omkrets på minst 2 CSS-piksler. Dette vil bidra til at tastaturbrukere enkelt kan se hvilket interaktivt element som har fokus.
Retningslinje 2.5 Inndatamodaliteter
Input Modalities har fått to nye SC med Dragging Movements og en nivå AA-versjon av Target Size.
2.5.7 Drabevegelser er knyttet til et AA-kriterium som skal sikre at drabevegelser kan utføres med en enkelt peker uten å dra, med mindre det er helt nødvendig. Det ligner på pekerbevegelser som snakker om retningsbaserte 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 er i stand til å dra i det hele tatt eller nøyaktig.
2.5.8 Målstørrelse (minimum) er et annet kriterium på AA-nivå. Her er hensikten å sikre at mål som knapper eller koblede ikoner enkelt kan aktiveres uten at et mål i nærheten aktiveres ved et uhell. 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ålene er minst 24 x 24 CSS-piksler. Dette kan inkludere mellomrom rundt målet.
Retningslinje 3.2 Forutsigbar
En SC er lagt til i retningslinjene for forutsigbar hjelp i 3.2.6 Konsistent hjelp, som sier at hvis det finnes hjelpealternativer, for eksempel chat, kontaktinformasjon for en person eller et selvhjelpsalternativ, for et sett med sider, skal minst ett alternativ være tilgjengelig i samme relative rekkefølge på hver side i settet.
Det betyr at hvis du har et chat-alternativ, bør det være lett å finne på samme sted på alle sider på reisen, for eksempel festet nederst i høyre hjørne, slik at det er lett å finne hjelpemulighetene. Dette er et krav på nivå A.
Retningslinje 3.3 Hjelp til innspill
Input Assistance har fått noen gode tilføyelser. Her finner vi et betydelig fokus på å vurdere kognitiv belastning i forbindelse med utfylling av skjemaer og autentisering.
La oss begynne med 3.3.7 Overflødige opplysninger, som er et kriterium på nivå A. Når du fyller ut et skjema der det etterspørres data som allerede er lagt inn tidligere i skjemaet, må gjentatte data være tilgjengelige via automatisk utfylling eller kunne velges. Dette reduserer den kognitive innsatsen når informasjon etterspørres mer enn én gang i løpet av en prosess. Det reduserer også behovet for å huske informasjon som er oppgitt i et tidligere trinn. Det finnes unntak for bekreftelse av passord og skjemaer som forlates.
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! Du kan fortsatt bruke brukernavn (eller e-post) og passord som autentiseringsmetode så lenge nettlesere og passordadministratorer ikke er blokkert og kan brukes til å fylle ut feltene automatisk, eller du tillater kopiering og liming for å redusere den kognitive belastningen ved å skrive inn på nytt.
3.3.9 Tilgjengelig autentisering (utvidet) 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 besluttet 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 bli fanget opp i 4.1.1, ellers ville/burde bli fanget opp av andre suksesskriterier som 1.3.1 Info and Relationship eller 4.1.2 Name Role Value. De andre parsing-problemene som ofte oppstår, skaper ikke lenger tilgjengelighetsfeil basert på hvordan dagens nettlesere og hjelpemiddelteknologier gjengir koden.
Det er verdt å påpeke at parsing faller inn under robust-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.
Det er flere ting å snakke om i denne saken, og den har ført til en del heftige (ordspill tilsiktet) samtaler. Her er 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 god bruk av noens tid?
- WCAG 2.2 er ment å være bakoverkompatibel, men det er fortsatt mange uklarheter knyttet til hvordan det vil fungere for WCAG 2.1 og 2.0 og utdaterte standarder som brukes av lover og styrende organer internasjonalt. Dette er ikke et uløselig problem, men det krever mer ettertanke og diskusjon. Arbeidsgruppen er allerede i gang med å vurdere dette, men det er verdt å nevne inntil en løsning er funnet.
- Jeg har alltid brukt analogien om at vi ikke skaper ny teknologi, hjelpemidler eller annet, basert på elendig kode (eller alfabetsuppe, som jeg liker å kalle det), så ved å fjerne parsing, senker vi HTML-standarden?
- Gjør vi antagelser om hvor mange hjelpemiddelbrukere som holder nettlesere og hjelpemidler oppdatert? Er dette et eksempel på at vi fokuserer for mye på nordamerikansk eller europeisk statistikk om bruk av hjelpemidler?
Støttedokumenter
Arbeidsgruppen fortsetter arbeidet med å utvikle teknikker som dokumenterer tilstrekkelige eksempler og eksempler på feil for WCAG 2-serien av retningslinjer, med hovedvekt på å utvikle teknikker for de nye kriteriene i WCAG 2.2. Ytterligere støttedokumenter, blant annet How to Meet WCAG 2.2 og Forståelse av WCAG 2.2er tilgjengelig for gjennomgang nå.
Fremtidige versjoner
Endelig 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, for eksempel WCAG 3.0 eller Silver, som den fortsatt kalles i enkelte kretser. 3.0 vil være en betydelig revisjon av WCAG-retningslinjene og vil ikke være bakoverkompatibel. Dette er imidlertid fortsatt mange år unna, noe som gjør det svært viktig at alle forstår 2.2 nå og i den nærmeste og mellomlange fremtiden.
