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 Felidentifiering. Om information matas in på ett felaktigt sätt så identifieras felet och beskrivs i text.
• 3.3.2 Etiketter och instruktioner. Dessa tillhandahålls när information efterfrågas av användaren.
• 3.3.7 Redundant inmatning. Be inte om samma information två gånger under samma session. En del personer med kognitiva funktionsnedsättningar har svårt att komma ihåg vad de skrev in tidigare. Om information efterfrågas igen kan det till exempel var förifyllt eller bekräftas av användaren.

Det låter enkelt att visa vad som är fel i ett formulär men 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

Nivå AA

• 3.3.3 Felstöd. 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 Felförebyggande. När en webbsida innefattar juridiska eller finansiella transaktioner – som förändrar eller raderar information som tillhör en person – måste ett 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.
• 3.3.4 Tillgänglig autentisering (minimum). Tvinga inte människor att lösa, minnas eller transkribera något för att logga in. En del personer med kognitiva funktionsnedsättningar kan inte lösa pussel, memorera ett användarnamn och lösenord eller skriva av engångskoder. Dessa kan tillåtas om något av följande också är uppfyllt:
  • Alternativ. En annan autentiseringsmetod som inte förlitar sig på ett kognitivt funktionstest.
  • Mekanism. En mekanism finns tillgänglig för att hjälpa användaren att slutföra det kognitiva funktionstestet.
  • Objektigenkänning Det kognitiva funktionstestet är att känna igen föremål.
  • Personligt innehåll Det kognitiva funktionstestet handlar om att identifiera icke-textbaserat innehåll som användaren själv har tillhandahållit webbplatsen.
  • Objektigenkänning och personligt innehåll kan innebära bilder, video eller ljud

Notera: En sida som blockerar möjligheten att klistra in sitt lösenord (för att slippa skriva det) misslyckas direkt med att leva upp till tillgänglig autentisering.

Nivå AAA

• 3.3.5 Hjälp. 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 Felprevention (alla). 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.
• 3.3.9 Tillgänglig autentisering (utvecklad). Tvinga inte människor att känna igen objekt eller innehåll de själva tillhandahållit (bilder och media) för att logga in. En del personer med kognitiva funktionsnedsättningar kan inte lösa pussel, inklusive att identifiera föremål och icke-textbaserad information som de själva tidigare tillhandahållit.

Ä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.