Digital tillgänglighet

Introduktion till WCAG av Per Axbom

Senast uppdaterad:  25 oktober 2018.

Jag vill hjälpa dig att snabbt förstå hur du ökar möjligheten för så många människor som möjligt att använda digitala tjänster. Genom att skapa lösningar på ett inkluderande sätt hjälper vi alla människor.

Att lära sig grunderna för tillgänglighet behöver inte kännas svårt. De standardiserade rekommendationerna, Web Content Accessibility Guidelines (WCAG), innehåller 13 övergripande riktlinjer med tillhörande kriterier. Här får du alla dessa riktlinjer presenterade på ett enkelt sätt, och med exempel där det är relevant.

Med denna kunskap kan du snart själv börja bidra till mer tillgängliga digitala tjänster, och ställa krav på personer som bygger och förvaltar webbaserade lösningar.

Författare: Per Axbom, Coach & Designer, Axbom Innovation AB
Första utgåvan: Mars 2013. Senast uppdaterad: 25 oktober 2018.

---

---

Tabell 1 - Riktlinjer i WCAG

Tabellen innehåller genvägar till respektive riktlinje och ger information om vilka A-nivåer inom WCAG som finns för varje riktlinje. Varje riktlinje som har uppdaterats med kriterier från version 2.1 (2018) är markerad med texten 2.1. Riktlinje 2.5 är helt ny och därför markerad med texten Ny.

Riktlinje Nivå A Nivå AA Nivå AAA Område 1: Möjlig att uppfatta 1.1 Textalternativ Ja n/a n/a 1.2 Tidsbaserad media Ja Ja Ja 1.3 Strukturerat innehåll 2.1 Ja Ja (2.1) Ja (2.1) 1.4 Urskiljbart 2.1 Ja Ja Ja Område 2: Möjlig att kontrollera 2.1 Åtkomst via tangentbord 2.1 Ja n/a Ja 2.2 Tillräckligt med tid 2.1 Ja n/a Ja 2.3 Anfall (epilepsi och liknande) 2.1 Ja n/a Ja 2.4 Lättnavigerad Ja Ja Ja 2.5 Peka och markera Ny 2.1 Ja n/a Ja 2.6 Ytterligare sensoriska inmatningar
Denna var del av den preliminära versionen av WCAG 2.1 men de två kriterierna har vid publicering flyttat in under punkt 2.3 och 2.5. n/a n/a n/a Område 3: Möjlig att förstå 3.1 Läsvänlig för skärmläsare Ja Ja Ja 3.2 Förutsägbar Ja Ja Ja 3.3 Inmatningshjälp Ja Ja Ja Område 4: Robust 4.1 Kompatibilitet 2.1 Ja Ja (2.1) n/a

A. Inledning

Vad är tillgänglighet?

B. Riktlinjer i WCAG

En enkel förklaring av vägledningen

1.1 Textalternativ

Allt som inte är text ska beskrivas i text

Den första riktlinjen, som också bara har ett kriterium (1.1.1) handlar om att erbjuda textalternativ för allt som inte är text. Lyckas du med denna första regel har du fastställt grunden för en medvetenhet om tillgänglighet. Tyvärr är det många som inte ens klarar detta mest välkända krav.

Ett grundläggande problem med sådant som inte är text är att det utesluter människor och maskiner som har problem med att tolka bilder, video och/eller ljud.

ALT-attributet

De flesta människor som arbetar med webb-produktion känner till ALT-attributet och det är också det vanligaste exemplet när man pratar om tillgänglighet i digitala medier. Det är också ett av de mest felanvända.

Ett ALT-attribut beskriver en bild i textform, där ALT står för alternativ text. Så om jag har en bild på ett äpple kan det i ALT-attributet stå ”Ett äpple”. Det innebär att sökmotorer och skärmläsare för synskadade bättre kan återge vad bilden föreställer.

<img src="apple.jpg" alt="Ett äpple">

Saken är bara den att:

• vad du ska skriva i ALT-attributet är helt beroende av sammanhang. Är det färgen på äpplet som jämföras med andra äpplen, är det avbildningsformen, konstnären eller andra attribut som du bör föra fram?
• ibland är det rekommenderat att ALT-attributet är tomt, speciellt när det handlar om utfyllnadsbilder som inte är ett stöd för förståelse av texten. Ingen blir gladare av att texten ”leende människa” läses upp när man ska teckna elavtal. Observera dock att man inte får utesluta ALT-attributet, tomt innebär att det ska vara utskrivet enligt ALT="". I annat fall kan skärmläsaren börja leta efter ledtrådar i filnamnet.

Här är några andra exempel på ALT-texter som beskriver bilder med äpplen:

<img src="apple.jpg" alt="Ett halvätet grönt äpple med en tecknad mask som kikar ut och säger Hallå där!">

<img src="apple.jpg" alt="Ett stort, grönt äpple svävar framför ansiktet på en man i plommonstop, vilket påminner om Rene Magrittes kända målning">

Tänk på att det inte finns något självändamål att hålla sig kort i ALT-texter. Det viktiga är att du är tydlig och ger bra, relevant information. Det finns ingen begränsning i specifikationen som säger något om antal tecken, men rent krasst så finns det skärmläsare som bryter uppläsningen vid 125 tecken, så det kan vara en bra tumregel att hålla sig under det. Behöver man förklara med längre texter än så finns attributet longdesc som jag skriver mer om nedan.

När det handlar om dekorativa element, bilder som används för visuell formattering och sådant som inte ens visas på skärmen, så ska man implementera på ett sätt så att det kan ignoreras av stödteknik. Det gäller också när bilderna redan förklaras i text vid sidan om, och då inte behöver upprepas i ALT-attributet.

Det här är ett av få områden där förespråkare för SEO och tillgänglighet kan ha olika åsikter, där de som jobbar med sökmotoroptimering ibland vill att man använder ALT-attributet för viktiga nyckelord, även om det bara är dekorativa bilder. Det måste avgöras från fall till fall, men ALT-attributet ska aldrig störa uppläsningen och måste därför bidra till upplevelsen och förståelsen, inte göra den förvirrande.

Diagram är också bilder

En ofta bortglömd bildtyp som är ack så viktig när det gäller tillgänglighet är diagram: pajdiagram, grafer, infografik, piktogram med mera. Ibland handlar hela texten om diagrammet och då kan det räcka som stöd för att förstå vad bilden säger. Men ofta är diagrammet ett stöd för förståelse och då innehåller det en mängd information som också bör förmedlas i textform.

När man vill förklara en bild mer ingående än med bara 125 tecken (vilket alltså är en inofficiell rekommendation för ALT-texter) så finns det ett attribut som heter longdesc, vilket är kort för long description. För att göra helt rätt bör du alltså använda longdesc för att länka till en annan sida - eller en text på samma sida - som mer ingående beskriver bilden, eller diagrammets innehåll.

<img src="elefant.jpg" alt="En elefant från barnprogrammet Fem myror är fler än fyra elefanter" longdesc="https://sv.wikipedia.org/wiki/Fem_myror_är_fler_än_fyra_elefanter">

Fler textalternativ

Att förstå ALT-attributet utan och innan, och skälet till att det behövs och hur det läses upp, hjälper dig förstå hur du angriper liknande utmaningar inom digital tillgänglighet. Riktlinjen handlar nämligen om mycket mer än ALT-attribut för bilder.

• När du har video på sajten ska du ha text som beskriver denna video och förmedlar samma kunskap som förmedlas av videon. Det räcker inte då med att ha textning i själv videon, eftersom det inte kan läsas av stödverktyg.
• När du har ljud ska du ha text som beskriver innehållet i ljudfilen. I vår podcast UX Podcast har vi med hjälp av tjänster på fiverr.com på ett kostnadseffektivt sätt skapat fullständiga transkriptioner för vissa utvalda program.

Captcha-dilemmat

Det finns också en speciell skrivelse kring Captchas, ett fenomen som ibland är kryptiska suddiga bokstäver eller mystiska matematiska utmaningar som måste fyllas i för att bevisa att man är en människa. Dessa dyker ofta upp när man fyller i formulär, och är i grunden framtagna för att förhindra missbruk i form av illvillig programkod.

