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.

Digital tillgänglighet är en levande e-bok. Det innebär att innehållet i boken uppdateras löpande med relevant information och förtydliganden. Du kan prenumerera på korta notiser vid större uppdateringar. Din e-postadress används endast till dessa notiser några gånger per år.


Innehåll

  1. Inledning
  2. Riktlinjer i WCAG
    Du kan hoppa direkt till en specifik riktlinje via tabell 1.
  3. Dela och sprid
  4. Checklista
  5. Ordlista Kommer snart
  6. Vidare läsning och inspiration

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?

World Wide Web Consortium, W3C, är den organisation som ansvarar för att ta fram standarder för webbsidor. De har sedan 1999 gett ut två versioner av det dokument som styr riktlinjer för tillgänglighet: Web Content Accessibility Guidelines, eller WCAG. Version 1.0 led av att vara alltför detaljerad och svår att förstå, vilket också gjorde den svår att efterleva. År 2008 kom WCAG 2.0 som kan tillämpas mer brett på mer avancerad teknik och är lättare att verifiera.

Våren 2018 kom version 2.1, som tar än mer hänsyn till mobila enheter.

Notera att även om dessa riktlinjer finns - och ibland kan uppfattas som tekniska - ska det påpekas att väldigt lite av tillgänglighet verifieras maskinellt. Riktlinjerna hjälper dig att göra så lite fel som möjligt när du skapar och utvecklar lösningar, medan utvärdering av tillgänglighet bör ske av ämnesexperter. För att säkerställa tillgänglighet måste lösningar också provas i användarstudier med riktiga människor med konkreta, upplevda funktionshinder.

Men vad innebär digital tillgänglighet?

Man brukar säga att det finns fyra typer av funktionshinder som adresseras:

  1. Visuella funktionsnedsättningar – olika synfel (exempelvis färgblindhet) och olika grader av synnedsättning
  2. Motoriska funktionsnedsättningar – nedsatta förmågor som innebär att personer rent praktiskt inte kan använda de verktyg som man förväntas använda för att hantera en dator, det kan till exempel handla om ofrivilliga skakningar eller partiell förlamning
  3. Auditiva funktionsnedsättningar – olika grader av oförmåga att uppfatta ljud
  4. Kognitiva funktionsnedsättningar – en nedsatt förmåga att förstå och hantera information, detta kan till exempel vara beroende av en utvecklingsstörning, bristande läs- och skrivförmåga eller brist på språkkunskap

Många tror att tillgänglighet handlar om en separat grupp människor med tydliga funktionshinder som påverkar deras generella förmåga att hantera sitt vardagliga liv. Så är det inte.

Många funktionsnedsättningar syns inte. De är så kallade osynliga funktionshinder. Det kan till exempel handla om kognitiv förmåga, färgblindhet eller dövhet. Vissa funktionshinder, som nedsatt syn, är också så vanliga att vi inte tänker på dem som hindrande. Det är för att glasögon är ett utbrett hjälpmedel som är väl integrerat i samhället. Syftet med att jobba med tillgänglighet är att erbjuda mer stöd och verktyg till fler människor så att vi minskar, eller eliminerar, alla de hinder som funktionshinder annars skulle innebära.

När vi pratar om digital tillgänglighet ges ofta exempel som dessa:

  1. Alternativ text – ange förklarande textalternativ för bilder, så att skärmläsare kan läsa upp dessa för synskadade
  2. Stora klickytor – gör knappar så stora att de blir lätta att klicka på även om man darrar på handen
  3. Teckentolkning – erbjud teckentolkning när du när du publicerar videomaterial
  4. Enkelt språk – använd ett lättläst språk så att fler har möjlighet att förstå, såväl barn som människor som ännu inte lärt sig språket så bra

Vissa av dessa exempel är mer tydligt riktade mot en särskild funktionsnedsättning, som teckentolkning för döva. Andra hjälper människor, som barn, som vi kanske inte traditionellt ser som personer med funktionshinder. När det gäller alternativ text så gynnar detta också personer som använder sökmotorer för att hitta särskilt material. Sökmotorer förstår nämligen text bättre än bilder. När det gäller stora klickytor så hjälper detta förstås alla som kan ha svårt att träffa rätt på en klickyta, oavsett om man är äldre och ovan vid en styrplatta eller om man sitter med ett barn i famnen.

När personer som pratar om tillgänglighet säger att det gynnar alla människor så menar de verkligen det. Det är inte ett sätt att överdriva betydelsen av kunskapsområdet. Under en livstid har vi alla olika varianter av funktionshinder som kan vara permanenta, temporära eller situationsbaserade.

