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.
Uppdatering: Så här skrev jag 2013:
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.
Jag är inte säker på att det här funkar lika bra idag, men det finns alltid bättre sätt att för att bli mer inkluderande när vi bekämpar spam och bot:ar. Jag hoppas kunna skriva mer om det på min blogg framöver. På min engelska blogg har jag skrivit nyligen (juni 2022) om hur EU förstör en röstningsfunktion med captcha, vilket alltså direkt påverkar demokratin.
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.