Koll på tillgänglighet: 5. Åtkomst via tangentbordet

För många år sedan hjälpte jag SL med deras reseplanerare och arbetade även med det (då helt nya) webbgränssnitt som SL:s kundtjänst använder, det vill säga de personer som svarar på frågor om resvägar, tider och störningsinformation på telefon. Det gränssnittet skiljer sig markant 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.

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, 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 kan enkelt kan integrera ytterligare mjukvara eller hårdvara som kan simulera kombinationer av knapptryckningar, för att förenkla eller effektivisera navigering.

Det här inlägget är en del av en serie poster om tillgänglighet.

wcag-tangentbord

Från start till slut

Den femte regeln i WCAG säger så här:

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) kompletteras även med följande krav:

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.

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 – 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 svårare blir det alltså att uppfylla riktlinje nummer 5. Det bästa sättet att arbeta är genom progressive enhancement, eller gradvisa förbättringar. Utgå från det enkla, standardiserade sättet till att börja med, och addera sedan 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.