Den bästa visualiseringen av den här insikten kommer från Microsoft som har tagit fram en verktygslåda med stöd för att förstå hur man kan jobba med inkluderande design. De kallar sitt stöd för Inclusive Toolkit. I den hittar vi flera diagram som visar hur olika personer kan uppleva liknande hinder av olika skäl.

I tabell 2 ser du exempel på permanenta, temporära och situationella hinder för olika förmågor såsom beröring, syn, hörsel och tal.

Tabell 2
Permanent Temporär Situationell
Exempel från Microsoft Inclusive Toolkit

En arm

Armskada

Ny förälder

Blind

Starr

Distraherad förare

Döv

Öroninfektion

Bartender

Icke-verbal

Strupkatarr

Stark brytning

När du når insikten att arbete med tillgänglighet är något som är till för att hjälpa alla människor, och för att fler ska få möjlighet att använda din tjänst, så blir det också tydligt att tillgänglighet inte bör betraktas som separat från ordinarie arbete med digitala tjänster.

Först när frågor om tillgänglighet hanteras på ett naturligt sätt varje dag som en integrerad del i arbetet för utvecklare, designers, redaktörer, förvaltning och webbansvariga så är vi på väg mot ett inkluderande digitalt samhälle.

B. Riktlinjer i WCAG

En enkel förklaring av vägledningen

Vägledningen i WCAG är uppdelad i 13 övergripande riktlinjer under 4 områden:

  1. Perceivable, alltså Möjlig att uppfatta
  2. Operable, alltså Möjlig att kontrollera
  3. Understandable, alltså Möjlig att förstå
  4. Robust, alltså Robust (vilket innebär att vi ska maximera kompatibilitet med alla typer av webbläsare)

Den nuvarande versionen av WCAG är 2.1, som lanserades i juni 2018. De riktlinjer och kriterier som är markerade med texten version 2.1 i denna e-bok är alltså relativt nya. I WCAG 2.0 fanns 12 övergripande riktlinjer och i WCAG 2.1 har dessa utökats med en riktlinje och totalt 17 nya kriterier som är utspridda över flera riktlinjer.

För var och en av de 13 riktlinjerna finns det alltså framgångskriterier, som vi kan ta hjälp av för att både planera och utvärdera vår lösning. Kriterierna är uppdelade i 3 nivåer: A, AA, och AAA – där man kan förenklat kan säga att fler A:n innebär en högre grad av tillgänglighet.

Strukturen i WCAG är alltså så här:
  • Områden (totalt finns 4 stycken)
    • Riktlinjer (totalt finns 13 stycken)
      • Kriterier fördelade över en till tre nivåer (A, AA och AAA)

Tips: Området Robust har bara en riktlinje och tre kriterier, att bygga för högsta möjliga kompatibilitet, så koncentrera dig först på att lära dig de första tre områdena.

Vad de flesta sajter gör fel (inklusive många kravspecifikationer jag läst) är att väldigt slarvigt säga:

  • Vi ska uppfylla nivå AA av WCAG 2.0

Problemet med det här påståendet är att alla riktlinjer inte ens har en AA-nivå. Vissa har bara en A-nivå och ibland finns både A och AAA, men inte AA. Det enda rätta är att gå igenom alla riktlinjerna och för var och en ta ställning till hur man ska ge stöd för just det behovet.

Handen på hjärtat, om du med enkla medel kan nå nivå AAA, varför skulle du undvika det bara för att någon annan påstår att nivå AA är tillräckligt? När vi fokuserar på att göra mindre än möjligt blir det ett felaktigt fokus på att undvika att göra saker, i stället för att fokusera på allt man kan göra.

Att gå igenom riktlinjerna tar inte lång tid, det är lärorikt, upplysande och etiskt korrekt att ta ett medvetet beslut kring egenskaper som påverkar hur alla människor kan konsumera innehåll i din tjänst eller produkt.

Snabbgenomgång av riktlinjerna

