Det har været længe undervejs, men Web Content Accessibility Guidelines (WCAG) version 2.2 er her næsten! Nej, vi mener det virkelig denne gang. Den 20. juli, WCAG 2.2 flyttet til W3C's foreslåede anbefaling fase. En foreslået anbefaling betyder, at W3C har accepteret den, og W3C-medlemmerne vil nu stemme om at udgive dokumentet som en W3C anbefaling. Selvom afstemningen slutter den 19. august 2023, og håbet er, at den vil være klar til offentliggørelse kort tid efter, er det vigtigt at bemærke, at W3C-medlemmernes input under afstemningsprocessen kan kræve mere arbejde. Planen er dog, at vi i slutningen af august vil have en ny opdatering af WCAG.
Hvad er ændringerne?
WCAG 2.2 bygger på WCAG 2.1, ligesom WCAG 2.1 byggede på 2.0 og udvider WCAG 2.x-serien af retningslinjer. Den indeholder alle WCAG 2.1, minus 4.1.1 Parsing (mere om dette senere), plus ni nye kriterier. Af dem er to niveau A, fire er niveau AA, og tre vil være niveau AAA succeskriterier (SC).
De fleste organisationer sigter mod at opfylde WCAG til niveau AA, hvilket betyder, at de vil tilføje seks nye kriterier til deres liste. Da de nye succeskriterier vil være tilføjelser til de eksisterende retningslinjer, vil de bevare den eksisterende bagudkompatibilitet og den samme overensstemmelsesmodel.
Ligesom de tilføjede 2.1-kriterier vil disse have til formål at hjælpe brugere med nedsat syn, kognitive og indlæringsmæssige handicap, og dem med motoriske handicap med fordele for brugere, der har handicap på mobile enheder.
Nye succeskriterier
Lad os se nærmere på hver af disse nye SC'er, deres navne, niveauer og konsekvenserne for slutbrugerne.
Retningslinje 2.4 Sejlbar
Under Guideline 2.4 Navigable ligger tre af de nye SC. Her finder vi 2.4.11 Focus Not Obscured (Minimum), et niveau AA-kriterium. For folk, der er afhængige af et tastatur eller en tastaturlignende enhed, er det vigtigt at kende det aktuelle fokuspunkt. Dette nye kriterium siger, at hvis andet indhold overlapper med et fokuseret element, må det fokuserede element ikke skjules.
Typiske typer indhold, der kan overlappe fokuserede elementer og forårsage et tilgængelighedsproblem, er sticky footers eller headers. Når en bruger tabber sig gennem siden, skjuler f.eks. en sticky footer dele af det fokuserede element.
2.4.12 Focus Not Obscured (Enhanced) er niveau AAA-versionen af den forrige og siger simpelthen, at når man tabber ned ad siden, overlappes det fokuserede element slet ikke af andet indhold.
Den anden SC, der ligger under Navigable Guideline, er 2.4.13 Focus Appearance. Der har været meget snak om denne, og den er blevet ændret et par gange i løbet af udkastfasen, men arbejdsgruppen mener, at de har fundet den rette balance nu.
Debatten og den manglende konsekvens i, hvordan synligt fokus for tastaturets fokusindikatorer bestemmes som tilgængeligt eller ej, har stået på i, ja, ærligt talt, lige så lang tid, som jeg har været i branchen (hvilket er 10 år). Selvom det er et niveau AAA, afslutter denne nye SC endelig enhver debat, og ærligt talt er det en meget velkommen tilføjelse!
Vigtigst af alt vil dette succeskriterium have farvekontrastforhold taget i betragtning. Når du angiver fokus, skal du have et kontrastforhold på mindst 3:1 og en omkreds på mindst 2 CSS-pixel. Det er med til at sikre, at tastaturbrugere nemt kan se, hvilket interaktivt element der har fokus.
Retningslinje 2.5 Input-modaliteter
Input Modalities har fået tilføjet to nye SC med Dragging Movements og en Level AA-version af Target Size.
2.5.7 Trækbevægelser er et niveau AA-kriterium, som skal sikre, at trækbevægelser kan udføres med en enkelt markør uden at trække, medmindre det er nødvendigt at trække. Det svarer til pointerbevægelser, hvor man taler om retningsbaserede bevægelser og bevægelser med flere punkter. Forskellen her er definitionen af, hvad der er en dragging-bevægelse. Med dragging er det kun bevægelsens start- og slutpunkt, der betyder noget, ikke stien. Konceptet er dog det samme, og det er en god forsikring om, at der er alternativer til rådighed for brugere, der ikke kan trække overhovedet eller præcist.
2.5.8 Målstørrelse (minimum) er et andet kriterium på AA-niveau. Her er hensigten at sikre, at mål som knapper eller linkede ikoner nemt kan aktiveres uden ved et uheld at aktivere et mål i nærheden. Hvis der er tilstrækkelig størrelse og/eller afstand mellem målene, reduceres sandsynligheden for, at man ved et uheld aktiverer den forkerte kontrol. Kravet her er, at målstørrelserne er mindst 24 x 24 CSS-pixels. Dette kan inkludere hvid plads omkring målet.
Retningslinje 3.2 Forudsigelig
En SC er tilføjet til Predictable Guideline i 3.2.6 Consistent Help, som siger, at hvis der er hjælpemuligheder, f.eks. chat, kontaktoplysninger for en person eller en selvhjælpsmulighed, for et sæt af sider, så skal der være adgang til mindst én mulighed i samme relative rækkefølge på hver side i det sæt.
Det betyder, at hvis du har en chatmulighed, skal den være let at finde det samme sted på hver side i rejsen, f.eks. fastgjort i nederste højre hjørne, så hjælpemulighederne er lette at finde. Dette vil være et niveau A-krav.
Retningslinje 3.3 Hjælp til input
Der er et par gode tilføjelser til Input Assistance. Her finder vi et betydeligt fokus på at overveje kognitiv belastning i forhold til udfyldelse af formularer og autentificering.
Lad os starte med 3.3.7 Redundant Entry, som er et niveau A-kriterium. Når man udfylder en formular, hvor der anmodes om data, som allerede er indtastet tidligere i formularen, skal gentagne data være tilgængelige via autofyld eller kunne vælges. Det reducerer den kognitive indsats, når der bliver bedt om oplysninger mere end én gang i løbet af en proces. Det reducerer også behovet for at huske oplysninger, der er givet i et tidligere trin. Der er undtagelser her for bekræftelse af adgangskoder og forladte formularer.
3.3.8 Accessible Authentication (Minimum), et niveau AA-kriterium, siger, at en kognitiv test ikke bør være påkrævet i en autentificeringsproces. Gode nyheder for biometri! Gå ikke i panik; du kan stadig bruge brugernavn (eller e-mail) og adgangskode som autentificeringsmetode, så længe browsere og adgangskodeadministratorer ikke er blokeret og kan bruges til at udfylde felterne automatisk, eller du tillader kopiering og indsætning for at reducere den kognitive byrde ved at skrive igen.
3.3.9 Accessible Authentication (Enhanced) er niveau AAA er det samme som ovenstående Minimum-version, men uden undtagelser for objektgenkendelse og brugerleveret indhold. Så igen er det meningen at sikre, at der er en tilgængelig, brugervenlig og sikker metode til at logge ind, få adgang til indhold osv.
Hvad med parsing?
For første gang i WCAG 2-serien har arbejdsgruppen besluttet, at en SC er forældet og fjernet 4.1.1 Parsing. Der er et par faktorer, der er taget i betragtning omkring denne beslutning.
Arbejdsgruppen har konkluderet, at alle reelle problemer, der påvirker brugere med handicap, og som ville blive fanget i 4.1.1, ville/burde blive fanget af andre succeskriterier som 1.3.1 Info and Relationship eller 4.1.2 Name Role Value. Det blev vurderet, at de andre parsing-problemer, der ofte opstår, ikke længere skaber tilgængelighedsfejl baseret på, hvordan nutidens browsere og hjælpeteknologier gengiver koden.
Det er værd at påpege, at parsing falder ind under det robuste princip i WCAG. Robust fokuserer på at sikre, at webindholdet er kompatibelt med forskellige teknologier og hjælpemidler. Det indebærer brug af kodning og webudviklingspraksis, der understøtter tilgængelighedsfunktioner og kan bruges af en række forskellige brugeragenter.
Nu er der et par punkter, man kan tale om, og det har givet anledning til nogle robuste (pun intended) samtaler. Et par af mine tanker om dette:
- Manglende parsing afholder organisationer fra at kræve overensstemmelse; men hvis det ikke har nogen indvirkning på den virkelige verden - er det så en god måde at bruge nogens tid på?
- Det er meningen, at WCAG 2.2 skal være bagudkompatibel, men der er stadig en masse gråzoner omkring, hvordan det vil fungere for WCAG 2.1 og 2.0 og forældede standarder, der bruges af love og styrende organer internationalt. Det er ikke uløseligt, men det kræver lidt mere eftertanke og diskussion. Arbejdsgruppen overvejer det allerede, men det er værd at nævne, indtil der er fundet en løsning.
- Jeg har altid brugt analogien, at vi ikke skaber ny teknologi, hjælpemidler eller andet, baseret på elendig kode (eller alfabetsuppe, som jeg ynder at kalde det), så ved at miste parsing, sænker vi så HTML-standarden hele vejen rundt?
- Gør vi os antagelser om, hvor mange AT-brugere der holder browsere og deres AT opdateret og aktuelt? Er dette et eksempel på, at vi fokuserer for meget på nordamerikanske eller europæiske statistikker om brug af hjælpemidler?
Understøttende dokumenter
Arbejdsgruppen fortsætter med at udvikle teknikker, der dokumenterer tilstrækkelige og fejlbehæftede eksempler til WCAG 2-serien af retningslinjer, med vægt på at udvikle teknikker til de nye kriterier i WCAG 2.2. Yderligere støttedokumenter, herunder How to Meet WCAG 2.2 og Forståelse af WCAG 2.2er tilgængelige til gennemsyn nu.
Fremtidige versioner
Endelig er det usandsynligt, at der kommer en WCAG 2.3, men som jeg lærte for længe siden, skal man aldrig sige aldrig. Efter udgivelsen af version 2.2 forventes det, at størstedelen af arbejdsgruppens indsats vil blive lagt i en fremtidig version af retningslinjerne for tilgængelighed, som WCAG 3.0 eller Silver, som den stadig kaldes i nogle tilgængelighedskredse. 3.0 vil være en væsentlig revision af WCAG-retningslinjerne og vil ikke være bagudkompatibel. Det ligger dog stadig mange år ude i fremtiden, så det er vigtigt, at alle forstår 2.2 nu og i den nærmeste fremtid.
