Det har været længe undervejs, men WCAG (Web Content Accessibility Guidelines) 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 etape. En foreslået anbefaling betyder, at W3C har accepteret den, og W3C-medlemmerne vil nu stemme om at udgive dokumentet som en W3C's anbefaling. Afstemningen slutter den 19. august 2023, og håbet er, at den vil være klar til at blive offentliggjort kort tid efter, men det er 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 bygger 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. To af dem er 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 kriterier i 2.1 vil disse sigte mod at hjælpe brugere med nedsat syn, kognitive og indlæringsmæssige handicap og brugere 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 og niveauer, og hvad de betyder for slutbrugerne.
Retningslinje 2.4 Sejlbar
Under Guideline 2.4 Navigable ligger tre af de nye SC. Her finder vi 2.4.11 Fokus ikke skjult (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 af indhold, der kan overlappe fokuserede elementer og forårsage et tilgængelighedsproblem, er klæbende sidefødder eller overskrifter. Når en bruger bladrer 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 foregående og siger ganske enkelt, 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 inkonsekvente måde, hvorpå synlig fokus for tastaturfokusindikatorer bestemmes som tilgængelig eller ej, har stået på i, ja, helt ærligt, lige så længe, som jeg har været i branchen (hvilket er 10 år). Selv om det er et niveau AAA, afslutter denne nye SC endelig enhver debat, og det er helt ærligt en meget velkommen tilføjelse!
Det vigtigste ved dette succeskriterium er, at der tages højde for farvekontrastforhold. Når du angiver fokus, skal du have et kontrastforhold på mindst 3:1 og en omkreds på mindst 2 CSS-pixels. Det er med til at sikre, at tastaturbrugere nemt kan se, hvilket interaktivt element der har fokus.
Retningslinje 2.5 Inputmodaliteter
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 udset til at være et niveau AA-kriterium, som sikrer, at trækbevægelser kan udføres med en enkelt markør uden at trække, medmindre det er afgørende at trække. Det svarer til markørbevægelser, hvor der tales om retningsbestemte stibaserede bevægelser og flerpunktsbevægelser. Forskellen her er definitionen af, hvad der er en trækbevægelse. Med træk 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 findes alternativer til brugere, der ikke kan trække, hverken 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 forbundne ikoner nemt kan aktiveres uden ved et uheld at aktivere et nærliggende mål. 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 omfatte 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 tilgængelige 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 dette sæt.
Det betyder, at hvis du har en chatmulighed, skal den være let at finde på samme sted på alle sider i rejsen, f.eks. i nederste højre hjørne, så det er let at finde hjælpemuligheder. 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 forbindelse med udfyldelse af formularer og autentificering.
Lad os starte med 3.3.7 Overflødig indtastning, som er planlagt til at være et niveau A-kriterium. Når man udfylder en formular, hvor der anmodes om data, som allerede er blevet indtastet tidligere i formularen, skal gentagne data være tilgængelige via autoudfyldning 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 genkalde oplysninger fra 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 der ikke bør kræves en kognitiv test 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 giver mulighed for at kopiere og indsætte 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 minimumsversion, 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 i forbindelse med denne beslutning.
Arbejdsgruppen har konkluderet, at eventuelle 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. De andre parsing-problemer, der ofte opstår, skaber ikke længere tilgængelighedsfejl baseret på, hvordan nutidens browsere og hjælpeteknologier gengiver koden.
Det er værd at bemærke, 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.
Der er et par punkter, man kan tale om, og det har givet anledning til nogle robuste samtaler (pun intended). 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 brug af nogens tid?
- 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 daterede standarder, der bruges af lovgivende og styrende organer internationalt. Det er ikke uløseligt, men det kræver mere eftertanke og diskussion. Arbejdsgruppen er allerede i gang med at overveje det, men det er værd at nævne, indtil der er fundet en løsning.
- Jeg har altid brugt den analogi, at vi ikke skaber ny teknologi, hverken hjælpemidler eller andet, baseret på dårlig kode (eller alfabetsuppe, som jeg kalder det), så ved at droppe parsing sænker vi HTML-standarden i det hele taget?
- Gør vi os antagelser om, hvor mange hjælpemiddelbrugere der holder browsere og deres hjælpemidler opdaterede og aktuelle? Er det 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 skabe teknikker, der vil dokumentere tilstrækkelige og fejlbehæftede eksempler for WCAG 2-serien af retningslinjer, med vægt på at skabe 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 for gennemgang 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 betydelig revision af WCAG-retningslinjerne og vil ikke være bagudkompatibel. Dette ligger dog stadig mange år ude i fremtiden, hvilket gør alles forståelse af 2.2 til en høj prioritet nu og i den nære og mellemlange fremtid.
