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

Något gick fel
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.