WCAG 2.2 – ny rekommendation
Web Content Accessibility Guidelines (WCAG) är tillgänglighetsvärldens motsvarighet till stentavlorna med budord som Moses sägs ha kånkat ned från Sinai för ett (bra) tag sedan. WCAG är grunden för det mesta av den lagstiftning om digital tillgänglighet som finns runt om i världen. Här i Europa hänvisar normen EN 301 549 till WCAG och i Sverige hänvisar lagen om tillgänglighet till digital offentlig service (DOS-lagen) och – snart – lagen om vissa produkters och tjänsters tillgänglighet till den normen.
Version 1 av WCAG kom 1999, version 2.0 kom 2008 och fick 2018 en uppdatering i form av version 2.1. Nu är det dags för ännu en uppdatering, i väntan på en framtida version 3.0. Uppdateringen har, inte helt oväntat, nummer 2.2.
WCAG 2.2 lägger till 9 nya krav (som kallas kriterier i WCAG) jämfört med 2.1 och slopar också ett krav som funnits med sedan 1999.
Kriterierna i WCAG är indelade i tre olika nivåer som kallas A, AA och AAA. En webbsida, ett dokument eller en app kan överensstämma med en viss nivå. Att överensstämma med AA-nivån (vilket EN 301 549 kräver) innebär att man uppfyller samtliga kriterier på nivåerna A och AA, men inte alla på nivå AAA.
De nya kraven gäller
- hjälpfunktioner
- fylla i samma information bara en gång
- alternativ till att dra med mus eller pekskärm
- minimistorlek för klickbara objekt
- fokusmarkering (3 kriterier)
- autentisering (2 kriterier).
Avskaffade krav i WCAG 2.2
Det avskaffade kravet är 4.1.1 Parsing (nivå A) som kräver att webbsidor uppfyller vissa aspekter av HTML-specifikationen. Med hjälp av en validator (ett slags stavnings- och grammatikkontroll av HTML-kod) kan man kontrollera att koden följer specifikationen. Vissa typer av fel kan göra att hjälpmedel, till exempel skärmläsare, inte kan förmedla innehållet på rätt sätt till användaren.
Det vore bra om dagens webbredaktörer och utvecklare kan HTML, men redaktörer arbetar i dag ofta med peka-och-klicka–gränssnitt där de är hårt begränsade i vad de får göra. Och många utvecklare förstår inte all inbyggd funktionalitet med HTML och kopierar i stället JavaScript från Stackoverflow i stället.
Därför är större delen av HTML-specifikationen nu beskrivningar av hur ogiltig kod ska tolkas. Webbläsare och hjälpmedel måste kunna gissa vad en redaktör eller utvecklare egentligen menade, i stället för vad de faktiskt skrivit.
WCAG 2.2 slopar alltså kravet på giltig HTML, med hänvisning till att dagens hjälpmedel inte längre tolkar HTML-kod utan kommunicerar med gränssnitt i webbläsaren. Man flyttar alltså ansvaret från redaktörer och utvecklare till webbläsaren och legaliserar ”taggsoppa” (HTML utan mening eller struktur).
HTML-specifikationen (på engelska).
Nya krav i WCAG 2.2
Hjälpfunktioner (3.2.6)
Det nya kriteriet 3.2.6 Consistent Help (nivå A) innebär att vissa typer av hjälpfunktioner som finns på flera sidor ska komma i samma relativa ordning gentemot övrigt innehåll (om inte användaren själv säger något annat).
De hjälpfunktioner kriteriet omfattar är
- kontaktuppgifter som e-postadress och telefonnummer
- kontaktfunktioner för mänsklig hjälp
- FAQ (vanliga frågor), hjälpsidor, support och dokumentation
- chatbottar och liknande automatiserade hjälpfunktioner.
Kriteriet innebär inte att man måste ha dessa hjälpfunktioner och inte heller att alla funktioner måste finnas på alla sidor. Men om någon eller några av dem finns på flera sidor ska de alltså återfinnas på samma ställe i förhållande till övrigt innehåll, så att de är lätta att hitta.
Exempel kan vara att kontaktuppgifter finns i sidfoten, en FAQ-länk i sidhuvudet och en ikon som aktiverar en chatbot alltid ligger sist i artikeln.
Kontaktfunktioner för mänsklig hjälp kan till exempel vara kontaktformulär där man får svar via e-post, eller en chattfunktion där man kommunicerar med en person (alltså inte en chatbot).
Kravet betyder inte att funktionerna alltid måste finnas på samma ställe, visuellt. De kan finnas på olika platser beroende på hur stor skärm eller hur stort fönster man har, om man använder zoom, och så vidare. Men så länge förutsättningarna är desamma ska funktionerna finnas på samma plats relativt annat innehåll. Chattikonen ska inte finnas i början av en sida och i slutet av en annan.
För de flesta webbplatser får nog det här kravet ingen större effekt. De har redan sina hjälpfunktioner placerade på ett konsekvent sätt.
Fylla i information bara en gång (3.3.7)
Det nya kriteriet 3.3.7 Redundant Entry (nivå A) innebär att man ska slippa fylla i samma uppgifter flera gånger i samma process. Uppgifter som man matat in en gång och som behövs i ett annat sammanhang ska tjänsten antingen fylla i åt en eller erbjuda som förslag.
Detta underlättar för användare som har svårt med inmatning, till exempel på grund av dyslexi, nedsatt finmotorik eller för att de behöver alternativa sätt att mata in text som ofta kan vara tidsödande och tröttande (som ögonstyrning).
Det gör också att man slipper komma ihåg exakt vad man skrivit tidigare, något som underlättar för den som har problem med närminnet eller andra kognitiva problem.
Kravet gäller för en process – det innebär inte att tjänster behöver lagra information för återanvändning i en annan session eller i en annan e-tjänst.
Det finns några undantag från det här kriteriet:
- Om det är en förutsättning för tjänsten att man måste mata in informationen på nytt (till exempel ett spel som bygger på minnesförmåga).
- Av säkerhetsskäl, som när man skapar ett nytt lösenord och behöver skriva in det två gånger för att minska risken för felskrivning när man inte ser vad man skriver.
- Om den tidigare inmatade information inte längre är giltig.
Kravet dikterar inte vilka fält man får använda. Ett vanligt, om än tveksamt, sätt att minska risken för att användare anger fel e-postadress är att tvinga dem att skriva in den två gånger. Även om det är en falsk trygghet blir den helt meningslös om tjänsten måste fylla i det andra fältet automatiskt. Undantaget av säkerhetsskäl går därmed att tillämpa här. Och det är inte förbjudet att kräva inmatning två gånger av en e-postadress; bara dumt.
Det här kravet kan sätta stopp för vissa riktigt enkla tjänster, men avgränsningen att det bara gäller inom en process gör att det inte bör innebära några större tekniska problem att uppfylla kravet.
Alternativ till att dra med mus eller pekskärm (2.5.7)
Det nya kriteriet 2.5.7 Dragging Movements (nivå AA) innebär att funktioner där användaren ska dra ett objekt med mus eller med fingrar på en pekskärm måste gå att utföra på ett alternativt sätt med mus eller ett finger, utan att behöva dra.
Användare med nedsatt rörlighet eller finmotorik kan ha svårt att utföra dragrörelser. Sådana rörelser kräver flera olika handgrepp: först att trycka eller klicka för att bestämma startpunkten, sedan att hålla ned fingret eller musknappen medan man förflyttar pekaren, för att till sist släppa upp när man nått slutpunkten. Den som använder ett förstorande hjälpmedel kanske inte ens ser både start- och slutpunkterna samtidigt.
En funktion för att panorera en virtuell anslagstavla kan exempelvis ha knappar som användaren kan klicka på för att panorera uppåt, nedåt, åt höger och åt vänster. En sorterbar lista eller tabell kan ha knappar för att flytta en markerad rad uppåt eller nedåt. Ett skjutreglage kan ha knappar för att öka och minska värdet.
Notera att det sedan tidigare finns krav på att funktioner för mus och pekskärm också ska gå att utföra med tangentbord. Men det räcker alltså inte för att uppfylla 2.5.7, som kräver att funktionerna ska gå att utföra med mus eller pekskärm, men utan att dra.
Ett annat kriterium som funnits några år är 2.5.1 Pointer Gestures (nivå A), som reglerar gester som är beroende av rörelsebanan. Dragrörelser omfattas inte av 2.5.1 eftersom bara start- och slutpunkterna har betydelse för funktionen, inte hur man för pekaren däremellan.
Undantagen för detta kriterium handlar om funktioner som inte går att realisera utan dragrörelser och om funktioner som finns i webbläsaren eller operativsystemet, till exempel att skrolla på en pekskärm.
Det här kommer att medföra en del merarbete för tjänster som har dra-och-släpp–funktioner. Samtidigt täpper det till den lucka som 2.5.1 lämnade öppen, och det är ju bra.
Minimistorlek för klickbara objekt (2.5.8)
Det nya kriteriet 2.5.8 Target Size (Minimum) (nivå AA) medför att element som användaren kan klicka på med mus eller pekskärm ska vara minst 24×24 CSS-pixlar (px). Detta för att underlätta för användare med nedsatt finmotorik, men också för att underlätta användning med pekskärm där man inte har samma precision som med en mus.
Kravet på storlek innebär att en kvadrat med sidan 24 px ska rymmas inom elementet utan att sticka utanför någonstans. Elementet i bilden nedan är alltså inte tillräckligt stort, trots att dess yta är större än kvadratens.
Det finns fem undantag från det här kriteriet:
- Om de klickbara objekten är mindre än 24×24 px men är placerade så att cirklar med diametern 24 px som är centrerade på varje objekt inte överlappar. Alltså att det finns tillräckligt stort avstånd mellan objekten.
- Om samma funktion går att utföra med någon annan mekanism på sidan, som uppfyller kriteriet.
- Om det klickbara objektet finns i löpande text eller på annat sätt begränsas av radhöjden. Till exempel länkar i brödtext (men inte i menyer).
- Om objektets utseende styrs av webbläsaren.
- Om ett specifikt utseende är nödvändigt, eller ett lagkrav, för den visade informationen.
Bilden nedan visar ett exempel på två runda knappar som är 20 px i diameter – alltså mindre än minimikravet. Om avståndet mellan knapparna är minst 4 px uppfyller de det första undantaget. Ligger de däremot utan avstånd emellan kommer testcirklarna att överlappa, så 2.5.8 blir underkänt.
Kravet i sig är bra. Att klicka med mus eller trycka med fingrar på pyttesmå element är svårt för många. 24 px är dock i minsta laget, särskilt på pekskärmar. Förklaringen med cirklarna som inte får överlappa, i det senaste förslaget, känns också lite väl komplicerad. Särskilt om man har oregelbundet formade komponenter kan det vara komplicerat att hitta centrum.
Fokusmarkering (2.4.11, 2.4.12, 2.4.13)
En tydligt synlig indikering av vilket element på sidan som har tangentbordsfokus är av kritisk betydelse för seende användare som inte kan använda mus, pekskärm eller liknande styrmedel.
Det finns redan kriterier som ställer krav på att fokusmarkeringen är synlig och att den uppfyller krav på kontrast mot omgivningen, men tre nya kriterier täpper till luckor i de gamla kraven.
Skym inte element med fokus (2.4.11, 2.4.12)
De nya kriterierna 2.4.11 Focus Not Obscured (Minimum) (nivå AA) och 2.4.12 Focus Not Obscured (Enhanced) (nivå AAA) innebär att element som får fokus inte får vara helt (2.4.11) eller delvis (2.4.12) skymda av annat sidinnehåll.
Ett vanligt problem som de här kriterierna ska bota är ”falska modaler”. Det handlar om dialogrutor, till exempel för att tvinga användaren att godta kakor, som ser ut att vara modala, men inte är det.Det vill säga att fokus går att flytta ut ur dialogen med Tabb-tangenten. Sådana dialogrutor skymmer ofta element på den underliggande sidan när de får fokus.
Ett annat problem är ”sticky” sidhuvuden och sidfötter som inte skrollar med resten av sidan. De skymmer ofta fokuserbara element när man skrollar innehållet.
En olycklig formulering i 2.4.11 kommer förmodligen att leda till många heta diskussioner framöver. Kravet säger att elementet med fokus inte får vara helt dolt. Men var går gränsen för hur mycket som måste synas? Det framgår inte. En tolkning är att användaren måste kunna känna igen elementet. En annan är att det räcker om en enda pixel går att urskilja.
Förhoppningsvis kan det få några utvecklare att inse att det finns användare som navigerar med tangentbord också, och att det som ser ut som en modal dialogruta även ska bete sig som en – oavsett hur användaren väljer att navigera.
Minimistorlek för fokusmarkeringen (2.4.13)
Det nya kriteriet 2.4.13 Focus Appearance (nivå AAA) ställer krav på hur stor fokusmarkeringen måste vara och hur den ska se ut.
Kriteriet säger att fokusmarkeringen ska ha minst lika stor yta som en 2 CSS-pixlar (px) tjock omkrets kring den ofokuserade komponenten och dessutom ha ett kontrastförhållande på minst 3:1 mellan varje pixel i det fokuserade och det ofokuserade tillståndet.
Kravet på yta gäller alltså ytan som själva fokusmarkeringen har, inte ytan den omger. En 2 px tjock rektangel som är 100×30 px har alltså ytan 520 px² (2×2×100 + 2×2×30 px). Alltså betydligt mindre än ytan den omger, som är 3000 px². Ytan för fokusmarkeringar som inte är rektanglar kan vara komplicerad att räkna ut. En 2 px tjock cirkel med diametern 40 px har exempelvis ytan 251 px².
Bilden nedan visar två knappar med en fokusmarkering som är 2 px tjock. Den första ligger 2 px utanför knappen och är därmed tillräckligt stor. Den andra ligger med 2 px indrag inuti knappen och uppfyller därför inte kravet på storlek – den skulle behöva vara minst 3 px tjock.
Kravet på kontrast gäller alltså mellan varje pixel som ingår i fokusmarkeringen, jämfört med samma pixel innan markeringen syns – vilket ofta är bakgrundsfärgen runt komponenten, om fokusmarkeringen omger komponenten, som den första knappen i bilden ovan. I den andra knappen i bilden är det kontrasten mellan fokusmarkeringen (röd) och knappens bakgrundsfärg (ljusblå) som ska vara minst 3:1.
Undantag från 2.4.13 är om markeringen styrs av webbläsaren och inte går att ändra, eller om man använder webbläsarens fokusmarkering och inte ändrar bakgrundsfärgen som indikatorn visas mot. Att förlita sig på webbläsarens fokusmarkering är alltså bara tillåtet om man inte ändrar bakgrunden.
Det här kravet är väldigt viktigt för alla som navigerar med tangentbord. Tyvärr har det halkat ned till nivå AAA i det senaste förslaget. Det lär innebära att de flesta kommer att bortse från det, eftersom det inte blir lagkrav. Det blir inte bättre av att reglerna är så komplicerade att förklaringen fyller 16 A4-sidor!
Autentisering (3.3.8, 3.3.9)
Autentisering innebär att man bevisar att man är den man utger sig för att vara. Det kan vara allt från enkla användarnamn eller lösenordsfält till komplexa processer med tvåfaktorsverifiering till biometrisk avläsning av fingeravtryck, näthinna, ansikte eller röst.
De nya kriterierna 3.3.8 Accessible Authentication (Minimum) (nivå AA) och 3.3.9 Accessible Authentication (Enhanced) (nivå AAA) innebär att en autentiseringsprocess inte får innehålla något steg som prövar en kognitiv funktion. Exempel på prov av kognitiva funktioner är lösenord (minne) eller att utföra en matematisk beräkning, svara på en kunskapsfråga eller lösa en CAPTCHA där man ska tolka förvrängd text (kognitiv förmåga).
Båda kriterierna medger undantag om det finns en annan autentiseringsmetod som inte prövar en kognitiv funktion.
Ett annat undantag är om det finns något sätt som kan hjälpa användaren att genomföra ett prov av kognitiv funktion. Exempel på det är om ett lösenordsfält tillåter att användare kopierar sitt lösenord från en lösenordshanterare och klistrar in det i fältet.
För 3.3.8 finns ytterligare två undantag. Det första gäller objektigenkänning, alltså att användaren ska känna igen vissa bildmotiv. Det andra undantaget är om det kognitiva funktionsprovet innebär att man ska identifiera en bild, film eller ljudfil som man själv laddat upp i tjänsten.
Separata autentiseringsprogram, exempelvis e-legitimation (BankID, Freja eID med flera) räknas inte som prov av en kognitiv funktion enligt de här kriterierna. Även om sådana lösningar innehåller kognitiva funktionsprov förmodas användare som själva valt att installera dessa lösningar kunna använda dem.
CAPTCHA – funktioner som ska försöka skilja mellan robotar och människor – är ett otyg. Det är i grunden ett feltänk, eftersom det vältrar över ansvaret på användarna att lösa webbplatsens problem. De allra flesta lösningar dras med bristande tillgänglighet. Att kräva alternativ för dessa är bra, men undantaget för objektigenkänning i 3.3.8 gör det hela tämligen urvattnat. Det är svårt att se någon annan motivering till det här undantaget än att man inte vågar sätta stopp för Googles reCAPTCHA, som används av otaliga webbtjänster (till många användares förtret). 3.3.9 har visserligen inte detta undantag, men är på AAA-nivå och därmed inte lagkrav. I praktiken innebär det i de flesta fall att kravet inte existerar.
När blir det här lagkrav?
DOS-lagen och Lagen om vissa produkter och tjänsters tillgänglighet hänvisar inte direkt till WCAG, utan till normen EN 301 549, som i sin tur hänvisar till WCAG. Den europeiska standardiseringsorganisationen ETSI håller på att ta fram en ny version av EN 301 549 som bland annat ska hänvisa till WCAG 2.2 i stället för 2.1. Arbetet beräknas vara klart under första halvåret 2025.
När ETSI gett ut den nya normen är nästa steg att EU ska anta den och publicera beslutet i sin officiella tidning. Därefter kan Myndigheten för digital förvaltning (Digg) uppdatera sina föreskrifter om tillgänglighet till digital offentlig service så att de hänvisar till den nya normen. Först då gäller WCAG 2.2 för DOS-lagen.
För Lagen om vissa produkter och tjänsters tillgänglighet blir det motsvarande process: tillsynsmyndigheten behöver hänvisa till den nya normen i sina föreskrifter.
I värsta fall innebär de nya kraven så pass stora förändringar att myndigheterna behöver genomföra en konsekvensanalys innan de kan börja hänvisa till den nya normen. Då kommer processen att ta ännu längre tid.
Den goda nyheten är att fram till dess fortsätter giltig HTML-kod att vara ett lagkrav…