En Captcha är ju implicit något som inte har textalternativ för då skulle det gå att läsa av en dator, vilket skulle förvanska syftet, eftersom man just ska bevisa att det inte är en dator som skriver in information.

Problemet är ju att en Captcha då alltid utesluter många människor; inte bara blinda, utan även de med kognitiva funktionsnedsättningar, lindrigare synnedsättningar eller datorovana som helt enkelt stoppas från att komma vidare.

Jag vidhåller att Captcha inte ska behövas på de sätt som de är implementerade idag, men om du ändå tvingas dras med dem är det viktigt att det finns alternativ:

• Erbjud möjligheten att spela upp ett ljud som läser upp texten som ska skrivas in.
• Erbjud möjligheten att kontakta en kundtjänst som kan verifiera dig.
• Erbjud något helt annat alternativ, som att skicka SMS med en bekräftelsekod som matas in.

Jag vill i sammanhanget nämna att jag har ett kontaktformulär på min egen webbplats som tidigare användes regelbundet av automatiserade verktyg för att skicka så kallad spam (skräppost) till mig. Jag har nu lagt in en funktion på den sidan som innebär att om formuläret skickas inom 11 sekunder från att användaren går in på sidan så möts hen av ett meddelande som säger "Mindre än 11 sekunder har gått sedan du besökte sidan, använd gärna mer tid för att fylla i formuläret." Skickas formuläret inom 11 sekunder (vilket inte görs av någon människa) så får alltså de automatiserade verktygen uppfattningen att innehållet i formuläret har skickats, trots att det inte har det. All automatiserad skräppost via detta formulär har nu upphört, utan behov av en captcha.

När du inte KAN ha textalternativ

Jodå, det finns situationer när det inte är rimligt att ha textalternativ.

• Sensoriskt innehåll. När du har innehåll som är där för att skapa en viss känsla så innehåller textalternativet åtminstone en beskrivning av det icke-textuella innehållet. Det kan vara exempelvis vara ett ljud som skapar stämning.
• Test/prov/tenta. Om du erbjuder en uppgift, till exempel ett prov som ”Vad är det på bilden?”, där ett textalternativ skulle ge svaret så är det självklart orimligt att tvingas ge svaret i textform. Även här bör du åtminstone identifiera innehållet på ett beskrivande sätt, eller erbjuda ett alternativ.
• Live-video. Det är svårt att ge textalternativ för något som pågår i realtid. Riktlinjerna ger dock tips om hur du kan angripa detta, till exempel med teckentolkning eller realtidstextning — men då är vi inne och nosar på riktlinje 1.2: Tidsbaserad media.

Uppfyllnad av riktlinje 1.1

Det är ironiskt att många företag jag stöter på säger att de ska stödja nivå AA av WCAG, men lyckas inte ens uppfylla nivå A av den första riktlinjen (det finns bara nivå A för denna). De flesta företag är nämligen notoriskt usla på att erbjuda textalternativ för video och diagram, eller har en bristfällig implementation av Captcha.

Jag kan mycket väl acceptera att det har sina skäl att inte uppfylla riktlinjerna fullt ut, men då ska man vara medveten om det, och inte leva i en föreställning om att man minsann tillgodoser en viss nivå när man inte gör det. Varje avsteg från en ambition måste vara ett medvetet, välgrundat och dokumenterat val.

1.2 Tidsbaserad media

Beskriv, texta och tolka allt ljud och rörlig bild

1.3 Strukturerat innehåll

Allt i ordning från början till slut

1.4 Urskiljbart

Tydlighet framför allt

2.1 Åtkomst via tangentbordet

Effektivare navigering för många

För många år sedan hjälpte jag Storstockholms Länstrafik (SL) med deras reseplanerare och arbetade även med det (då helt nya) webbgränssnitt som SL:s kundtjänst använde. Kundtjänst innebär de personer som svarar på frågor om resvägar, tider och störningsinformation på telefon. Det gränssnittet skiljer sig avsevärt från det som vanliga resenärer ser, och framför allt är det enormt snabbjobbat. Det som gör det snabbjobbat är alla snabbkommandon via tangentbordet som kundtjänstpersonalen kan använda sig av för att snabbt hoppa mellan olika sökfält, samt exempelvis välja färdvägar och färdmedel.

Kundtjänstpersonalen ger oss ett tydligt exempel på situationella behov, snarare än permanenta behov.

En viktig aspekt av att möjjliggöra webbnavigering via tangentbordet är att det inte bara handlar om att tillgodose de som inte kan använda en mus eller styrplatta, utan många människor använder det för att snabba på sina aktiviteter, framför allt i formulär. Det tillåter också att man enkelt kan integrera ytterligare mjukvara eller hårdvara som kan simulera kombinationer av knapptryckningar, för att förenkla eller effektivisera navigering.

Nivå A

Kriterierna i WCAG om åtkomst via tangentbord säger så här:

• 2.1.1 All funktionalitet i innehållet går att kontrollera med ett tangentbord utan krav på specifik tajming av enstaka knapptryckningar. För att uppnå nivå AAA har denna regel inga undantag. Det enda undantaget som finns för nivå A är om det krävs en speciell rörelse som följer en viss bana (som att signera sitt namn). Det finns ingen nivå AA för denna riktlinje.

Nivå A (den lägsta nivån) innehåller även följande grundläggande krav:

• 2.1.2 Ingen tangentbordsfälla: Om fokus kan förflyttas till en komponent på sidan med tangentbordet så kan fokus också förflyttas från den komponenten, och, om det kräver mer än pilar, tab-tangenter eller andra standardiserade exit-metoder, så förklaras för användaren hur han/hon ska göra.

Här tycker jag tyvärr att författarna av WCAG gör det lite för lätt för sig eftersom det inte finns en specifikation av vad som är ett standardiserat sätt att förflytta fokus från en komponent på sidan.

Faktum är dock att den som använder sig av standardiserad HTML-kod sällan behöver bekymra sig om denna riktlinje som säger att allt ska vara åtkomligt via tangentbordet, eftersom vanliga länkar och formulärfält alltid är det. Det fungerar som så att användaren använder tab-tangenten för att förflytta sig framåt i sidan mellan klickbara och ifyllningsbara element. Med det sagt är det viktigt att ändå alltid kontrollera att sidan har den förväntade strukturen, eftersom absolut positionering och ”flytande” element kan innebära att ordningen i sidan inte är den du visuellt ser framför dig.

För A-nivån finns nu även sedan version 2.1 detta kriterium (som tyvärr gör att numreringen av detta och nästa kriterium blir omkastade).

• 2.1.4 Version 2.1 Genvägar med teckentangenter. Om en tangentbords-genväg har implementerats med endast bokstav (gemen eller versal), siffra eller symboltecken så är minst en av dessa kriterier uppfyllda:
  • Avstängning. Det finns möjlighet att stänga av genvägen.
  • Om-mappning. Det finns möjlighet att mappa om genvägen så att den använder en eller flera icke-skrivbara tecken (exempelvis: Ctrl, Alt, och så vidare).
  • Endast aktiv vid fokus. Genvägen för en komponent är endast aktiv när den komponenten har fokus.

Nivå AAA

För den högsta nivån av uppfyllnad av riktlinje 2.1 gäller även:

• 2.1.3 Det finns inga undantag när det gäller att all funktionalitet måste gå att styra med hjälpa av tangentbordet utan krav på särskild tid under, eller mellan, tangent-tryckningarna.

Vanliga fallgropar

De vanligaste problemen när det gäller att tillåta navigering via tangentbordet är när vi har interaktiva element i sidan som uppför sig lite oförskämt.

