WCAG - En fördjupning

 Denna vecka hade vi lektion med Johan Kling från Funka, som kommer hålla i de flesta lektionerna de kommande fyra Funka-veckorna. Johan bor i Stockholm och är utbildad byggnadsingenjör. Han har ingen utbildning inom webbutveckling eller webbtillgänglighet, men har varit intresserad av webben sedan 1990-talet. Från början ville han bli arkitekt, men han insåg att han fick utlopp för sin kreativitet genom webbutvecklingen också och valde därför att arbeta med det. Johan var med och startade Funka för ungefär 20 år sedan och idag är han kvalitetschef. Det innebär att han hjälper kunder att hålla den kvalitét de önskar, men han ser också till att Funkas egna tjänster håller en hög kvalitét. Johan är certifierad i tillgänglighet via en branschorganisation vid namn IAP.

 

Måndag

Måndagen började med att Johan Kling presenterade sig själv och därefter fick vi deltagare berätta lite om oss och vilka hjälpmedel vi tar hjälp av när vi använder den digitala tekniken. Därefter fick vi en föreläsning om WCAG.

 

Kort om WCAG

WCAG står för Web Content Accessibility Guidelines och är en internationell standard som tagits fram av en arbetsgrupp som heter Web Accessibility Initiative. Det är en grupp inom W3C som arbetar med olika standarder.

 

Historia om WCAG

År 1999 kom den första versionen som hette WCAG 1.0. år 2000 fick Johan ett uppdrag från en organisation som hette Handikapp.se, som bestod av flera olika funktionshinderorganisationer som ville lösa IT-frågor. Organisationen hade fått arvsfondspengar för att utveckla en portal som skulle skötas av hjälpmedelsanvändare. Det behövde också byggas ett publiceringsverktyg till portalen och det var av yttersta vikt att verktyget fungerade med hjälpmedel. Johan, som inte hade någon kunskap om tillgängliga webbplatser, fick i uppdrag att bygga publiceringsverktyget och utgå från det då nya WCAG för att det skulle bli bra. Det var många nya tekniker och de fungerade dåligt i de webbläsare som fanns år 2000. Tack vare att han samarbetade med Handikapp.se så fanns det många användare som kunde hjälpa till och testa det han hade byggt. Det visade sig att det fanns stora problem, eftersom hjälpmedlen inte alltid fungerade såsom man önskade, och så är det än idag. För 20 år sedan var det dock betydligt svårare. Hjälpmedelsutvecklarna gjorde så gott de kunde, men eftersom det inte fanns några tillgängliga webbplatser så var det extremt svårt att utveckla tekniska hjälpmedel som fungerade bra. Tack vare användartestning så gick det framåt. Tillslut hade de en portal och ett publiceringsverktyg som både följde html-standarden, WCAG och fungerade med hjälpmedel. Det var utifrån detta projekt som Johan och tre personer till startade Funka, för att se till att fler webbplatser skulle fungera med hjälpmedel.

År 2008 publicerades WCAG 2.0. Den stora skillnaden var att den gamla versionen enbart var inriktad på webb (html), men den nya skulle vara mer teknikoberoende. Det blev inte helt perfekt, men betydligt bättre. Idag kan man exempelvis använda WCAG för att kontrollera tillgängligheten i en PDF-fil.

Tio år senare kom WCAG 2.1, den innehöll alla punkter som 2.0, men med 17 ytterligare punkter. Målet var att innefatta fler användargrupper än de tidigare versionerna. Tidigare hade fokus mest legat på gravt synnedsatta och dessas hjälpmedel, vilket är olika typer av skärmläsare. De användargrupper som blev högre prioriterade var personer med kognitiva nedsättningar, användare som är synsvaga och beroende av bra kontrast och förstoring samt personer som behöver röststyrning. Man förstod också att vi blivit mer mobila med åren, så i den nya versionen ingick det att all information skulle gå att ta till sig via alla skärmar.

Målet är att släppa en ny uppdatering vartannat år, men det blir inte riktigt så. I höstas skulle WCAG 2.2 släppts, men den blev försenad och släps förhoppningsvis under 2022. Det jobbas också på en större uppdatering som har arbetsnamnet WCAG 3.0.

 

 

Fyra principer inom WCAG

·         Perceivable – Möjlig att uppfatta

·         Operable – Möjlig att hantera

·         Understandable – Möjlig att förstå

