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?