• Lightbox / Modala fönster – En lightbox är ett virtuellt fönster som öppnar sig så att det visuellt ligger ovanför det övriga innehållet och presenterar helt nytt innehåll, vare sig det är en bild, formulär, text eller audiovisuellt innehåll. Det viktiga att tillgodose är (1) att tab-ordningen (förflyttandet i sidan med tab-tangenten) sker i rätt ordning inuti denna lightbox, (2) att det inte går att tabba sig utanför rutan utan att först stänga den och (3) att det enkelt går att stänga rutan, företrädesvis med Esc-tangenten, eller annars med en tydligt markerad länk inuti rutan.
• Kalender – Om du har inmatning av datum och en så kallad popup-kalender för att lätt välja i en kalender så måste det gå att navigera i kalendern med tangentbordet och förstå vilken dag det är man väljer. Ett annat sätt är att inte tillåta öppning av popup-kalendern via tangentbordet (göra den osynlig för tangentbordet, vilket alltså är möjligt) och ändå tillgodose behovet av att mata in datum genom att tillåta det via vanlig nummerinmatning.
• Video – Om det går att tabba sig till en video och starta den så måste det också gå att kontrollera uppspelningen av den via tangentbordet, samt lämna och gå vidare från videon.
• Oönskade fokusförflyttningar – Det är inte ofta jag stöter på det men det händer att någon välvilligt implementerar formulär där markören flyttar sig från ett fält till ett annat utan att användaren begärt det. Ett typiskt exempel är inmatning av kreditkortsnummer där man delat upp det hela i 4 fält, och markören hoppar vidare så fort man skrivit in 4 siffror i ett fält. Tyvärr skapar detta en hel del förvirring och gör det dessutom svårt att korrigera när man skrivit fel. Ett gränssnitt ska inte på eget bevåg göra saker som användaren inte bett om.
• Kreativa formulär – Det finns en mängd varianter av kreativa formulär, där så kallade ”sliders” blivit populära, där man alltså drar en markör längs en mätare för att indikera längd, vikt eller annat mått. Dessa måste också gå att kontrollera via tangentbordet, ibland genom att komplettera med ett inmatningsformulär. En annan variant är kartor som används för att markera orter; på samma sätt så måste det gå att välja orter via tangentbordet och inte bara med musen.

Ju mer kreativ du blir desto mer utmanande blir det alltså att uppfylla denna riktlinje. Det bästa sättet att arbeta är genom progressive enhancement, vilket kan översättas med gradvisa förbättringar. Utgå från det enkla, standardiserade sättet till att börja med, och lägg sedan till funktionalitet som skapar mer lustfylldhet och visuellt stöd. Målet är att det alltid ska fungera nästan oavsett hur föråldrad webbläsare någon kan tänkas ha.

Och du, det är väldigt lätt att testa, släpp musen en stund och försök göra allt på sidan med hjälp av tangentbordet. Det är enkelt testmoment som hjälper dig att skapa framtidssäkra, effektiva och tillgängliga webbplatser.

2.2 Tillräckligt med tid

Skynda långsamt

Vi har alla varit med om det. Vi skriver in något på en webbsida, det tar lite extra tid för att det är krångligt eller för att du blir avbruten, och när du klickar på skicka så händer det: du har blivit utloggad på grund av inaktivitet. Allt du skrev är borta.

"Tillräckligt med tid" i WCAG handlar om att ge användaren tid på sig att läsa och använda innehåll. Och om du till exempel har en tidsgräns så måste du i god tid innan den löper ut uppmärksamma användaren om att tiden snart löper ut och i bästa fall ge möjlighet att förlänga tiden.

Nivå A

• 2.2.1 Justerbara tidsgränser.

  Kriteriet, inom ramen för WCAG:s nivå A, innebär att för varje aktivitet där det finns någon form av tidsgräns så ska webbplatsen alltid tillgodose en av dessa kriterier:

  • Avstängning: det ska gå att stänga av tidsgränsen
  • Justering: användaren kan justera tidsgränsen innan hon stöter på den, med möjlighet att förlänga till minst tio gånger längre än utgångsvärdet
  • Förlängning: Användaren varnas innan tiden går ut och har 20 sekunder på sig att förlänga tiden med en enkel interaktion, exempelvis genom att trycka på en specifik knapp på tangentbordet.

  Tillåtna undantag för denna regel är:

  • Realtid: Om tidsgränsen är på plats på grund av något som sker i realtid, exempelvis en auktion, och det inte finns något alternativ till tidsgränsen
  • Nödvändig: Tidsgränsen är nödvändig och att förlänga den skulle göra aktiviteten ogiltig, exempelvis vid ett prov.
  • 20 timmar: Om tidsgränsen är längre än 20 timmar.
• 2.2.2 Pausa, Stoppa, Dölj. Inom nivå A tas också hänsyn till information som när sidan laddas rör på sig, blinkar eller uppdateras automatiskt i mer än fem sekunder. För att alla besökare oavsett förmåga ska få skälig tid på sig gäller att:
  • Det ska gå att pausa, stoppa eller gömma innehållet; så länge inte rörelserna och blinkandet är nödvändiga delar för att förmedla information.

En hjälp för alla

Det här är återigen en regel som visar hur ett efterlevande av tillgänglighetsprinciper ger fördelar för alla användare, oavsett om det finns tydliga funktionsnedsättningar eller inte.

Vi är alla hjälpta av att känna att vi har kontroll över den information som visas, och ska inte i onödan behöva lida av tidsgränser och rörlig information på ett sätt som skapar förvirring, gör att vi går miste om information eller förlorar data.

Ytterligare regler

Nivå AAA

För "Tillräckligt med tid" finns endast nivå A och AAA. För att ta sig till nivå AAA gäller även ett uppfyllande av dessa kriterier:

• 2.2.3 Rätt tajming är inte en nödvändig del av aktiviteten som presenteras av innehållet (utom för realtidshändelser).
• 2.2.4 Användaren blir inte avbruten, eller kan senarelägga avbrott, såvida dessa inte är en del av en nödsituation.
• 2.2.5 Åter-autentisering. Om en autentiserad session går ut så kan användaren fortsätta aktiviteten utan dataförlust när hon autentiseras igen.
• 2.2.6 version 2.1 Användare varnas om tiden för inaktivitet kan orsaka förlust av data, om inte denna data vidhålls i mer än 20 timmar när användaren är inaktiv.

Rent praktiskt: varna, lyssna och spara

Jag ser väldigt få lösningar där jag varnas innan utloggning, men det är ett grundkrav för tillgänglighet. Se till att göra det. Och i samma andetag som man varnar för tidsgränser så måste man lyssna efter om användaren vill förlänga den givna tidsgränsen.

Till slut vill jag slå ett slag för att spara data automatiskt åt användaren. E-posttjänsten Gmail var en pionjär inom detta men alltför få har följt efter. Spara min information regelbundet utan att jag skickar formuläret (självklart med användarens goda minne); säkerställ att jag inte förlorar data vid förlorad uppkoppling, om jag råkar navigera från sidan eller om en tidsgräns löper ut.

Rent tekniskt: ARIA och ljud

Att varna på webben handlar ofta om att visa information ur sitt sammanhang. Det gäller att visa information (exempelvis i ett popup-fönster eller egen ruta) men också uppmärksamma om att det finns viktig information i ett nytt fönster, för de som inte kan se det.

För detta ändamål är det viktigt att läsa på om WAI-ARIA som ger stöd för att göra interaktiva applikationer mer tillgängliga, bland annat genom att göra det möjligt att definiera områden i sidan som får fokus under vissa omständigheter.

Förstås så har WAI-ARIA inte det breda stöd i alla webbläsare som vi alltid drömmer om, varför jag ibland också skulle rekommendera att programmatiskt spela upp ett ljud som ger relevant information till användaren. Att tiden löper ut är faktiskt relevant för alla.

Så länge du är medveten om behoven så litar jag på att du är rådig när det gäller att tillgodose dessa. Det viktiga är att verkligen ta behoven på allvar.

2.3 Anfall (epilepsi och liknande)

Skada inte andra

Det finns riktlinjer i WCAG:s rekommendationer för tillgänglighet som är lätta att leva upp till. De är så självklara att de tack och lov är väldigt sällsynta. Riktlinjen om medicinska "anfall" är en sådan: Publicera inte innehåll som skapar epilepsi-anfall.

Det som orsakar anfall är oftast flimmer och blixtliknande blinkningar med hög intensitet. Riktlinjen definierar detta kriterium i nivå A:

Nivå A

• 2.3.1 Inget på sidan blinkar mer än 3 gånger på en sekund.