·         Robust – Pålitlig, kan tolkas av hjälpmedel

Varje princip har övergripande riktlinjer, sammanlagt är de 13 stycken.

Perceivable – Möjlig att uppfatta

·         1.1 Textalternativ
Det ska finnas ett textalternativ till allt innehåll som inte är textbaserat, exempelvis bilder, filmer och diagram. Användaren ska kunna förstora texten, få den uppläst eller omvandlad till punktskrift. Det är denna punkt som nämns först när vi börjar prata om webbtillgänglighet.

·         1.2 Tidsberoende media
Det ska finnas alternativ för tidsberoende media. Filmer eller ljudbaserade poddar ska finnas i textformat. Teckenspråk är också ett alternativ för tidsberoende media.

·         1.3 Anpassningsbart
Innehåll ska kunna förändras, behöver användaren förstora text ska det fungera. Texten ska inte klocka med annat innehåll när gränssnittet förstoras. Webbplatsen ska vara densamma oavsett om man använder en dator eller en mobiltelefon. All information ska gå att komma åt oavsett vilken typ av skärm som används.

·         1.4 Urskiljningsbart
Innehåll ska gå att se, det ska vara bra kontrast och inte beroende av färg. Aktören ska inte referera till innehåll som bara är tillgängligt visuellt, alltså att användare med skärmläsare inte kan komma åt det.

Operable – Möjlig att hantera

·         2.1 Tangentbord
All funktionalitet och information ska gå att komma åt utan en datormus, alltså med hjälp av tangentbordsnavigering.

·         2.2 Tillräckligt med tid
Användaren ska ges tillräckligt med tid för att ta del av informationen. Det kretsar mycket kring att utföra tjänster, användaren ska hinna läsa informationen och fylla i tjänsten innan det händer något automatiskt. Ett exempel är att man blir automatiskt utloggad. Aktören ska erbjuda stöd och spara så mycket som möjligt, så användaren inte behöver göra om arbetet.

·         2.3 Krampanfall och fysiska reaktioner
Det finns ett krav som hanterar blinkningar i gränssnitt, för att ingen ska kunna få epileptiska anfall av webbplatsen. Johan har som tur är aldrig varit med om någon som brutit mot kravet.

·         2.4 Navigerbart
Det ska finnas flera sätt att navigera på webbplatsen. Tycker användaren inte om en vanlig meny så ska det finnas en sökfunktion eller webbkarta. På en webbplats ska det finnas minst två olika sätt att navigera på. Det är också viktigt att menyn är tydlig och att det är enkelt att hitta det man söker. Användaren ska veta var på hemsidan man befinner sig, om man är inne i en djupare struktur. Mer än hälften av en webbplats besökare kommer dit med hjälp av Google och då besöker man aldrig startsidan. Då är det viktigt att förstå var på webbplatsen man befinner sig, så att man kan hitta samma innehåller nästa gång man besöker webbplatsen, även om man väljer att gå via startsidan.

·         2.5 Inmatningsenheter
Detta handlar om exempelvis en datormus, tangentbord eller röststyrning. Oavsett vilken inmatningsenhet man använder så ska man kunna ta del av webbplatsen.

Understandable – Möjlig att förstå

·         3.1 Läsbart
Denna riktlinje har stor förbättringspotential. Det står bara att textinnehåll ska vara läsbart och begripligt, men inte hur. Därför är det svårt för aktören att veta hur de ska följa riktlinjen.

·         3.2 Förutsägbart
Aktören ska använda etablerade principer och koncept. Det är viktigt att ha samma struktur på hela webbplatsen. Formulär är ett bra exempel, om formulären har skicka-knappen längst ner till höger, så ska ett formulär inte ha avbryt-knappen på samma plats och skicka-knappen till vänster. Webbplatsen ska vara enkel för användaren att lära sig. Knappar ska ha tydliga namn och aktören ska inte referera till samma sak på olika sätt, exempelvis START och HEM.

·         3.3 Inmatningsstöd
Detta handlar om att hjälpa användaren att undvika misstag, alternativt att rätta till de misstag som begås. Om det står att användaren ska fylla i sitt personnummer med tolv siffror, men ändå skriver 10, så kan man med hjälp av programmering lista ut de första två siffrorna, så användaren ändå kan gå vidare. Det ska finnas tydliga och bra instruktioner, så risken för misstag minimeras.