I listan markeras vilka A-nivåer som finns angivna för respektive riklinje.

  1. Möjlig att uppfatta
    1. Textalternativ. Allt innehåll som inte består av text måste ha ett textalternativ. Exempelvis: bilder ska ha ALT-attribut.
      Nivåer: A
    2. Tidsbaserad media. All multimedia som är förinspelad (ej live) måste ha tillhörande text som förmedlar innehållet. Är det live ska det gärna teckentolkas.
      Nivåer: A, AA, AAA.
    3. Strukturerat innehåll. Det ska gå att maskinellt förstå vad som är rubriker, länkar, listor, tabeller, etiketter till formulärfält, och så vidare. Koda rätt alltså. Man får inte heller i sina texter hänvisa till saker baserat på färg, form, storlek eller placering som ”klicka på den röda ikonen” eller ”kolla i kolumnen till höger”. Det är inte säkert att sådana egenskaper presenteras för användaren på samma sätt som för dig.
      Nivåer: A, AA (2.1), AAA (2.1).
    4. Urskiljbart. Hjälp människor att se och höra innehåll. Kontrast mellan förgrund och bakgrund måste vara godkänd. Använd heller inte endast färg för att särskilja visuellt innehåll (som för länkar, understrykning är alltså att rekommendera). Användaren måste också kunna själv kontrollera uppspelning av eventuella ljud.
      Nivåer: A, AA, AAA.
  2. Möjlig att kontrollera
    1. Åtkomst via tangentbord. Det ska gå att hantera all funktionalitet på sidan med endast ett tangentbord.
      Nivåer: A, AAA.
    2. Tillräckligt med tid. 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. Om saker rör sig går det att stoppa, pausa eller döljas.
      Nivåer: A, AAA.
    3. Anfall (epilepsi och liknande). 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.
      Nivåer: A, AAA.
    4. Lättnavigerad. Gör det möjligt att hoppa över innehåll, ha en beskrivande titel, informativa länktexter, gör formulärfältens etiketter informativa och gör det visuellt uppenbart vilket element på sidan som har fokus om man navigerar via tangentbordet.
      Nivåer: A, AA, AAA.
    5. Peka och markera Ny Det ska vara möjligt att kontrollera gränssnitt med endast ett finger/musmarkör/röstmarkör. Det innebär till exempel att du måste erbjuda alternativ till pekgester med flera fingrar. Tänk också på storleken på klickytor och att tillåta alla typer av inmatningsverktyg som plattformen tillåter.
      Nivåer: A, AAA.
  3. Möjlig att förstå
    1. Läsvänligt för skärmläsare. Språk är angivet för hela dokumentet och delar av sidan som är på annat språk är markerat i koden med lang-attributet.
      Nivåer: A, AA, AAA.
    2. Förutsägbar. När ett element på sidan får fokus, eller när information matas in i formulär, så förändras inte innehåll på sidan på ett sätt som kan desorientera. Navigationselement ändrar inte ordning vid navigering på sidan. Alltså: var försiktig med Ajax.
      Nivåer: A, AA, AAA.
    3. Inmatningshjälp. Det är tydligt om information ska skrivas in på ett visst sätt och/eller är obligatoriskt. Eventuella felmeddelanden presenteras på ett intuitivt sätt där felet är tydligt markerat med snabb access till möjlighet att åtgärda och skicka om.
      Nivåer: A, AA, AAA.
  4. Robust
    1. Kompatibilitet. Följ specifikationerna för den HTML-standard du använder för sidorna. Säkerställ att så många webbläsare som möjligt kan använda tjänsten.
      Nivåer: A, AA.

Du märker säkert att mycket av andemeningen går att förstå nästan genast, medan andra saker kan behöva mer förklaring. Du kanske också undrar hur vissa riktlinjer påverkar just dig. Ofta kan du faktiskt utesluta flera riktlinjer som inte är relevanta för din lösning. Det ger dig i slutändan endast en handfull riktlinjer att djupdyka i och hantera.

För var och en av dessa riktlinjer kommer jag att ge exempel och förklara hur de påverkar olika roller i ett team som jobbar med webben: beställare, redaktörer, utvecklare och andra producenter. Jag kommer också peka på positiva effekter inom andra kritiska områden som användbarhet och sökmotoroptimering.

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

Jag misstänker att riktlinje 1.2 kan upplevas som det tuffaste, och mest resurskrävande, kravet att uppfylla i WCAG. Hur många fördelar vi än kan lista med multimedia så kvarstår dock problemet att det utesluter människor som inte kan tolka information i det formatet.

Ljud är, i grunden, bra

Möjligheten till ljud förs ofta fram som en fördel, just för att det har potentialen att göra innehåll tillgängligt för människor med nedsatt synförmåga. Och så är det. Problemen uppstår oftast när vi har ljud i kombination med video, och de rörliga bilderna krävs för att förmedla innehållet. Men bara för att synskadade har fått en välförtjänst stark position i designtänkande så får vi inte glömma bort att många är permanent eller situationellt drabbade av begränsad hörsel och/eller kognitiv förmåga.

Nivå A

För att uppfylla kriterierna för tillgänglighet när det gäller ljud och video så måste man, för att uppfylla det lägst ställda kravet (nivå A):

  • 1.2.1 Ha ett textalternativ för allt förinspelat ljud och video som återger likvärdig information som ljud-spåret.
  • 1.2.2 Ha undertexter (captions) för all förinspelad video.
  • 1.2.3 Ha antingen ett textalternativ eller ett extra ljudspår som förklarar det visuella innehållet i förinspelad video.