Det betyder självklart inte att allt innehåll som blinkar snabbare än så triggar epilepsi-anfall, utan det är speciella typer av flimmer som oftast är boven. Det här ger en fingervisning som gör att man håller sig inom godkända gränser.

För nivå A, som generellt är lättare att uppnå, finns ett väldigt tekniskt undantag som handlar om storleken på den blinkande ytan och hur stor del av synfältet det tar upp. Förhoppningsvis ska du inte ens vara i riskzonen för att bidra till detta.

För en högre grad av uppfyllnad av kriterierna i 2.3 gäller:

• 2.3.2 Regeln "Inget på sidan blinkar mer än 3 gånger på en sekund" vidhålls överallt och alltid.
• 2.3.3 version 2.1 Animeringar som aktiveras av interaktion kan inaktiveras, om inte animationen är av vikt för funktionalitet eller information som förmedlas.

Viktigt om användargenererat innehåll

Det finns rapporter om att användare i sociala medier skickar blinkande bilder via direkmeddelanden till personer med epilepsi och i vissa fall har satt igång livshotande anfall. Om du har en tjänst där användare interagerar med andra användare så blir denna regel plötsligt oerhört viktig. Det måste finnas mekanismer för sårbara användare att helt kunna undvika animationer som potentiellt kan skada dem.

Så, nu har du en riktlinje som du bör kunna leva upp till rakt av i alla dina lösningar, även på nivå AAA. Låt inte din lösning trigga epilepsi-anfall. Punkt.

2.4 Lättnavigerad

Var är jag?

Tänk dig att du vaknar upp på en okänd plats. Hur orienterar du dig så att du förstår var du befinner dig? Vägskyltar, gatunamn, kända intressepunkter? Åt vilket håll går du? Tänk dig nu att du har kognitiva fuktionsnedsättningar som påverkar ditt närminne, eller har grava synnedsättningar. Tänk dig att du råkar hamna på en okänd webbplats. Hur vet du var du är?

Att hela tiden erbjuda tydlig, kontextuell information om den aktuella webbsidans placering i en hierarki, samt vara lika tydlig med hierarkin inom sidan uppnår du flera mål:

• Användarna känner att de har mer kontroll över situationen
• De känner sig inte lika osäkra på var de ska härnäst
• De kan snabbt orientera sig vid behov, oavsett hur ofta det behovet uppstår

"Lättnavigerad" handlar om att snabbt kunna orientera sig på en sida och få tydligt stöd för att förstå var man är.

För denna riktlinje finns alla tre nivåer av uppfyllnadsgrad för WCAG, och de kan sammanfattas så här:

Nivå A

• 2.4.1 Hoppa över block. För den som använt en skärmläsare så blir det snabbt ganska tydligt att man inte vill lyssna på menyn varje gång man går in på en sida. Ibland vill man bara scanna innehåll också. Då är det viktigt att det är tydligt och lätt hur man hoppar över navigeringen, kommer direkt till innehållet och hoppar mellan rubriker. Observera att det inte nödvändigtvis handlar om en ”Hoppa över innehållet”-länk, det kan också vara namngivna sektioner eller helt enkelt tydliga rubriker på varje sida. Bara det är uppenbart hur man hoppar dit.
• 2.4.2 Tydlig titel. Med detta menas inte rubriken på sidan utan det som står i title-taggen på sidan. Det är denna som läses upp först av text- och skärmläsare, som blir synlig i Google och som ofta har ett snabbkommando för att man snabbt ska ”komma ihåg” vilken sida man är på. Många väljer att ha samma title som den synliga rubriken på sidan, men tänk på att texten ska förklara syftet eller innehållet på sidan mycket tydligt.
• 2.4.3 Fokus-ordning. om en webbsida kan navigeras sekventiellt och ordningen på hur länkarna aktiveras påverkar betydelsen eller styrförmågan, så måste alla element som kan få fokus aktiveras den ordning som vidhåller betydelse (mening) och kontroll.
• 2.4.4 Länksyfte (kontext). Länktexten ska vara beskrivande och det ska gå att förstå vart den leder enbart baserat på länktexten eller i kombination med dess programmatiska sammanhang. Bland det vanligaste, och tyvärr inte tydligt avrått i specifikationen, är att komplettera länken med ett title-attribut. Här krockar gängse åtgärd med verkligheten eftersom skärmläsare generellt är dåliga på att läsa upp det attributet på ett konsekvent sätt, och det kan bli en källa till många olika typer av störningar. Det du bör göra är säkerställa att länktexten kan stå för sig själv (se nivå AAA) på ett sätt så att alla som tar del av texten blir hjälpta i sitt beslut om att följa länken eller inte. Läs gärna blogginlägget Title Texts Suck, av Hampus Sethfors på Axess Lab, för en genomgång av alla problem med title-attributet i samband med länkar.

Nivå AA

• 2.4.5 Sajtkarta (och/eller sökmotor). Det ska gå att nå sidan på flera sätt än bara via vanlig navigering. Ett vanligt sätt att åstadkomma detta på är att erbjuda en sajtkarta, som ofta ger duktiga användare ett snabbt sätt att nå allt innehåll. Alternativt kan en sökmotor också sägas uppfylla kravet. Bara det finns mer än ett sätt, som sagt.
• 2.4.6 Rubriker + etiketter. Rubriker och etiketter i formulär ska tydligt beskriva ämne eller syfte. Tolka gärna detta som att det handlar om rubriker för funktionella element i sidan. En fyndig mellanrubrik i löptext är alltid välkommen.
• 2.4.7 Synligt fokus. När man använder tab-tangenten för att ta sig fram i sidan, eller med hjälp av andra verktyg som motsvarar navigering via tangentbord, så ska det vara tydligt vilket element som just nu har fokus. En svagt ljusgrå streckad ram räcker alltså inte, utan det bör vara en ram eller bakgrund med hög kontrast som visar var fokus är just nu.

Nivå AAA

• 2.4.8 Var är jag? Jag ska förstå var i webbplatsens hierarki jag befinner mig just nu. Det här går att åstadkomma med så kallade brödsmulor (länkar som beskriver den hierarkiska sökvägen till sidan), med en lättåtkomlig sajtkarta, eller genom att tydligt markera i menyerna vilka som är de aktuella sidorna. Observera att det inte räcker med att måla flikar eller länkar i en annan färg, de måste också programmatiskt innehålla information om att de är de aktuella rubrikerna i menyn – genom exempelvis alternativ text. W3C själva verkar tycka att det kan räcka med att inaktivera länken om du är på den sidan, men jag är faktiskt personligen skeptisk till det.
• 2.4.9 Länksyfte (endast länk). Om länken är det enda jag kan läsa på sidan så ska jag förstå vart den leder. Inga undantag.
• 2.4.10 Avsnittsrubriker. Vi har varit inne på det förut: en tydlig struktur i sidan med hjälp av elementen h1, h2 och h3 hjälper alla användare, och sökmotorer, att förstå hur olika delar i sidan förhåller sig till varandra. Det går också snabbt att hoppa mellan sektioner i sidan.

Nog borde du uppfylla alla rekommendationer i riktlinje "Lättnavigerad", även den högsta nivån AAA? Fall inte för frestelsen att göra en generalisering om att följa nivå AA för alla riktlinjer, se till att du vet när du också kan nå nivå AAA.

Nästa gång någon trillar in långt ner i din webb via en tursam sökning i en sökmotor eller en rekommenderad länk, hjälp dem på fötter genom att anslå tydliga vägvisare. Då minimerar du också risken att de lägger benen på ryggen och flyr tjänsten illa kvickt.

2.5 Peka och markera

Ett varningens finger

"Peka och markera" är en helt ny riktlinje i och med version 2.1 av WCAG. Den adresserar en del av det som saknats i form av kriterier för mobila gränssnitt när det gäller hur vi interagerar med pekskärmar.

Nivå A