Robust – Pålitlig, kunna tolkas av hjälpmedel

·         4.1 Kompatibelt
Programmerare ska följa standarder och inte frångå dem vid programmering av webbplatser. Följer man standarder så vet man att webbplatsen fungerar i de olika webbläsare som finns. Utgår man från standarder så är webbplatsen kompatibel med olika hjälpmedel, exempelvis skärmläsare. Rubriker behöver vara kodade som rubriker, för att skärmläsaranvändare ska kunna hoppa mellan dem, för att ge ett exempel.

 

Tre olika nivåer i WCAG – A, AA och AAA

Lagkravsnivå är AA, vilket inkluderar både A och AA. Det är minimikrav, men det är ingen nackdel att uppfylla vissa punkter i AAA. Det kan finnas stora fördelar med det, som inte är så besvärliga att utföra.

 

Uppgift – Kontrast

I WCAG 2.1 finns två olika framgångskriterier gällande kontrast på nivå AA. Det ena handlar om text mot bakgrund och det andra om objekt mot bakgrund. Det finns också ett utökat krav gällande kontrast för text, men det ligger på nivå AAA och omfattas alltså inte av lagen.

Framgångskriteriet för kontrastminimum för text på nivå AA heter 1.4.3. Det säger att text mot bakgrund ska ha ett kontrastvärde som är minst 4,5:1. Det finns en formel för att räkna ut kontrastvärde, men det finns också automatiska verktyg som hjälper oss att göra det. Det finns dock tre undantag.

·         Om normal text är större än 24 pixlar, eller fetstilt är större än 18,5 pixlar, så räcker det att kontrastvärdet är 3:1.

·         Om texten är oväsentlig så finns det inte några krav på kontrast.

·         Logotyper är också ett undantag, det finns inga krav. Om aktören vill att alla ska kunna läsa logotypen så bör de ändå uppfylla kontrastkraven.

Framgångskriteriet 1.4.11 gäller kontrast för objekt mot bakgrund, det handlar om komponenter som formulärfält och knappar, men också grafiska medel såsom ikoner. Finns det en ikon med en text bredvid, exempelvis en spara-symbol och texten Spara, så mäter man kontrasten på texten, ikonen har inget kontrastkrav i det läget. Objekt har ett lägre krav på kontrastvärde, nämligen 3:1, precis som stor text.

Till onsdagens lektion fick vi i uppgift att installera Colour Contrast Analyser (CCA), vilket är ett gratisverktyg som mäter kontrast. För att använda programmet behöver man dock kunna se texten man ska mäta, Johan uppmanade mig att prova, men han var inte säker på att det skulle fungera. När jag först skulle installera det så fungerade det inte, det stod att jag skulle fylla i massa uppgifter, men när jag hade gjort det så kom jag ändå inte vidare. Under onsdagen pratade jag med Johan och han sa att jag inte skulle fylla i några uppgifter, så något hade gått snett. Jag fick länken igen och då var det plötsligt inga problem att installera verktyget. Jag provade att använda det på några olika hemsidor, både privata och inom den offentliga sektorn. På bilden nedan ser nu hur det såg ut när jag testade verktyget här på bloggen.

Syntolkning: Kontrasttest med CCA på EmelieASE. 

 

Onsdag

Onsdagens lektion började med en genomgång av uppgiften, var och en fick vi berätta hur det hade gått för oss. Vi fick också chansen att ställa frågor till Johan, bland annat hur det fungerar med hjälpmedel i olika operativsystem. Johan förklarade att alla hjälpmedel finns inbyggda i Mac, liksom i alla Apples produkter. Windows kommer med en egen skärmläsare som heter Narrator och man kan ladda ner skärmläsaren NVDA gratis. Skärmläsaren JAWS for Windows är populär, men den är väldigt dyr. Som tur är kan man få den som hjälpmedel, men man får inte alltid alla uppdateringar gratis. Därför tycker Johan det är bättre när hjälpmedlen är inbyggda.

Vi pratade om alternativtexter till bilder och Johan förklarade att de bara dyker upp för skärmläsaranvändare, de syns inte visuellt. Det tycker jag är dåligt, om man är gravt synskadad men använder förstoring istället för skärmläsare så kan behovet av syntolkade bilder ändå vara stort.