Det här innebär förstås att den stora massan av ljud och film vi tar del av på nätet inte uppfyller det lägst ställda kravet. Även om YouTube erbjuder en integrerad tjänst för bildtext så är det tyvärr bara en handfull som använder den funktionaliteten.

Det behövs en del kampanjande och insiktsskapande om att väldigt många har nytta av bildtext och textalternativ; det handlar inte bara om hörselnedsättningar utan även om människor som har svårt att förstå språket och har stor nytta av textkomplement för bättre förståelse. Det ger också betydande fördelar om sökmotorer och andra verktyg kan tolka innehållet.

Glöm inte heller bort de situationella behoven: många sitter idag i kontorslandskap eller befinner sig på bussen och har glömt hörlurarna hemma; eller lyssnar på musik och väljer bort ljud i en förklaringsvideo. Textning av video gör att alla i olika situationer kan ta till sig innehållet trots avsaknad av ljud, och du når betydligt fler.

Det kan faktiskt vara billigare än många tror; även för ett hobbyprojekt som exempelvis den podcast jag medproducerar så prioriterar vi transkribering av avsnitten. Generellt är det billigare med engelskt innehåll, (eftersom utbudet av människor som transkriberar är betydligt större) men i och med att fler företag kan hittas via nätet - och jobba på distans - finns ett växande utbud av leverantörer även i Sverige.

Exempel: När jag bäddar in video från YouTube på min webbplats, som jag inte själv kan påverka innehållet i, så försöker jag förklara andemeningen i filmens budskap i min text. Det är en god ansträngning när man inte själv har producerat videon, men enligt konstens alla regler är faktiskt inte ens det nivå A av tillgänglighet – eftersom jag inte förklarar det visuella innehållet (hur människorna ser ut rör sig i filmen) och det inte finns bildtext i själva videon.

Nivå AA

Vi kämpar vidare med nivå A men låt oss också kika på vad som krävs för att nästa nivå (AA) ska uppfyllas. Det här är speciellt intressant eftersom de flesta företag och organisationer säger sig uppfylla nivå AA av WCAG 2.0. Men i 99 fall av 100 gör de alltså inte det.

  • 1.2.4 Bildtext (captions) ska finnas tillgänglig för alla live-sändningar av media med ljud. Det betyder alltså att du måste ha någon som simultanskriver i samband med sändningen, eller ett färdigt manus som lyfts in.
  • 1.2.5 Ljudbeskrivningar ska finnas tillgängliga för allt video-innehåll.

Ljudbeskrivningar är inte text, det är ett extra ljudspår som berättar vad som händer i bild för de som inte kan ta till sig bilden. Man lägger alltså i ljud till information om beteenden, karaktärer, scenförändringar och eventuell skärmtext som är viktig men inte beskrivs eller uttalas i det primära ljudspåret.

En vanlig fördom är att synskadade inte går på bio. Men när filmer har ljudbeskrivningar så är det inte alls ovanligt att även människor som är registrerade som blinda med stor behållning gärna tar sig till biografen.

Tips: En serie på Netflix som har ljudbeskrivningar är den om den blinda superhjälten Daredevil. Läs mer om kampanjen som krävde detta extra ljudspår.

Nivå AAA

Låt oss för all del inte stanna där. Det finns en nivå till i denna riktlinje. För att uppfylla nivå AAA krävs:

  • 1.2.6 Att all förinspelad video har teckenspråkstolkning.
  • 1.2.7 Avancerade ljudbeskrivningar. När videon inte har tillräckligt många/långa pauser för att lägga in ljudbeskrivningar så pausas videon automatiskt för att ljudbeskrivningarna ska få tillfälle att förmedla känslan i videon.
  • 1.2.8 Ett fullgott textalternativ för all video med visuellt innehåll: ett sådant läses nästan som en bok om det finns visuell information, med till exempel beskrivningar av sammanhang, beteende och människors ansiktsuttryck.
  • 1.2.9 Ljud som är live ackompanjeras med motsvarande textalternativ. Det innebär live-transkribering eller, om det är tal som följer ett manus, en länk till manuset.

Medvetet beslut eller förödande okunskap

För företag och organisationer som jobbar med video och ljud ska det ligga i budget hur man skapar och säkerställer en tillgänglig produktion. Trenden som jag ser just nu, där man har en okunskap och i viss mån total brist på empati för behovet hos vanliga människor, är oroväckande.