• 2.5.1 Version 2.1 Gester. All funktionalitet som använder "flerpunktsgester", eller spårbundna gester, för att kunna styras tillåts också styras med en enskild markör utan spårbundna gester, såvida det inte är väsentligt. På läsplattor kan man ibland få möjlighet att aktivera innehåll med tre fingrar som dras i en viss riktning, eller zooma med två fingrar. Det här kriteriet innebär alltså att man även ska kunna nå samma innehåll och funktionalitet med endast ett finger, och/eller en färdväg som innebär att man aktiverar enskilda "klick" i taget. Tänk på att ett finger också kan inbegripa dubbel-klick och "hålla länge".
• 2.5.2 Version 2.1 Markör-annulering. För funktionalitet som styrs med en enskild markör (exempel: finger, musmarkör eller röstmarkör) är minst en av följande uppfyllda:
  • Ingen "ner"-händelse (down-event). Att enbart trycka ner med markören används inte för att aktivera någon del av funktionen.
  • Avbryt eller ångra. Aktivering av funktionen sker vid "upp"-händelsen (up-event) och det finns då möjlighet att avbryta funktionen innan den slutförs eller ångra funktionen efter att den körts.
  • Upphävning. "Upp-händelsen" återställer helt "ner-händelsens" effekt.
  • Nödvändigt. Att aktivera och slutföra funktionen på "ner-händelsen" är helt nördvändigt.
• 2.5.3 Version 2.1 Etikett i namnet. För komponenter på sidan med etiketter som inkluderar text, eller bilder av text, måste namnet innehålla samma text som presenteras visuellt. Det innebär till exempel att de som använder röststyrning kan säga namnet på etiketten för att aktivera en knapp. En komponent, som en knapp, kan ha en programmatisk etikett och användare får förstås betydligt lättare att navigera om den etiketten matchar det som faktiskt står på knappen.
• 2.5.4 Version 2.1 Rörelse-aktivering. Funktionalitet som styrs med enhetens rörelser eller användarens rörelser kan också styras med komponenter i gränssnittet; och rörelse-styrning kan inaktiveras för att undvika oavsiktlig aktivering, förutom när:
  • Gränssnittet är specifikt framtaget för en tillgänglighets-funktion. Rörelsen används för att styra funktionalitet genom ett gränssnitt som är skapat för att stödja tillgänglighet.
  • Det är nödvändigt. Rörelsen är nödvändig för funktionen och inaktivering skulle upphäva aktiviteten.

Nivå AAA

• 2.5.5 Version 2.1 Klickyta. Storleken på ytan som ska aktiveras av markören är minst 44 gånger 44 CSS-pixlar förutom när:
  • Ekvivalent alternativ finns. Ytan/länken finns även på annan plats på samma sida, och är där minst 44x44 CSS-pixlar i storlek.
  • Inline gäller. Ytan är inom en mening eller ett textblock (ofta en länkad text).
  • Webbläsaren kontrollerar. Ytans storlek kontrolleras av webbläsaren och kan inte ändras av utvecklaren.
  • Den är nödvändig. Presentationen som den ser ut är nödvändig för informationen som förmedlas.
• 2.5.6 Version 2.1 Samtidiga verktyg för styrning och inmatning. Innehållet begränsar inte vilken typ av verktyg för att styra gränssnittet som kan användas på plattformen, om inte restriktionen är nödvändig för att säkerställa innehållets säkerhet eller för att respektera användarens inställningar.

3.1 Läsvänlig för skärmläsare (och människor)

Vårda ditt språk

En dator som läser svenska texter på amerikanska, eller tvärtom, kan göra ont i öronen. En dator som läser KBM (Krisberedskapsmyndigheten) som "kubikmeter", eller datorföretaget HP som "horsepower" skapar förvirring. Ovanliga förkortningar utan förklaringar är irriterande. Hur mycket informationsbrus skapar din sida?

När vi hjälper skärmläsare och stödteknik att tolka och läsa upp innehållet i sidan så hjälper vi förstås också fler människor att bättre förstå. Flera av dessa regler kan kännas tekniska men det gör dem faktiskt ofta lättare att efterleva.

Nivå A

• 3.1.1 Språket är definierat för hela sidan.

Japp, svårare än så är inte denna lägsta nivå! Man måste verkligen undra varför så många missar det.

För den här sidan har det svenska språket definierats så här:

<html lang="sv">

Nivå AA

• 3.1.2 Enskilda stycken och ord på ett annat språk, än det som definierats för hela sidan, är definierade som varandes på det språket.

Det låter så enkelt men ytterst få tycks klara av att ange språk. Tyvärr tror jag att det kan hänga ihop med att många publiceringsverktyg inte har stöd för det.

Så här kan det se ut:

På engelska kallas tillgänglighet för <span lang="en">accessibility</span>.

Med denna kod blir ordet accessibility uppläst med engelskt uttal och resten med svenskt uttal. Även sökmotorer förstår bättre hur de ska kategorisera ordet för den som söker efter det.

Gör detta enkla så fixar du nivå AA i denna rekommendation, vilket de flesta sajter faktiskt i något bortglömt dokument eftersträvar.

Nivå AAA

Nu kanske det börjar kännas lite krångligare. Men häng på, för några är görbara för det flesta, och det är något jag verkligen försöker vara övertydlig med: bara för att du inte klarar alla på nivå AAA, betyder ju inte att du ska ignorera de du faktiskt klarar av att tillgodose!

• 3.1.3 Ovanliga ord och fraser ska kompletteras med en definitionslista som förklarar begreppet, det ger förbättringar både för sökmotoroptimering och för människor med svenska som andraspråk samt med kognitiva funktionsnedsättningar.
• 3.1.4 Förkortningar ska förklaras. Det finns HTML-attribut som hjälper med detta för skärmläsare, men de bör även skrivas ut i klartext, så att alla kan ta del av förkortningens betydelse. Gör som papperstidningarna, första gången förkortningen används så skriver du ut hela förklaringen.
• 3.1.5 En version av texten som inte kräver en läskunskapsnivå högre än mellanstadiet kompletterar den vanliga texten, såvida inte ursprungstexten själv uppfyller detta. » Fördjupningsinfo om läsnivå
• 3.1.6 Uttal av ord är specificerat när betydelsen kan bli tvetydig. Det kan göras på flera sätt: Länka till fonetiskt uttal, skriv detsamma i parentes, eller länka till en ljudfil.

För dig som undrar hur KBM ska bli läst som Krisberedskapsmyndigheten, så ska koden se ut så här:

<abbr title="Krisberedskapsmyndigheten">KBM</abbr>

Fördelarna

En del människor har svårigheter med att tolka skriftliga texter men har tycker det är lättare att förstå dokument när de läses högt, eller när nyckelpunkter illustreras med bilder eller tolkas med teckenspråk. För en del personer är förståelsen avhängigt om det finns tillgång till specifika definitioner av specialiserade begrepp och förkortningar.

Avsaknad av språkinformation och uttalsinformation, och även textens läsriktning när det är relevant, kan orsaka enorma barriärer för många människor. Behöver jag nämna att något så enkelt som stavfel kan ställa till med en hel del förvirring också?

Och som du märker, om du inte klarar nivå AA av denna riktlinje, då anstränger du dig knappt.

Fler tips från W3C för att göra text lättläst och lättförståelig.

3.2 Förutsägbar

Infria förväntningar

Tänk dig att du sitter på bussen och din hållplats närmar sig. Du trycker på stopp-knappen och vips så har bussen blivit mindre och hoppat till en parallellgata. Om du är en miljöskadad webbdesigner tänker du: "Oj, någon har lekt lite för mycket med Javascript!"

Riktlinjen "Förutsägbar" handlar om att inte göra förändringar i miljö och sammanhang utan att först förbereda användaren på det.

Webbsidor ska se ut och uppföra sig på ett förutsägbart sätt. Denna riktlinje nämner en hel del om att undvika kontextförändringar som användaren inte är beredd på. Enkelt uttryckt handlar en kontextförändring om något som förändrar webbläsaren, dess viewport (den synliga ytan i webbläsaren), fokus i sidan eller ändrar innehåll som påverkar budskapet i sidan.

Exempel på kontextförändringar är:

• nya fönster,
• förflyttning av fokus till ett annat element,
• hopp till en ny sida (även om det för användare bara "ser ut" som att de bytt sida),
• eller att ”möblera om” innehåll på sidan så att det hamnar i en annan ordning.

Här är de tre nivåerna att förhålla sig till:

Nivå A

• 3.2.1 Vid fokus. När ett element på sidan får fokus (länk, knapp eller annat), så triggar inte den en kontextförändring. Observera att det handlar om fokus; ett klick är något annat.
• 3.2.2 Vid inmatning. Förändring av inställningar för en komponent i sidan orsakar inte en kontextförändring.

Exempel: Jag har sett inmatningsfält för kreditkortsnummer där användarens markör för inmatning automatiskt hoppar från ett fält till annat när 4 siffror är inmatade. Det är exempel på en otillåten kontextförändring.

Nivå AA

• 3.2.3 Konsekvent navigering. Om du har en meny eller för all del en sidfot med länkar som återkommer på många sidor, så ska inte de inbördes länkarna byta ordning från sida till sida.
• 3.2.4 Konsekvent identifiering. Komponenter som har samma funktionalitet inom en grupp webbsidor har identifierats på ett konsekvent sätt, oftast med samma namn.

Exempel: Textalternativ för dokumentikoner, om de används för att länka till dokument, börjar alltid med samma ord (ladda ner) och på samma sätt så har pilar längst ner på olika sidor samma textalternativ om de alltid används för att hänvisa vidare till en annan sida (gå till sida x). Om du har en sök-ruta med liknande funktionalitet på två olika sidor, men i ena fallet heter sök-knappen ”sök” och i andra fallet ”hitta”, då gör du alltså fel.

Nivå AAA

• 3.2.5 Förändringar på begäran. Kontextförändringar sker endast på användarens begäran eller så finns möjlighet att stänga av sådana förändringar.

Det här adresserar till exempel beteendet att öppna i nytt fönster eller i en ny flik. Om du gör rätt så ska sådana beteenden ske endast på begäran, eller så ska användaren kunna stänga av det. Om man har dålig syn eller kognitiva besvär är det inte alltid uppenbart varför inte bakåt-knappen funkar som den ska.

Andra exempel på kontextförändringar jag inte bett om är skickandet av formulär när jag kryssar en checkruta. Jag har sett liknande sådana tillämpningar i enkäter. Sluta med det.

Fortfarande kvar på bussen?

Tillbaka till bussen. Lustigt nog säger inte den här riktlinjen om förutsägbarhet så mycket om att klicka. Om man klickar så ska ju helst både bussen och knappen fortsätta bete sig på ett förutsägbart sätt. Det som avgör vad som är förutsägbart är förstås alltid de förväntningar du satt. Det är omhändertagande att vara tydlig med vad som händer vid specifika aktiviteter.

Men om busschauffören heter Joe Labero (en känd illusionist), ja då är kanske dina förväntningar helt i linje med aktuella skeenden. De flesta användare förväntar sig dock inte att bli lurade.

3.3 Inmatningshjälp

Vänta så menade jag inte!

Ibland hävdar jag att hyperlänkar är det magiska med Internet. Men den starkaste kraften vågar jag ändå påstå är möjligheten som öppnas upp för världsomspännande kommunikation. Vi har fått möjlighet att prata, dela med oss, skicka in, kollaborera, anmäla, betala, och begära alldeles oavsett fysiska gränser eller avstånd. Det finns dock ingen kommunikation som inte kan missförstås, och det blir etter värre om vi inte ens förstår hur vi ska mata in vår information digitalt.

"Inmatningshjälp" handlar om hur vi hjälper människor att göra rätt när de ska bidra med information, men också hur vi hjälper dem när de gör misstag.

Även denna riktlinje har rekommendationer för alla tre nivåer.

Nivå A

• 3.3.1 Om information matas in på ett felaktigt sätt så identifieras felet och beskrivs i text.
• 3.3.2 Etiketter och instruktioner tillhandahålls när information efterfrågas.

Det låter enkelt men även här görs många misstag. För det första räcker det alltså inte med att markera med en röd ram (som jag ofta ser) där man gjort fel, utan vad som är fel måste beskrivas. Det måste redan innan också finnas instruktioner för hur man gör rätt och det måste finnas en etikett för inmatningsfältet.

Förvånansvärt många utvecklare vet inte hur man bygger formulär på ett strukturerat sätt och ett av misstagen handlar om att man inte anger etiketten semantiskt i koden.

Så här ska det se ut när man anger etikett rätt för ett textfält, notera att label pekar ut det id på inmatningsfältet som etiketten gäller:

<label for="personnr">Skriv personnummer (10 siffror)</label>
<input type="text" id="personnr" name="personnummer">

Det blir då tydligt vilken etikett som tillhör vilket inmatningsfält. Dels kommer etiketten (rubriken) bli klickbar för att textfältet ska få fokus, men det blir också så att om man befinner sig i inmatningsfältet kan man snabbt få instruktionerna upplästa om man använder en skärmläsare.

Personer som använder verktyg för att fylla i formulär automatiskt gynnas också. När en etikett ofta återkommer så kommer dessa verktyg kunna föreslå vilket innehåll som ska matas in, baserat på det som användaren matat in tidigare i fält med liknande etikett.

Exempel på formulär och felmeddelande:

Nivå AA

• 3.3.3 Om ett fel i inmatad information upptäcks och det finns kända förslag för att rätta felet, så visas dessa förslag. Undantaget är om eventuella förslag skulle innebära en säkerhetsrisk (som att tala om hur många tecken ett lösenord ska innehålla) eller förstöra syftet med innehållet (som vid ett prov).
• 3.3.4 När en webbsida innefattar juridiska eller finansiella transaktioner – som förändrar eller raderar information som en person använder – måste en av följande kriterier vara uppfyllda:
  • Reversibel. Personen kan ångra och ta tillbaka sitt inskick.
  • Kontrollerad. Information som matas in kontrolleras för felaktiga inmatningar och användaren får möjlighet att rätta dessa.
  • Bekräftad. Det finns en tydlig möjlighet att läsa igenom, bekräfta och rätta information innan det slutgiltiga inskicket.

Nivå AAA

• 3.3.5 Kontextuell hjälp erbjuds. Med kontextuell hjälp menas att man erbjuder ytterligare hjälptexter när etiketten inte alltid räcker för att helt förstå det som man förväntas skriva eller mata in.
• 3.3.6 När information efterfrågas så måste en av kriterierna Reversibel, Kontrollerad eller Bekräftad vara uppfylld oavsett information som hanteras. Se punkt 3.3.4 under nivå AA där kriterierna förklaras.

Även denna riktlinje kring inmatningshjälp är för mig exempel på en sådan riktlinje där det finns alla skäl och möjligheter att uppnå den högsta graden, nivå AAA, utan att det blir resurskrävande. Att erbjuda hjälp hela vägen gynnar verkligen alla parter, inte minst de som faktiskt ska ta emot informationen!

Lägg komplexiteten på rätt ställe

Det är också en riktlinje som för mig inte blir heltäckande, då den talar väldigt mycket om tydlighet och felhantering, men inte tar upp det som ligger mig varmt om hjärtat: en hantering av komplexitet.

Det är ingen slump att jag använder personnummer som exempel ovan. Det är ett bra exempel även för att illustrera hur utvecklare bör eftersträva att ta emot information i olika format, även om den i slutändan ska sparas ner enligt en fördefinierad formattering.

Det är min övertygelse att det inte ska spela någon roll för en lösning vilket av dessa format som en användare matar in sitt personnummer i:

• 820620-1234
• 8206201234
• 19820620-1234
• 198206201234

Alltså: även om vi ger användaren en tydlig instruktion kring ett av dessa format för personnummer, så ska vi inte slänga upp ett felmeddelande om användaren skriver något av de tre andra formaten. Så länge vi är trygga med vad användaren menar, så kan vi ta ansvar för att formattera om och spara ner informationen i det format vi själva vill.

Det är detta jag menar med att lägga komplexitet på rätt ställe. En dator formatterar om en uppgift som personnummer mycket snabbare än en människa.

Även här finns förvisso undantag, då det blir allt vanligare att människor lever mer än hundra år. Jag känner mig ändå trygg i förvissningen om att tjänster ska klara av att hantera detta på ett bra sätt om de misstänker att 3-åringar försöker logga in med bank-id.