Därefter pratade vi om ytterligare ett framgångskriterie, 1.4.6, som ligger på AAA-nivå. Det är alltså inget lagkrav, men det handlar om ytterligare kontrast och det är bra att känna till. Enligt detta kriterium ska vanlig text ha ett kontrastvärde på 7:1, medan stor text ska ha ett kontrastvärde på 4,5:1. Liksom i 1.4.3 så har oväsentlig text och text i logotyper inga kontrastkrav.

 

Uppgift – 2.4.1

Vi pratade om framgångskriteriet 2.4.1 som handlar om att hoppa över grupperat innehåll. Det ska finnas en funktion för att hoppa över grupperat innehåll som upprepas på flera webbplatser. Detta är en funktion för seende personer som navigerar med tangentbord. Genom att tabba kan de hoppa mellan länkar på webbplatsen. De hoppar bakåt genom Shift + Tabb. I överkant på hemsidor finns navigeringen, vilken brukar innehålla många länkar, och personer som navigerar med tangentbord behöver tabba igenom alla dessa för att komma till sidans huvudinnehåll. Det finns dock en lösning som sparar tid för användaren. Om man trycker Tabb en gång så dyker det upp en ruta uppe i vänster hörn som heter Till innehållet på sidan. Trycker man Enter så hamnar man direkt på sidans innehåll.

Inför fredagens lektion fick vi i uppgift att gå in på ett antal myndighetshemsidor och prova om vi kunde hoppa över grupperat innehåll när vi tabbade oss fram. Nedan ser ni mitt resultat.

·         Försäkringskassan – Det fungerar.

·         Arbetsförmedlingen – Det fungerar.

·         Diskrimineringsombudsmannen – Det fungerar.  

·         Helsingborgs kommun – Det fungerar inte, när jag tabbar en gång så kommer jag till logotypen. Via den kan jag gå till startsidan, vilken jag redan befinner mig på.

·         Stockholms stad– Det fungerar

 

Fredag

Under fredagen hade vi en kort lektion som hölls av Sara från Funka. Vi började med att gå in på ett antal kommunhemsidor och provade att hoppa över grupperat innehåll. På vissa fungerade det bra och andra inte. Sara förklarade att funktionen är bra att använda på nyhetssajter, eftersom de ofta har mycket reklam som visas innan man kommer till själva innehållet. En av mina kamrater hade hittat en kommunhemsida där funktionen inte fanns, men när han tittade i källkoden såg allt bra ut. Vi konstaterade att det kan vara klurigt, eftersom man ibland behöver ladda om sidan för att det ska fungera. Hos en av kommunerna vi besökte hamnade man på en underrubrik när man hoppade över grupperat innehåll. Egentligen borde man hamna på huvudrubriken.

Hur gör man om funktionen inte fungerar? Man läser igenom tillgänglighetsredogörelsen och ser om det finns någon information om det, exempelvis om/när det ska åtgärdas. Man kan skriva återkoppling till myndigheten, vilket också görs via tillgänglighetsredogörelsen.

 

Under lektionen spårade vi ur från veckans tema och pratade om kognitiv tillgänglighet, vilket är lågt prioriterat i WCAG. Sara berättade om ett projekt vid namn Kognitiv kriterium och tillsammans tittade vi på deras webbplats. Där fanns både bra och dåliga exempel på kognitiv tillgänglighet, som kan vara en bra guide. Kognitiv tillgänglighet handlar bland annat om tydlighet, det ska finnas korta kärnfulla texter och visuella ledtrådar som hjälper användaren att hitta på webbplatsen.

Varför är detta inte prioriterat i WCAG? Sara berättade att många aktörer hävdar att deras webbplatser inte går att göra tillgängliga för personer med kognitiva nedsättningar. De menar att de måste ha mycket information och inte har möjlighet att korta ner sina texter. Dessutom påstår de att deras målgrupp inte är personer med svårigheter inom kognition. Ofta finns det en prestige i att ha långa och krångliga texter på sin webbplats.

W3C, som står bakom WCAG, jobbar mycket med detta, för att få fram fler lagkrav som kräver kognitiv tillgänglighet. Den europeiska standarden EN 301 549, som webbtillgänglighetsdirektivet lutar sig mot, ska uppdateras de kommande åren och då finns det möjlighet att lägga till fler krav om kognition. Alla människor upplever svårigheter med komplicerade hemsidor, därför gynnar sådana här krav hela befolkningen, inte bara personer med diagnoser.

 

Jag önskar er alla en trevlig helg i solskenet!  

/Emelie