Jag kan acceptera att man väljer bort tillgänglighet i vissa fall om det är ett beslut som man har värderat och begrundat på riktigt när det gäller teknik, resurser och användare. Att välja att skapa otillgängligt innehåll som inte når alla ska framför allt vara ett medvetet beslut som någon kan stå till svars och argumentera för. Att gömma huvudet i sanden, som så ofta när det gäller video, borde inte vara den framkomliga väg som det är idag.

Tips: Åsa Holmberg bloggar om hur man gör webbvideo tillgänglig för fler.

1.3 Strukturerat innehåll

Allt i ordning från början till slut

Som seende blir man överöst med visuella signaler som berättar hur innehåll på en webbsida hänger ihop, och i vilken ordning saker och ting ska läsas och tas in. Typsnitt, rubriker, inramningar, färger, pilar, kolumner och så vidare. Men hur förstår man sammanhang om inga visuella signaler finns tillgängliga? Och hur dämpar man alla intryck om det blir för mycket?

På webben är struktur virtuell

Ibland ser jag hänvisningar till saker som ”länken i högerkolumnen” eller ”det rödmarkerade felmeddelandet”. Sådana förklaringar kan bli totalt intetsägande, och leda till förvirring, när det handlar om digitalt innehåll.

En skärmläsare, och för all del en sökmotor, vet inte om vad som är högerkolumnen eller vad som är det röda fältet. Allt läses uppifrån och ner enligt ordningen i koden. Instruktionerna blir som att hänvisa till en nål i en höstack.

En stor styrka i webbvärlden är syndikering av innehåll, exempelvis via RSS, som innebär att innehåll är strukturerat så att det lätt lyfts in på många olika platser. Det är alltså inte säkert att det längre ens finns en högerkolumn där din text blir läst.

I och med att så många människor konsumerar webbsidor via mobilen idag har faktiskt fler förstått delar av det här strukturproblemet. Vi arbetar inte i flera kolumner på mobilen, utan där blir ofta 3 kolumner nerkokade till en enda lång kolumn. Att då hänvisa till en högerkolumn är uppenbart missvisande.

Som tumregel är det fel att hänvisa till något på webben utan att ha en länk till det man hänvisar till; det är trots allt det som är ryggraden i webben: hyperlänkar. Om du ser till att hänvisningar är länkade så hittar alla direkt det du menar.

Instruktioner för strukturerat innehåll

När det gäller "Strukturerat innehåll" i WCAG så finns nu - sedan version 2.1 - tre nivåer; tidigare fanns endast nivå A. Tilläggen handlar om hantering av personlig data och personalisering av gränssnittet. Men vi börjar först med att innehållet ska vara logiskt strukturerat:

Nivå A

  • 1.3.1 Info och relationer. Information, struktur och relationer som förmedlas via presentation kan även härledas utifrån sidans kod.
  • 1.3.2 Meningsfull ordning. När ordningen som innehåll presenteras i är viktig för förståelsen så erbjuder sidans kod den önskade läsordningen.
  • 1.3.3 Sensoriska egenskaper. Instruktioner för att förstå och hantera innehåll förlitar sig inte enbart på sensoriska egenskaper som form, storlek, visuell placering eller ljud.

De första två punkterna handlar om hur sidan kodas för att det ska vara lätt att förstå sammanhang. Det ska till exempel gå att utläsa vad som är rubriker (inklusive inbördes nivåer), 'fotnötter', etiketter i formulär, felmeddelanden, med mera.

Det är också viktigt att läsordningen stämmer överens med den läsordning du förväntar dig. Ett enkelt sätt att testa detta är att avaktivera sidans stilmall och se i vilken ordning innehållet i sidan ligger.

Den tredje punkten ger oss vägledning kring en grundläggande minnesregel inom digital tillgänglighet: förmedla funktion på mer än ett sätt. Om du till exempel ger användaren möjlighet att bläddra till nästa sida så räcker inte instruktionen "Klicka på pilen för att komma till nästa sida." Det är inte säkert att personen uppfattar pilen som en pil. Om du i stället skriver "Klicka på den gröna pilen som det står Nästa på för att gå vidare", så använder du både färg, form och etikett för att beskriva funktionen. Sannolikheten för att fler ska kunna slutföra uppgiften framgångsrikt ökar betydligt.

En textlänk ska till exempel inte enbart ha en annan färg utan även vara understruken.

Nivå AA

  • 1.3.4 Version 2.1 Orientering. Innehåll begränsar inte sin vy eller användning till enbart stående eller liggande läge, såvida inte en specifik orientering är nödvändig.
  • 1.3.5 version 2.1 Betydelsen av varje inmatningfält som samlar in information om användaren kan adresseras programmatiskt när:
    • Inmatningsfältet har en innebörd som mappar mot instruktionerna i specifikationen HTML 5.2 Autofill field names; och
    • Innehållet är implementerat med teknik som stödjer identifiering av den förväntade innebörden för formulärdata.