Tips! I sammanhanget kan det vara rimligt att läsa på om Privacy by design och fundera över hur man ska förhålla sig till vilka uppgifter man efterfrågar och hur man hanterar dem.

4.1 Kompatibilitet

Gör rätt från början

Jag har nämnt tidigare hur det här området - Robust - med endast en riktlinje (Kompatibilitet) och två kriterier på Nivå A, nästan är så tydlig som den kan vara redan i rubriksättning. Bygg enligt standarder och säkerställ att din lösning är kompatibel med alla typer av webbläsare.

Låt oss ändå titta på de två kriterierna:

Nivå A

• 4.1.1 I allt innehåll som implementeras med markup-språk (alltså HTML), så ska element ha fullständiga start- och slut-taggar, de ska vara hierarkiskt strukturerade enligt sina specifikation, det ska inte finnas dubletter och alla ID:n ska ara unika, förutom när specifikationerna tillåter dessa egenskaper.
• 4.1.2 För alla komponenter i ett användargränssnitt (inklusive men inte begränsat till: formulär-element, länkar och komponenter som genereras av skript), så kan namn och roll utläsas programmatiskt; inställningar, egenskaper och värden som kan bestämmas av användaren kan ställas in programmatiskt; och notifieringar om förändringar finns tillgängliga för webbläsare, inklusive assisterande teknik.

Nivåa AA

För robust finns ett nytt kriterium i version 2.1

• 4.1.3 version 2.1 Statusmeddelanden. I innehåll som implementerats med markup-språk (HTML) kan statusmeddelanden tolkas programmatiskt genom role eller egenskaper, så att de kan presenteras för användaren med hjälp av assisterande teknik utan att få fokus.

Tydligheten till trots så blir det ju tyvärr ofta fel och det är nog felkällorna som vi bör fokusera på så att vi kan minimera skapandet av lösningar som bidrar till en sämre webb.

Varför så många inte bygger rätt

• Utbildningarna är bristfälliga. Kurser och utbildningsprogram för webbutvecklare innehåller alldeles för lite kunskap om specifikationer generellt och tillgänglighet i synnerhet. Vi har alltså tusentals webbutvecklare som tar examen varje år med bristande förmågor inom dessa områden. Resultatet blir skapandet av webbtjänster som då av naturliga skäl inte lever upp till vad som kan definieras som kompatibel och tillgänglig webb.
• Webbägare är ovetande om inkluderande design. Okunskapen sträcker sig förstås ofta hela vägen genom projekt även till de som beställer och förvaltar digitala tjänster. Om man inte tidigt mäter och utvärderar kompatibilitet, och hur man gör det möjligt för fler människor att använda en tjänst, så sitter man snart med en stor härva av otillgängliga lösningar.
• Otestad extern kod. Många utvecklare vill gärna arbeta mer effektivt och med den senaste tekniken; inte sällan vänder man sig då till färdig kod och färdiga bibliotek från webben. Tyvärr gås denna externa kod sällan igenom för att säkerställa att den uppfyller WCAG:s riktlinjer och kriterier. Resultatet blir att man sitter med flera olika bibliotek där utvecklare har dålig insyn och ingen känner personligt ansvar för koden; samtidigt som alla dessa kan vara bidragande till att många människor inte kan använda en tjänst.
• Orimliga kravställningar på tid. Det ställs ofta orimliga krav på att lösningar ska hinnas klart inom en viss tid och på ett sätt som lever upp till en ogrundad föreställning om modern, interaktiv webb. Tidspress är en stor källa till dåliga beslut, och därför ett stort skäl till att det blir fel. Om färdigställande i tid gör kunden mer nöjd än hög kvalitet - speciellt när kunden inte kan se skillnad - så kommer också hastighet alltid vinna över god design.
• Konkurrens i form av tid och pris. Eftersom det ofta går att bygga undermåliga lösningar snabbare och billigare än inkluderande lösningar så kommer undermåliga lösningar fortsätta att vinna många upphandlingar. Undermåliga lösningar kan på ytan se ut precis som en välkonstruerad lösning, men när beställare och webbägare inte har förståelse för hur man inkluderar fler männniskor på webben så kommer tjänster byggas och lanseras utan att denna aspekt följs upp på ett rimligt sätt. Det funkar precis på samma sätt som byggfusk i fastighetsbranschen.
• Publiceringsverktygen stjälper mer än de hjälper. Om man sitter som innehållsansvarig för en större webbplats så har man också ett löpande redaktionellt ansvar för att leva upp till WCAG, till exempel när det gäller textalternativ och språk. Trots att WCAG 2.0 har funnits sedan 2008 så klarar många etablerade publiceringsverktyg fortfarande inte av att låta webbredaktörer på ett enkelt sätt ange språk för ett enskilt ord/stycke, eller skriva olika ALT-texter för bilder beroende av sammanhang.

Så vad blir lösningen på alla dessa problem? För att göra rätt måste vi satsa på kunskap och förmåga. Fler som ansvarar för digitala lösningar måste inse vad deras ansvar är gentemot alla människor som borde kunna använda tjänsten. När kunskapen finns kommer fler också föhoppningsvis förstå vad som krävs i form av tid för utveckling, och för löpande undersökningar och studier. Då kan vi hjälpas åt att ta fram utvecklingsstöd och verktyg som även har fokus på att bibehålla kvalitet, inte bara kapa tid.

Vi bygger digitala lösningar för människor. Det finns ingen rimlig anledning att satsa på att bygga för färre människor än vi har möjlighet till.

C. Dela och sprid

Den här e-boken vill få vingar

För att bidra till kunskapen om digital tillgänglighet får du gärna hjälpa mig sprida den här e-boken. Den är för alltid kostnadsfri och jag kommer bevara den här i HTML för att göra den så kompatibel som möjligt.

Länken att dela är https://axbom.se/digitill/. Om du vill länka direkt till en riktlinje, via en så kallad ankarlänk, så kan du kopiera länken till respektive riktlinje i tabell 1.

Återkoppling och förslag till förbättringar är alltid välkomna. Min avsikt är att hålla boken levande genom att uppdatera då och då med relevanta exempel. Säkert kan det ha smygit sig in några fel och då är jag bara tacksam om jag får information så att jag kan ändra det omgående.

axbom.se axbom.com Anlita Per

D. Checklista

Börja krypa innan du kan gå

Låt mig vara den första att säga det: en checklista kan aldrig ersätta ett systematiskt, kontinuerligt arbete med inkluderande design. Checklistan kan däremot ge dig ett snabbt sätt att bocka av det mest grundläggande, sådant som inte bör ha missats från början. Jag vill att du ska få mer tid över till att arbeta medvetet med att nå fler människor och ta hänsyn till olika typer av funktionshinder och funktionsvariationer.

Checklistan belyser också ett möjligt sätt tänka kring tillgänglighet i förhållande till WCAG: utvärdera varje sida och komponent, men alla riktlinjer är förstås inte relevanta för alla sidor. Använd dig av de relevanta kriterierna och gå igenom checklistan varje gång du publicerar nytt innehåll.

Kom alltid ihåg: tillgänglighet verifierar du på riktigt sedan med expertis, och med studier där du inkluderar människor med konkreta, upplevda funktionshinder.

Du kan också ladda ner checklistan på min utbildningsplattform: education.axbom.com

. Riktlinje Bedömning Checklista framtagen av Per Axbom, läs mer på axbom.se/digitill Enskilda element på en sida Det finns genomtänkta textalternativ för allt innehåll som inte är text. alt-text för bilder, texter som beskriver innehåll i video, och så vidare.   Om bilder inte är betydelsebärande så är alt-texten tom. Attributet måste dock finnas.   Bilder används inte för att representera enbart textinnehåll.   Samtliga element har tillräckligt hög kontrast (text, rubriker, knappar, bilder).   Färg används inte som enda sätt att urskilja eller särskilja visuellt innehåll. Enbart färg räcker till exempel alltså inte för att indikera länkar.   Instruktioner till användaren förlitar sig inte enbart på form, storlek eller visuell placering Detta är exempelvis fel: ”klicka på den fyrkantiga ikonen” eller ”läs instruktionerna i kolumnen till höger”.   Hela sidan Sidans titel (title) är logisk och intuitiv. Den ska gå att förstå utanför sitt sammanhang.   Det går att navigera med tab-tangenten från start till slut och samtliga länkar och trigger-områden (klickbara element/ytor) går att aktivera med tangentbordet, och de aktiveras i en logisk följd. Det är samtidigt visuellt tydligt vilken länk som är aktiverad.   Det finns en tydlig struktur i dokumentet. Det innebär bland annat att rubriknivåer h1-h5 används och innehållet kommer i en logisk följd, även i koden.   Det går, från sidans topp, att hoppa direkt till sidans huvudinnehåll. Syftet är att hoppa över header/meny för att undvika att de blir upplästa vid varje omladdning av webbtjänsten. En tydlig rubrik i koden kan räcka.   Länkar eller knappar med samma text som går till olika platser går direkt att särskilja.   Tabeller används för tabulär data. Tabeller används inte enbart för layout.   När ett element på sidan får fokus (inget klick) så förändras inte sidan på ett sätt som kan desorientera användaren. Det ska inte ske någon förändring av övrigt innehåll på sidan, det startar alltså inte en popup eller lightbox, tangentbordets fokus förändras inte, och så vidare.   Betydande fel i validering av HTML/XHTML undviks. Kan testas med http://validator.w3.org/   Formulär I formulär används rätt label för rätt element. Detta kan testas genom att klicka på rubriken vilket ska aktivera inmatningsfältet så att markören placeras där.   Obligatoriska formulärfält som kräver en viss längd, ett visst format eller ett visst värde upplyser om det inom etiketten (label) för det formulärfältet, eller om det inte finns en etikett så inom ”title”-attributet för fältet.   Om de används så presenteras felmeddelanden vid validering på ett effektivt, intuitivt och tillgängligt sätt. Felet är tydligt identifierat, det finns snabb access till elementet/fältet där felet återfinns och användaren kan lätt åtgärda felet och skicka om formuläret.   Det finns tillräckligt med etiketter, vägvisare och instruktioner för obligatoriska interaktiva element på sidan. Dessa kan vara i form av instruktioner, exempel, korrekt placerade fältetiketter och/eller användning av fieldset och legend.   Om ett inmatningsfel upptäcks, antingen via klientvalidering eller validering på servern, ges förslag som påvisar hur felet kan rättas till.   Media/rörlig grafik Det finns textalternativ som förklarar budskapet i eventuellt video/ljud.   Det finns stöd för att pausa, stoppa, tysta eller justera volymen för ljud som spelas i mer än 3 sekunder.   Innehåll som automatiskt blinkar eller rullar i perioder längre än 5 sekunder kan stoppas, pausas eller döljas av användaren.   Inget innehåll på sidan blinkar mer än 3 gånger per sekund såvida inte blinkandet är tillräckligt litet, med låg kontrast och inte har för mycket rött.   Automatisk utloggning och tidsgränser Om en sida har en tidsgräns så får användaren alltid möjlighet att förlänga, stänga av eller justera den tidsgränsen. Detta gäller inte för live-event (exempelvis en auktion) eller om tidsgränsen är mer än 20 timmar.  

E. Ordlista

Men vad betyder det?

Det är helt klart att en ordlista behövs. Som så ofta när det handlar om fackuttryck och teknik i beskrivning på svenska så blir det en salig blandning av både engelska och svenska och kryptiska koder.

Jag arbetar med ordlistan då och då när jag får tid över. Tipsa mig gärna om vilka ord och begrepp du vill se här, och bidra gärna med egna ordförklaringar.

• ARIA. En akronym för Accessible Rich Internet Applications. Det här är ett sätt att prata om webbsidor och webb-applikationer som är interaktiva - vilket nästan inbegriper de flesta digitala tjänster idag. Så fort du har en knapp eller länk så är förstås tjänsten interaktiv. Insikten om att strukturer och beteenden på webbsidor måste kommuniceras till digitala hjälpmedel har gett upphov till specifikationen WAI-ARIA, som är ett viktigt komplement till WCAG. Alla som utvecklar webbsidor bör ha god kännedom om både WCAG och WAI-ARIA.
• ATAG. En akronym för Authoring Tool Accessibility Guidelines. Författarverktyg (authoring tools) är tjänster eller program som används för att producera innehåll för webben. Det kan handla om publiceringsverktyg (CMS), HTML-redigerare och online-bloggar. Den här specifikationen (ATAG) förklarar hur dessa verktyg i sig måste vara tillgängliga men också hur de som använder verktygen bör få stöd i att skapa tillgängligt innehåll. Du kan till exempel också använda specifikationen för att ställa krav på det verktyg du använder.
• Brödsmulor. Det här konceptet har förstås fått sitt namn från sagan om Hans och Greta. Tanken är att det ligger länkar nära toppen av sidan som visar den väg man går hierarkiskt från hemsidan för att komma till den sida man är på. Jag brukar skoja om att brödsmulorna funkade dåligt för Hans och Greta. Det var när fåglarna åt upp deras brödsmulor som de inte hittade hem och i stället hamnade hos häxan.
• CSS. Detta står för Cascading Style Sheet. På svenska kallar vi det ofta stilmall. Det är ofta ett separat dokument, men kan också vara en del av koden i sidan, som definierar hur innehållet ska presenteras visuellt. CSS-angivelser innehåller typiskt storlekar, typsnitt, marginalinställningar, med mera.
• CSS-pixlar. Det fanns en tid när en pixel alltid motsvarade en punkt på en skärm. Så är det inte med CSS-pixlar, som är en abstrakt enhet som ska göra det lättare att faktiskt mappa storleken mot en fysisk storlek på en skärm. Helt enkelt: 96 CSS-pixlar ska motsvara en tum (en inch), oavsett upplösningen på skärmen. Detta är för att storleken ska kunna vara förutsägbar för utvecklare, när innehåll flödar och anpassas till olika skärmar.
• UUAG. User Agent Accessibility Guidelines ger stöd för de som utvecklar och skapar webbläsare, insticksprogram till webbläsare, mediespelare och andra typer av program som genererar innehåll för webben. Syftet är att dessa verktyg också måste bygga in stöd för tillgänglighet, och vi kan alla hjälpas åt att ställa krav på de som bygger dessa verktyg. User Agent Accessibility Guidelines (UAAG)
• W3C. World Wide Web Consortium (W3C) är den organisation som utvecklar internationella standarder för webben: HTML, CSS och mycket mer. Organisationens hemsida är w3.org.
• WAI. W3C:s Web Accessibility Initiative utvecklar standarder och stödmaterial för att hjälpa dig förstå och implementera tillgänglighet i webbsidor och digitala tjänster. De välkomnar deltagare från hela världen. Initiativets hemsida är w3.org/WAI/
• WAI-ARIA. En specifikation om roller, tillstånd och egenskaper som definierar tillgängliga komponenter i användargränssnitt. Vägledningen kan användas för att förbättra tillgänglighet och samspel i webbinnehåll och applikationer. De semantiska egenskaperna ger utvecklaren möjlighet att förmedla gränssnittets beteende och strukturella information i sidornas kod. Vägledningen WAI-ARIA 1.1.

Fler ord som nog behöver en förklaring när jag får tid över:

• Programmatiskt
• Ner-händelse (down-event)
• Upp-händelse (up-event)
• Röststyrning
• Webbläsare (user agent)
• Inmatning (input)
• Läsplatta
• Markör
• Modal
• Hover
• Focus

F. Vidare läsning och inspiration

När du inte kan få nog

Officiell dokumentation

• Vägledning för webbutveckling - De officiella riktlinjerna för hur man bör arbeta med webbplatser i offentlig sektor i Sverige
• WCAG 2.0
• WCAG 2.1
• Accessible Rich Internet Applications (ARIA) - en specifikation för hur man kan öka tillgängligheten på dynamiska webbsidor
• Authoring Tool Accessibility Guidelines (ATAG) 2.0 – information om hur publiceringsverktyg bör ge stöd åt tekniskt och redaktionellt tillgänglighetsarbete.

Forum

Bloggar

Verktyg

Granska koden med insticksprogram till webbläsare