Det som sägs här är att om ett formulär efterfrågar information som användaren fyller i ofta - till exempel e-postadress - så kan webbläsaren förstå detta (programmatiskt) och erbjuda förslag och hjälp för att fylla i formuläret enklare och snabbare. Typisk information som detta gäller enligt specfikationen är:

  • Namn
  • Adress
  • Användarnamn
  • Lösenord
  • Valuta
  • Födelsedag
  • och många fler

I praktiken innebär detta att man använder sig av autocomplete-attributet när man bygger formulär. Det kan se ut så här:

<form>
<label for="namn">Namn</label>
<input id="namn" autocomplete="name" type="text">
<label for="epost">E-postadress</label>
<input id="epost" autocomplete="email" type="e-mail">
</form>

Nivå AAA

Nu blir vi ännu lite mer tekniska:

  • 1.3.6 version 2.1 När innehållet implementeras med markup-språk, kan syftet med gränssnittets komponenter, ikoner och regioner tolkas programmatiskt.

Det här kriteriet bygger vidare på kriteriet från Nivå AA, men nu är det inte längre bara innehåll som ska vara markerat och kunnas tolkas, utan även vad knappar och funktioner faktiskt gör. Poängen med detta är att om användare är bekanta och bekväma med vissa utseenden, ikoner och texter så kan deras webbläsare1 ersätta hur gränssnittet ser ut med de komponenter som användaren bättre förstår och kan hantera.

1Notera: I begreppet webbläsare inbegriper jag även olika typer av stödverktyg som används för att få åtkomst till innehåll och funktioner på webbplatser, exempelvis skärmläsare och braille-tangentbord.

Låt säga att vi har en knapp och/eller ikon som vi använder för att aktivera en sökning efter innehåll. Ofta kan ikonen vara ett förstoringsglas. Om vi specificerar att knappen innebär "starta sökning" så kan användarens webbläsare använda andra ikoner eller text, och även placera knappen annorlunda eller göra den större, vilket hjälper användaren att bättre förstå vad knappen gör.

Exempel på hur detta kan implementeras för en sök-knapp:

<button itemprop="http://schema.org/SearchAction">Sök</button>

I förlängningen innebär det att regioner som endast är text också kan ersättas programmatiskt. Då metaforer och liknelser kan ställa till besvär för många människor, finns möjlighet att alltid erbjuda konkreta formuleringar som minskar tvetydighet, som i detta kodexempel för "Det regnar småspik":

<span aui-literal="det regnar mycket kraftigt"> Det regnar småspik. </span>

Webbredaktörens roll

Tillgänglighet påverkas väldigt mycket av det dagliga arbetet med en webbplats. Tillgänglighet är alltså inte något man fixar i ett projekt och är färdig med när man lanserar. Man kan ha en "välkodad" mall men misslyckas kapitalt med tillgänglighet om man gör fel som redaktör eller skribent.

Därför raljerar jag om förvirrande instruktioner som "titta i högerkolumnen" (vanligt överlag) eller "de rödmarkerade fälten" (vanligt i felmeddelanden). Det är instruktioner som man bara förstår om man har visuella signaler. Oftare än du tror är de visuella signalerna osynliga eller tvetydiga.

Ditt jobb blir att hela tiden tänka: utan de visuella signalerna om hur sidan ser ut, hur kan jag på bästa sätt förmedla det användaren behöver veta?

1.4 Urskiljbart

Tydlighet framför allt

Det är en otäck känsla när man hela tiden anar att man missar något, att man inte riktigt har kontroll över situationen. Den känslan skapar vi när det inte är tillräckligt tydligt för användaren vad som är en länk, när ljud spelar och vi inte kan stoppa det, samt när text och bakgrund flyter in i varandra. Situationen blir snabbt frustrerade och enerverande.

Det kan vara små detaljer som avgör om en människa kan urskilja innehåll och därför är det viktigt att man använder bra verktyg för att till exempel avgöra rätt färgton och rätt volym på bakgrundsljudet.

"Urskiljbart" handlar om att göra innehåll, både text och ljud, så tydligt som möjligt för användaren. Syftet är att minska bruset och öka möjligheterna för besökare att utan hinder förstå och ta till sig information.

För denna riktlinje finns tre tydliga nivåer som jag vill lotsa dig igenom:

Nivå A

  • 1.4.1 Använd inte enbart färg som det enda sättet att förmedla betydelse. Det klassiska exempelmisstaget är att i löptext förlita sig på enbart färg för att särskilja länkar. Skillnaden mellan brödtext och länkar blir för svag, och man måste alltså komplettera med någon form av understrykning och/eller ikon för att uppfylla den lästa nivån av tillgänglighet.
  • 1.4.2 Tillåt styrning av ljud. Om ett ljud spelar i mer än 3 sekunder så finns det antingen en tydlig möjlighet att pausa eller stoppa ljudet och/eller så finns möjlighet att styra ljudets volym oberoende av det övergripande systemets volym.

Nivå AA

  • 1.4.3 Kontrastförhållanden. Text, och bilder av text, måste ha ett kontrastförhållande på minst 4:5:1. För stor text på 18 punkter eller mer gäller förhållandet 3:1. Undantaget är text som inte fyller en informationsbärande funktion, samt logotyper.

Men vad betyder dessa kontrastförhållanden i praktiken? För att avgöra det måste du mäta kontrasten mellan förgrund (textens färg) och bakgrund (färgen bakom texten). Snabbast går du enkelt till online-verktyget Colour Contrast Check och matar in värdena för färgerna som du vill använda. Där kan du också leka med ett reglage för att öka och minska färgstyrkorna. Du får omedelbart bekräftelse på om kontrasten uppfyller WCAG:s krav.

Om du sitter desto oftare och bedömer kontrast rekommenderar jag att ladda ner och installera verktyget Contrast Analyser for Windows and Mac, som ger dig möjlighet att plocka färger direkt från skärmen och bedöma deras kontrastförhållande. Det du snart märker är att det är små skillnader som kan avgöra om det blir godkänt eller inte, så det finns sällan bra ursäkter för att inte göra rätt från början.

OBS! Det är väldigt lätt att tro att man med synen kan avgöra om något har tillräcklig kontrast, men det är ofta jag blir förvånad över bristen på godkänd kontrast. Tillåt dig själv att bli förvånad och gör jobbet ordentligt genom att kolla av färgerna.

  • 1.4.4 Ändra storlek på text. Förstoring av text är möjlig upp till 200% utan behov av tredjepartsverktyg, utan att förlora någon funktionalitet i sidan och utan att innehåll försvinner. Moderna webbläsare klarar det här rätt bra på egen hand.
  • 1.4.5 Bilder med text. Bilder med text används endast om bilden visuellt kan anpassas till användarens behov, eller när en specifik presentation av texten är nödvändig (som i logotyper). Generellt finns ingen som helst anledning att ersätta text med bilder av texten.
Här följer fyra AA-kriterier som är nya i version 2.1 av WCAG, och därför i numreringen hamnar efter några av de äldre kriterier som hör till nivå AAA. Blir därför inte förvånad över att numreringen hoppar över några nummer och sedan tillbaka.
  • 1.4.10 version 2.1 Responsiv design. Innehåll kan presenteras utan att information eller funktionalitet går förlorad, och utan att det krävs bläddring i två dimensioner för:
    • Vertikalt bläddrande vid en bredd som på 320 CSS-pixlar.
    • Horisontellt bläddrande vid en höjd på 256 CSS-pixlar.

    Detta säger oss att webbsidor ska fungera (utan att behöva bläddra/skrolla) ner till de flesta storlekar som används av smarta telefoner.

  • 1.4.11 version 2.1 Kontrast för innehåll som inte är text. Den visuella presentationen av följande har ett kontrastförhållande på minst 3:1 gentemot intilliggande färg(er):
    • Komponenter i gränssnittet. Visuell information som används för att indikera inställningar och gränserna för dessa komponenter; förutom inaktiva komponenter eller när utseendet på komponenten styrs av webbläsaren och inte utvecklaren.
    • Grafiska objekt. Delar av grafik som behövs för att förstå innehållet, förutom när en särskild presentation krävs för informationen som förmedlas.
  • 1.4.12 version 2.1 Textavstånd. Användare och webbläsare måste själva kunna justera text för att göra den lättare att läsa. I markup-innehåll som stödjer följande text-egenskaper så förloras inget innehåll och inga funktioner genom att ställa in alla dessa utan att ändra någon annan stil-egenskap:
    • Radhöjd (radavstånd) till minst 1.5 gånger typsnittets storlek
    • Avstånd efter textstycken till minst 2 gånger typsnittets storlek
    • Teckenavstånd till minst 0.12 gånger typsnittets storlek
    • Ordavstånd till minst 0.16 gånger typsnittets storlek
    Undantaget: Mänskliga språk och skript som inte använder något av dessa text-egenskaper i skrift klarar sig med de egenskaper som används.
  • 1.4.13 version 2.1 Innehåll vid Hover eller Focus. När ytterligare innehåll döljs och/eller visas som ett resultat av att användaren antingen håller markören ovanför ett klickbart element (hover), eller tangentbordet används för att markera ett klickbart område (focus), så gäller följande:
    • Möjlig att avvisa. Möjlighet finns att avvisa det ytterligare innehållet utan att flytta markör eller fokus, såvida inte det ytterligare innehållet kommunicerar ett inmatningsfel, eller inte döljer eller ersätter annat innehåll
    • Synlighet vid hover. Om markörens placering kan aktivera det ytterligare innehållet så kan markören också förflyttas ovanför det ytterligare innehållet utan att det försvinner.
    • Beständighet. Det ytterligare innehållet förblir synligt till dess att hover eller focus försvinner, användaren avvisar det, eller informationen inte längre är giltig. Undantag: Din visuella presentationen av det ytterligare innehållet kontrolleras av webbläsaren och kan inte justeras av utvecklaren.

Nivå AAA

  • 1.4.6 Textens kontrastförhållande bör vara på 7:1, eller 4:5:1 för stor text (stor text innebär 18 punkter eller mer vid normal text, 14 punkter och uppåt för fet text)
  • 1.4.7 Bakgrundsljud i förinspelat ljud går antingen att stänga av, är 4 gånger lägre (20 decibel lägre) i ljudstyrka än förgrundsljudet eller finns helst inte alls. Undantaget är musikaliska ljudspår eller ljud som är en ljudlogotyp.
  • 1.4.8 För block av text finns funktioner för att åstadkomma följande:
    • Förgrunds- och bakgrundsfärg kan väljas av användaren.
    • Radlängden är på 80 tecken eller färre (40 tecken för CJK – Kinesiskt, Japanskt, Koreanskt)
    • Radhöjden är på 1.5 eller mer, och mellanrum mellan stycken är minst 1.5 gånger mer än radhöjden.
    • Textstycken är inte marginaljusterade, alltså kantjusterade på både höger och vänster sida.
    • Text kan förstoras upp till 200% utan förlorad funktionalitet och utan krav på att behöva bläddra i sidled för att läsa texten.
  • 1.4.9 Det finns inga undantag till kriteriet att bilder med text endast används för dekoration eler när presentationen av text är nödvändig för informationen som förmedlas (som i en logotyp).

Som jag varit inne på så är ett vanligt misstag att tänka ”Vi ska uppfylla nivå AA så därför läser vi inte AAA-kriterierna”. Det är självklart rimligt att eftersträva att uppfylla så många kriterier man kan, oavsett nivå, eftersom varenda litet kriterium kommer göra att fler mottagare kan ta till sig information. Så även om man inte har för avsikt att uppfylla nivå AAA fullt ut, ha ambitionen att fastställa vilka delar av nivå AAA som ändå är rimliga.

Denna riktlinje som handlar om tydlighet (och kontroll) innehåller enkla regler som är relativt lätta att implementera och verifiera. Alla handlar om att skapa yta och kontrast för att lättare särskilja innehållet, samt ge användaren kontroll över innehållets presentation och distraktioner. Därför bör det vara tydligt från start när man utvecklar vilka av dessa kriterier som gäller. Och skulle någon ifrågasätta behovet så är svaret enkelt:

Vi gör det systematiskt enklare för fler att ta till sig innehållet genom att eliminera hinder som har visat sig skapa förvirring hos många människor.

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.

AAA

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.

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:

Formulär med instruktion

Formulär med felmeddelande

Vi kunde inte ta emot dina uppgifter. Du har endast angett 6 av 10 siffror i fältet "Personnummer". Åtgärda felet och skicka igen.

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.eu/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.

Per Axbom - svartvit porträttbild, tittar åt höger i bild

Författare: Per Axbom

@axbom

Per Axbom är kommunikationsvetare, coach och designer. Han började använda datorer i sitt skolarbete 1984 då han skrev en uppsats om ”Bigfoot” på sin Atari 600XL och använde en matrisskrivare för utskrift.

Sedan 1998 har Per arbetat professionellt med användbarhet, tillgänglighet och inkluderande design för digitala tjänster. Under 2018 arbetar han på en engelskspråkig bok om etisk och hållbar design: Misusability.

Frågor, idéer och synpunkter gällande Digital tillgänglighet tas emot på e-postadressen digitill@axbom.se

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.

Skicka ett meddelande till mig om du är intresserad av en PDF-version av checklistan.

Riktlinje Bedömning
Checklista framtagen av Per Axbom, läs mer på axbom.eu/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