Interaktionsdesign / Använda (Hela kapitlet)

• Skall
• www.anvandbart.se/ab/bakgrundsfarg

Eftersom en del webbläsare använder grå bakgrundsfärg på kontroller för att markera att de inte är aktiva (till exempel på kryssrutor, valboxar och textfält), bör grått inte användas för dekorativa syften i kontroller.

• Bör - undantag, se boken
• www.anvandbart.se/ab/radioknapp-forval

I en grupp radioknappar bör en av knapparna vara förvald. Om det finns behov av ett inget-val, så bör detta vara en egen radioknapp (detta för att användaren alltid skall kunna ångra en inmatning och återgå till ursprungsläget).

Personligen tycker jag att man kan göra undantag från detta när uppgiften är obligatorisk och formuläret inte kommer att godkännas om inget val gjorts. Andra användbarhetsmänniskor är dock strängare på denna punkt och menar att radioknappar alltid måste ha ett förval.

• Skall
• www.anvandbart.se/ab/radioknapp-tydlig

Layouten måste göra det uppenbart vilka radioknappar som hänger samman.

Ofta är detta tydligare när radioknapparna sitter över varandra än när de läggs horisontellt.

• Bör
• www.anvandbart.se/ab/valbox-alternativ

En valbox kräver av användaren att hon skaffar sig överblick och sedan väljer det alternativ som passar bäst. För att underlätta detta bör de olika alternativen vara korta och skilja sig tydligt från varandra. Det är en fördel om de kan formuleras så att de inleds med den mest betydelsebärande delen (speciellt om listan är ordnad i bokstavsordning). Se Sortera det som är relevant, sid 189 .

• Tips
• www.anvandbart.se/ab/valbox-instruktion

Om inget alternativ skall vara förvalt, kan valboxen inledas med en instruktion i stil med ”Välj ett land”. Denna rad bör ges ett avvikande utseende.

Alternativt kan första alternativet lämnas tomt.

• Bör
• www.anvandbart.se/ab/valbox-flerval

Även om det tekniskt är möjligt att låta användaren välja flera alternativ i en valbox samtidigt så är detta ingenting som användarna känner till eller som det är lätt att förklara för dem. Detta skall därför undvikas. I Välj rätt flervalskontroll, sid 283 , finns andra alternativ för detta.

• Tips
• www.anvandbart.se/ab/valbox-lang

Samma sak gäller för valboxar som för till exempel navigation – redan någonstans vid sex alternativ börjar användare tappa överblick (se Om antalet alternativ är fler än fem, försök hitta ett tema för navigationen , sid 159 ). De klarar betydligt längre boxar än så, men får allt svårare med överblicken. En valbox med för användaren okända alternativ, där hon måste betrakta vart och ett och väga dem mot varandra bör därför hållas kort.

Däremot kan en valboxar där användaren redan har en karta i sitt huvud för både innehåll och ordning – till exempel länder i bokstavsordning – utan problem vara långa.

• Bör. 24-timmarswebben: Skall
• www.anvandbart.se/ab/valbox-gruppera

Om det finns många alternativ i valboxen, bör dessa grupperas och grupperna gärna också få etiketter – ”mellanrubriker” – över sig.

Gruppering görs med HTML-elementet <optgroup>. Länkar till kodningsråd och knep för att få optgroup att fungera även med äldre webb­läsare finns via www.anvandbart.se/ab/valbox-gruppera.

Se även WCAG 12.3 (prioritet 2), sid 367. Samt Navi­ga­ti­on­ens tema, sid 156, där det finns teman som även kan användas för att strukturera en valbox.

• Tips
• www.anvandbart.se/ab/valbox-populara

Om några alternativ i en lång valbox är mycket populärare än de andra kan de sättas först.

Skilj i så fall av kortlistan från resten av valboxen. (Se föregående råd om hur detta kan göras.)

Alternativen från kortlistan bör upprepas i långa listan.

• Tips
• www.anvandbart.se/ab/textfalt-begransning

Undvik att begränsa antalet tecken man kan skriva in i textfältet, eftersom det gör det krångligt för användaren att rätta om hon skrivit fel.

Fånga hellre inmatningsfel när formuläret kontrolleras – då finns det mycket större möjligheter att förklara för användaren varför hennes inmatning är olämplig.

• Tips
• www.anvandbart.se/ab/textfalt-storlek

Storleken på textfältet ger användaren en signal om hur långt hennes svar förväntas vara. Sträva efter att anpassa storleken så att den med viss marginal passar för ett normalt svar (men ta samtidigt hänsyn till layoutens behov, så att inte formuläret i sin helhet blir rörigt).

• Tips
• www.anvandbart.se/ab/textfalt-autocomplete

Moderna webbläsare har en funktion där de minns vad som skrivits in i ett fält. När användaren på nytt kommer till detta fält (eller ett annat med samma namn) följer webbläsaren vad användaren skriver in och visar alla varianter som tidigare skrivits. Detta kan göra arbetet avsevärt snabbare för användare som gång på gång fyller i samma formulär, eller som fyller i vanliga uppgifter typ namn och adress.

I den bästa av världar skulle alla webbplatser döpa till exempel ett fält för e-post på samma sätt, för att på så sätt maximalt underlätta för sina användare. Tyvärr finns ingen allmänt spridd standard för detta, så det bästa man kan göra är att se till att åtminstone den egna webbplatsen är konsekvent.

De fältnamn jag brukar använda för att ta in vanliga personuppgifter är titel, namn, fornamn, efternamn, personnummer, foretag, co, gata, postnummer, ort, email, telefon, arbetet, mobil. (Inga svenska tecken, ”co” används för c/o, ”arbetet” för arbetstelefonnumret.) Detta är som sagt ingen standard, men kan vara en utgångspunkt för att skapa enhetlighet på din egen webbplats.

• Tips
• www.anvandbart.se/ab/losenordsfalt-autocomplete

Beroende på vilken taktik man har för lösenord (se sid 311 för ett resonemang kring detta) kan man vilja hindra webbläsaren från att spara lösenordet. Detta görs med attributet autocomplete=”off” i <input>. Attributet är inte en del av HTML-standarden, se Standard­avvikel­ser , sid 422 .

• Bör
• www.anvandbart.se/ab/knapptext-bild

Det är möjligt att låta en bild fungera som en knapp. Det är dock olämpligt att låta denna innehålla text eftersom storleken på denna i så fall inte är under användarens kontroll (se Textstorlek , sid 46).

Delvis kan detta lösas med HTML-koden button, som medger att man lägger text ovanpå en bakgrundsbild.

Se även WCAG 3.1 (prioritet 2), sid 352.

• Skall
• www.anvandbart.se/ab/knapp-alt

Precis som andra visuella element skall även knappar gjorda av bilder ha en alt-text. Mer om dessa i Bilder skall ha alt-text, sid 60, och WCAG 1.1 (prioritet 1), sid 349.

• Skall
• www.anvandbart.se/ab/knapputseende

Även om det är möjligt att utforma en knapp på många olika sätt bör man vara tämligen konventionell för att inte förvirra användaren. Det skall vara tydligt redan vid först anblicken vad som är en knapp.

Se även Låt inte knappar fungera som länkar eller länkar som knappar , sid 120.

• Skall
• www.anvandbart.se/ab/skickaknapp-namn

Trots att knappen här kallas för ”Skicka” är det inte säkert att det är ett lämpligt namn på ditt formulär. Namnet bör istället väljas så att det berättar vad som kommer att hända när användaren klickar på den. Till exempel ”Registrera mig” eller ”Lägg till logotyp”.

Finns inget bättre alternativ kan man följa den konvention som utvecklats för datorprogram och döpa den till ”OK” (med versaler).

Det är viktigt att alltid döpa knappen till något, eftersom det annars lämnas åt systemet att ge den namn, vilket ger olika namn och till och med olika språk på olika datorer.

• Skall
• www.anvandbart.se/ab/skickaknapp-flera-klick

Om användaren är snabb eller förbindelsen långsam kan hon hinna klicka på skicka-knappen flera gånger. Det är då viktigt att tekniken hanterar detta så att det inte leder till oönskade konsekvenser - till exempel att en beställning på en e-handelsplats räknas som två eller att en inmatning i en databas dubbleras.

På motsvarande sätt får inte heller en omladdning av sidan leda till dubblerad inmatning.

• Bör
• www.anvandbart.se/ab/skickaknapp-javascript

Javascript kan härma skicka-knappens funktion och göra så att till exempel en händelse eller ett klick på en bild är det som skickar formuläret. Att ta bort skicka-knappen kan dock vara mycket förvirrande för bland andra användare med skärmläsare och kan i värsta fall göra webbplatsen helt otillgänglig. Tänk och testa därför noga igenom lösningen om du gör det.

Se vidare Javascript , sid 426 , och Använd HTML-element utifrån betydelse, sid 420 , samt WCAG 6.3 (prioritet 1), sid 358 , och 6.4 (prioritet 2), sid 358 .

Exempel på hur en borttagen skicka-knapp ger otillgänglighet: Val­box­meny­er måste kunna användas utan mus, sid 141 .

• Skall
• www.anvandbart.se/ab/rensaknapp-tomt

Det är sällsynt att användaren vill slänga bort allt hon fyllt i. Rensa-knappen är därför en onödig komplikation för formulär som från början är tomma.

• Bör
• www.anvandbart.se/ab/rensaknapp-forifyllt

Om det finns förinställningar i formuläret ger rensa-knappen användaren en chans att återfå dessa.

Eftersom ett klick i misstag på denna kan ställa till med stor frustration genom att radera allt användaren matat in, bör man göra det möjligt för användaren att ångra sig . Se www.anvandbart.se/ab/rensaknapp-forifylltför tips om hur detta görs.

• Tips
• www.anvandbart.se/ab/aktionsknapp-synlighet

När användaren skall gå igenom en process, till exempel ett flersidigt formulär eller en del av en webbapplikation, vill man ofta göra vägen framåt extra tydlig. Detta kan åstadkommas genom att den knapp som leder vidare görs extra framträdande.

En sådan kallas på svengelska en aktionsknapp (efter engelskans action button). Det enda som skiljer den från andra knappar är utseendet. Tekniskt sett är det en vanlig skicka-knapp. Om det ingår sidor i processen som är vanliga textsidor, inte formulär, kan den till och med vara en vanlig länk förklädd till knapp.

Ibland är det inte bara vägen framåt som betonas på detta sätt utan de handlingarna och möjligheterna på sidan som webbmakaren menar är viktigast görs alla till knappar och får ett mer framträdande utseende. På e-handelsplatser brukar till exempel ”Köp”-knappen behandlas så.

• Tips
• www.anvandbart.se/ab/undvik-lank

Länkar bör undvikas i formulär, eftersom deras grundläggande betydelse är att de lämnar det nuvarande sammanhanget och tar läsaren till någonting nytt – detta kan göra användaren osäker på om hon riskerar att förlora det hon matat in i formuläret.

Det finns dock sammanhang där länkar är motiverade.

• Hjälptexter

Det kan behövas mer hjälptext än vad som får plats i formuläret. I så fall kan det vid kontroller finnas länkar till hjälptexter. Ibland kan det vara lämpligt att öppna dessa i nya fönster så att man inte stör användarens flöde genom formuläret (se Nytt fönster , sid 329 ).

• Genvägar

Länkar som går till andra delar av samma sida, till exempel för att hoppa över en del av formuläret som inte berör användaren.

• Underformulär

Ibland kan delar av formuläret behöva betydligt mer eller annorlunda information från vissa användare från än andra. I så fall är en tänkbar metod att hoppa till ett underformulär med frågor riktade just till dessa användare.

Försök dock undvika detta. Använd hellre genvägar så att användare som inte berörs kan hoppa vidare till nästa del som är aktuell för dem. Eller dela formuläret på flera sidor och anpassa vilka sidor som visas.

Se även navigationskapitlets avsnitt om länkar, sid 115 , och Formulär trivs inte med navigation, sid 278 .

• Tips
• www.anvandbart.se/ab/dokumentuppladdning-pedagogik

Som nämnts ovan har uppladdningskontrollen stora användbarhetsproblem. Det är därför viktigt att vara mycket pedagogisk i utformningen av den.

Ett sätt kan vara att lägga uppladdningskontrollen på en separat sida. När användaren klickar på ”Välj bild” (anpassa formuleringen till den sorts dokument som skall laddas upp) tas hon till en ny sida som bara består av uppladdningskontrollen och förklarande text. Från denna sida återvänder hon först när hon klickat på ”Spara” (eller genom att avbryta).

Detta upplägg medför fler knapptryckningar och är litet långsammare. Trots detta är det i många fall värt det eftersom det avsevärt minskar risken att användaren går vidare utan att ha klickat på båda de nödvändiga knapparna.

• Skall
• www.anvandbart.se/ab/dokumentuppladdning-anvandarkontroll

Om dokumentuppladdningen inte är det enda eller sista som sker utan användaren kan arbeta vidare med formuläret efter att dokumentet bifogats, skall hon kunna se vilket eller vilka dokument hon laddat upp, och ha en möjlighet att ångra sig och ta bort dem igen. (Se även Om användaren kan skapa något skall hon kunna kontrollera att det blev rätt och kunna ångra eller ändra det, sid 302 .)

• Skall
• www.anvandbart.se/ab/etikett-kontroll

De flesta kontroller har en etikett. Det är texten som anger vilken information som skall ges eller vad kontrollen gör.

Hur etiketten placeras varierar med olika kontroller.

• För boxar och fält (valboxar, vallistor, textfält och lösenordsfält ) placeras etiketten som ledtext ovanför eller till vänster om kontrollen.

• För kryssrutor och radioknappar är det informationen som är etiketten. Detta sätts till höger om rutan/knappen.

• Många rutor/knappar behöver ingen etikett utan vad som frågas efter framgår av svaret.

När en etikett behövs sätts den som ledtext ovanför eller till vänster om antingen en enskild kryssruta eller en grupp rutor/knappar. Det är då en god idé att sätta ett <fieldset> runt kryssrutan/rutorna respektive radioknapparna, och att ha ledtexten som <legend>, så det blir tydligt vilken grupp den hör till. Se Gruppera och namnge formulärets delar, sid 273 .

• Knappar har etiketten som text ovanpå sig.

Placeringen av etiketten är viktig för både seende och blinda. För seende är sammankopplingen automatisk om texten är placerad på ett vettigt sätt i förhållande till kontrollen. För synskadade gäller faktiskt samma sak – skärmläsare är duktiga på att gissa vilken text som hör till vilken kontroll så länge layouten inte är alltför rörig.

Det är naturligtvis ändå inte tillfredsställande att skärmläsarna tvingas gissa, så för att öka tillförlitligheten finns två saker man kan göra:

• Använd en tabell för formuläret. Genom att placera etikett och kontroll i samma tabellcell, eller i cellerna omedelbart efter varandra ges skärmläsaren en tydlig signal om att de hör samman.

• Använd HTML-elementet <label>. Detta är den lösning som rekommenderas av WCAG och krävs av 24-timmarswebben. Man måste dock vara medveten om att det i dagsläget inte kan användas som ensam lösning eftersom alla skärmläsare ännu inte stöder <label>, så att placera etiketten rätt är också nödvändigt.

Se även WCAG 10.2 (prioritet 2), sid 364 , och 12.4 (prioritet 2), sid 367 .

• Bör - undantag, se boken
• www.anvandbart.se/ab/etikett-textfalt

Ibland ser man etiketter eller instruktioner stå inuti textfältet. Det är en dålig idé av flera skäl:

• Användare kan se att fältet redan har text och hoppa över det, i tron att det är ett förval.

• Texten försvinner när användaren börjar skriva. Enda sättet att få tillbaka instruktionen är vanligen att ladda om sidan.

• Texten måste ofta vara väldigt kort för att få plats (vilket i och för sig kan vara en nyttig begränsning). Se även Sidorna måste vara användbara även när användaren ställer in en större textstorlek , sid 49 .

• Ofta finns det ingen vettig instruktion att ge och man ser därför kontroller med pratiga nonsensinstruktioner som ”Skriv din sökning här”.

Detta sagt finns det situationer där det är väldigt trångt om utrymme och där valet står mellan att ha texten i fältet eller inte alls. Om det inte är möjligt att ändra layouten kan det trots allt vara det bästa alternativet att placera etiketten eller instruktionen där. Gör den då gärna grå (utan att göra den så blek att den bryter mot Gör kontrasten mellan text och bakgrund tydlig, sid 66 ) och gör ett javascript som tar bort texten och gråheten när användaren kommer till fältet.

En kontroll som däremot kan ha instruktioner i sig är valboxen. Se Valboxar där inget alternativ skall vara förvalt kan inledas med en instruktion , sid 255 .

• Tips
• www.anvandbart.se/ab/instruktion-kontroll

För en del kontroller räcker inte etiketten. Det kan behövas ytterligare instruktioner, förklaringar eller hjälptexter.

Detta är ett problematiskt område. Användartester och erfarenhet visar tydligt att användare sällan läser instruktioner. De ger sig på formuläret direkt och improviserar sig fram. Det är därför avgörande att formuläret är så självförklarande som möjligt. Ju närmare mellan kontroll och text, desto större chans att den blir läst, så ge inte instruktionerna i ett textblock i början av formuläret utan dela upp dem och sätt dem tillsammans med de kontroller de handlar om.

Om en instruktion eller hjälptext är mycket omfattande kan det ibland uppstå behov av att öppna ett nytt fönster med den (se i sådant fall Nytt fönster , sid 329 ), men ofta är det ett bättre alternativ att ladda om sidan (rädda de inmatningar användaren redan gjort!), denna gång med den omfattande hjälptexten intill kontrollen.

• Tips
• www.anvandbart.se/ab/instruktion-exempel

Undvik abstraktioner. Skriv hellre ”Datum (t.ex. 2005-07-18 )” än ”Datum (enligt mönstret åååå-mm-dd)”, och hellre ”Kreditkortsnummer (16 siffror, t.ex. 1234-5678-9012-3456)” än ”Kreditkortsnummer (####-####-####-####)”.

• Skall
• www.anvandbart.se/ab/koppling-instruktion

För att instruktioner, exempel och hjälptexter skall vara tillgängliga måste det vara tydligt vilken kontroll de hör till. För detta finns flera metoder:

• Instruktionen läggs som title-text till kontrollen ¹¹

Ofta en bra lösning tillgänglighetsmässigt eftersom skärmläsaren läser upp texten när användaren kommer till kontrollen (till skillnad från instruktioner som placerats efter den och som hon därför inte hör innan hon redan är klar).

En seende användare får title-texten när hon för pekaren över kontrollen (men tyvärr inte om hon går med tabbtangenten). Hon kan dock inte se den samtidigt som hon till exempel skriver i ett textfält.

För den som följer 24-timmarswebben är title den lösning som skall användas.

• Placering och utseende

Instruktioner bör placeras till höger om eller under kontrollen. Sätts gärna med mindre text än etiketten, eftersom det ger användaren en ledtråd om vilken sorts text det är.

Alternativt kan korta instruktioner sättas i parentes efter ledtexten.

• I <label>-elementet

Detta ger en stark koppling mellan kontroll och instruktion men har ett par icke önskvärda följder: skillnaden mellan etikett och instruktion blir oklar, och även instruktionen blir klickbar.

Se även Koppla samman kontroll och felmeddelande, sid 277 , om hur felmeddelanden samordnas med detta.

Välj rätt tilltal

I ett formulär finns två röster: webbplatsen som ber om information, samt användaren som svarar och som använder formuläret för att be webbplatsen göra saker (speciellt när formuläret används för att styra en webbapplikation).

När dessa röster blandas gäller det att hålla tungan rätt i mun. Se Bestäm om webbplatsen talar med användarens, avsändarens eller en neutral röst , sid 90 .

• Skall - undantag, se boken
• www.anvandbart.se/ab/arbetsriktning

Räkna inte med att användaren har överblick över hela formuläret. Lägg upp det så att man kan fylla i det från vänster till höger och uppifrån ner. skicka-knappen bör finnas längst ner, och till höger i formuläret (om det finns en rensa- eller avbryt-knapp skall den dock ligga till höger om skicka-knappen).

Låt även tabbordningen följa detta mönster. (Se Gör tabbordningen logisk och förutsebar, sid 230.)

• Tips
• www.anvandbart.se/ab/raka-vansterkanter

Råden i Välj rätt kontroller, sid 280 , måste vägas mot formgivningens behov. Det kan bli alltför rörigt att blanda många olika sorters kontroller på samma formulär.

Sträva efter att göra det enklare för ögat genom att hålla raka vänsterkanter på både etiketterna och kontrollerna.

Alternativet att istället ge etiketterna rak högerkant och kontrollerna rak vänster – så kallad julgranslayout – är möjligt, men mindre lyckat. Det ger visserligen en tydlig koppling mellan etikett och kontroll, men den ojämna vänsterkanten gör det svårare för ögat när det försöker hitta början på nästa etikett.

Betona hellre sambandet mellan etikett och kontroll med hjälp av luft eller linjer.

• Bör. 24-timmarswebben: Skall
• www.anvandbart.se/ab/gruppera-formular

Ofta finns det i ett formulär kontroller som hör samman. Dessa bör grupperas och få en etikett som berättar deras gemensamma tema. På så sätt får kontrollerna ett sammanhang och användaren kan fundera över en aspekt i taget.

För en seende användare räcker det med en klok användning av luft eller linjer för att göra formulärets struktur uppenbar. Det är viktigt att vara konsekvent med hur luften används. Använd samma avstånd mellan kontrollerna inom en grupp, och på motsvarande sätt mellan grupperna, annars kan ögat lätt luras att se grupperingar där det inte finns några.

För den som hör webben via en skärmläsare säger inte luften något. Därför finns HTML-elementet <fieldset>, som uttryckligen skapar dessa grupper. Det finns även <legend>, som ger ett <fieldset> en etikett.

Om det finns grupper och undergrupper kan <fieldset> läggas inuti varandra.

Se Gruppera formulär för tips om kodning.

<legend> kan vara ett bra ställe att berätta om den aktuella delen av formuläret inte är obligatorisk, eftersom användaren då vet att det är möjligt att hoppa över hela den gruppen utan att behöva undersöka varje fält för sig.

När <fieldset> används i sin råa version, utan formatmall, lägger den en ram runt sin grupp. Det gör formulärets struktur väldigt tydlig, men layouten blir lådig.

Möjligheten att påverka utseendet med formatmallar varierar från webbläsare till webbläsare. Framförallt hanterar de placeringen av <legend> olika.

Se även WCAG 12.3 (prioritet 2), sid 367.

• Skall
• www.anvandbart.se/ab/kontroller-inaktiva

Om en kontroll för tillfället inte är meningsfull, bör den visas som inaktiv. Det får gärna också finnas instruktionstext som förklarar varför kontrollen är inaktiv. Instruktionstexten kan läggas i kontrollens title, så att den syns bara när man för muspekaren över kontrollen (detta är en kompromiss mellan två principer, den att man inte skall behöva leta runt efter osynliga instruktioner, och den att inte fylla användargränssnittet med alltför många detaljer).

• Bör
• www.anvandbart.se/ab/textfalt-siffror

Textfält för siffror bör normalt högerjusteras. Speciellt viktigt är detta när flera fält ligger över varandra, eftersom det underlättar att jämföra olika tal.

• Skall
• www.anvandbart.se/ab/markera-obligatoriska

För att markera vilka uppgifter användaren måste fylla i (till skillnad från dem som är frivilliga) skall etiketterna markeras med en röd fet asterisk. Det skall också finnas en tydlig instruktion typ ”Uppgifter markerade med * måste fyllas i.”

Ännu bättre blir det om formuläret delas i två delar, där den första halvan är obligatorisk och den andra frivillig. Observera att de röda asteriskerna är en så pass stark konvention att de ändå bör sättas ut vid varje etikett i den obligatoriska delen.

En uppdelning gör formuläret enklare för användaren – men ökar naturligtvis risken att hon helt hoppar över de icke-obligatoriska fälten.

• Tips
• www.anvandbart.se/ab/tvinga-inte

Om en uppgift görs obligatorisk måste det vara tydligt för användaren varför den är nödvändig och vilken nytta hon har av att lämna den. Om inte detta är helt klart bör det finnas alternativ typ ”vet inte”, ”ännu ej bestämt” eller ”vill inte uppge”, annars leder det lätt till att användare fyller i vad som helst som systemet godtar, för att komma vidare.

Om man inte kan kontrollera att användarens svar är korrekt (och det kan man praktiskt taget aldrig) är risken stor att obligatoriet gör att man istället för ingen uppgift får en felaktig uppgift. Det är därför som amerikanska sajter som kräver att man fyller i en adress har en stor andel av sina användare från postnummerområdet 90 210 - Beverly Hills, eftersom en populär TV-serie gjort att detta är ett postnummer icke-amerikaner känner till.

• Tips
• www.anvandbart.se/ab/validering-fria

Det är lätt att göra upp regler men svårt att förutse undantagen. Användaren kan ha goda anledningar att mata in på ett sätt du inte förutsett, och du bör så långt möjligt tillåta detta. Till exempel kan man tänka sig att en användare skriver ”Maila hellre än ring” i telefonnummerfältet (ett stycke information som kan vara ytterst betydelsefull, eftersom relationen med användaren kan byggas eller rivas av hur väl du klarar att ta hänsyn till hennes önskemål).

Detta måste naturligtvis balanseras mot behovet av datakvalité och konsekvenserna av att felaktiga uppgifter lagras.

• Bör
• www.anvandbart.se/ab/nummer-tecken

Människor kan skriva nummer på många olika sätt och många nummer innehåller inte bara siffror.

Ett telefonnummer kan till exempel innehålla plustecken, teser, snedstreck, parenteser, bindestreck och mellanslag.

Ett personnummer kan innehålla mellanslag och bindestreck.

En summa pengar kan innehålla mellanslag, och sätten att avskilja ören är flera: kolon, punkt och komma.

Tal kan innehålla mellanslag.

Exakt var som tillåts beror naturligtvis på vad det är för sorts tal och vad du har för avsikt att göra med det. Men om det är ett nummer (som telefon- eller kontokortsnummer) där det finns flera vanliga sätt att skriva dem skall du tillåta dessa sätt, inte tvinga användaren att ge sig in på en gissningslek om hur just din webbplats vill ha dem.

Fältet som numret skrivs in i måste tillåta så många tecken som varianterna kräver. Se Begränsa inte hur mycket text som kan skrivas in, sid 257.

• Skall
• www.anvandbart.se/ab/validering-fel

Underlätta för användaren när något blivit fel – till exempel när hon inte fyllt i alla obligatoriska uppgifter eller när hon matat in fel:

• Visa formuläret igen, men med en väl synlig text som förklarar att inte alla uppgifter är korrekt inmatade och en innehållsförteckning över felen (även när det bara är ett) med länkar till respektive kontroll. Sätt ett ankare på den och gå direkt dit när sidan laddas; detta gör det lättare för synskadade.

• Kontrollera hela formuläret och visa alla fel med en gång.

• Markera tydligt var det blivit fel, till exempel genom att ge de kontroller som fallerar en 2 punkter tjock röd ram kring sig.

• Sätt en framträdande text nära kontrollen som berättar vilket sorts fel det blivit och hur det kan rättas till. Ge gärna exempel på korrekta svar.

Se även Ge artiga och begripliga felmeddelanden, sid 327.

• Skall
• www.anvandbart.se/ab/koppla-felmeddelande

För att vanliga användare men framförallt för att synskadade skall kunna begripa vilket fält felmeddelandet hör till, måste de kopplas samman. Samma metoder kan användas som i Koppla samman kontroll och instruktioner, sid 271 - men felmeddelandetexten skall inte göras diskret.

Felmeddelandet får inte ersätta instruktionstexten, om det inte i sig innehåller instruktionerna.

• Skall
• www.anvandbart.se/ab/validering-rattahjalp

• Bevara den inmatade informationen så att bara det som blivit fel behöver matas in igen. Ett undantag är lösenordsfält, som alltid skall tömmas (om inte användaren uttryckligen bett webbplatsen komma ihåg hennes lösenord, se Gör det lätt att bli glömd, sid 318).

• Om du tror det underlättar för användaren, låt även det som blivit fel stå kvar, så att användaren kan ändra det istället för att bli tvungen att mata in det på nytt.

• Om felet består i att inmatningen inte kan tolkas entydigt, överväg att låta användaren välja i en lista över de olika möjliga tolkningarna.

• Tips
• www.anvandbart.se/ab/validering-javascript

De formulärfunktioner som finns i HTML är ganska primitiva. Därför är ofta möjligheten att bättra på funktionerna med hjälp av javascript mycket välkomna, inte minst för att göra formulären lättare att använda och för att omedelbart kontrollera inmatningar och säga till när det blivit fel.

Observera att löpande kontroll måste ske på ett sätt som fungerar för alla användare. Se Ändra inte innehåll på sidan utan att ge användaren en möjlighet att bli uppmärksammad på detta, sid 431, och Flytta inte fokus , sid 431.

Ett enklare alternativ är att låta javascript kontrollera formuläret när användaren klickat skicka-knappen. Vinsten med detta är inte så stor eftersom samma kontroll ändå måste göras på webbservern, men det minskar serverbelastningen och ger användaren svar litet snabbare.

Även om javascript används för kontrollen måste motsvarande kontroll även göras på webbservern när den tar emot formuläret. På detta sätt kan även användare utan javascript använda det (även om de inte får samma omedelbara reaktion), och felaktigheter får svårare att smita in.

• Tips
• www.anvandbart.se/ab/tunnel

En metod för att hindra att användaren lämnar formuläret är tunneln. Grundidén är att formuläret skall fungera som en biltunnel – när man väl kört in i den finns det ingen möjlighet att lämna vägen, man måste följa den tills man kommer ut i andra änden.

En mer komplicerad tunnel kan grena sig så att det finns flera vägar att köra och flera ställen att komma ut på – men även i det fallet är det webbmakaren som har precis kontroll över hur användaren kan röra sig.

På den sida (eller de sidor) som ingår i tunneln skall det inte finnas några länkar som leder bort från sidan. Det enda sättet att lämna den är att antingen köra till slutet – skicka-knappen - eller att uttryckligen klicka på avbryt-knapp­en.

Denna nödutgång är viktig, meningen med tunneln är naturligtvis inte att stänga in användaren, bara att skydda henne mot att oavsiktligt förlora det hon gjort.

Tunneln är tydligt inspirerad av vanliga programs dialogrutor. Vill man driva denna likhet längre kan man öppna formuläret i ett separat modalt fönster. Modalt betyder att det inte uppför sig som ett vanligt webbläsarfönster utan alltid ligger kvar överst, tills man uttryckligen stänger det. Se sid 331.

Tunneln är inget idiotsäkert skydd. I en webbläsare finns alltid sätt att avbryta som ligger utanför webbplatsens kontroll. Användaren kan till exempel skriva in en ny adress, välja ett bokmärke eller stänga fönstret. Det är möjligt att fånga även sådant med hjälp av javascript, men personligen tror jag det är bättre att acceptera att detta är det sätt webben fungerar på och trösta sig med att risken för dessa handlingar är betydligt mindre än för att användaren obetänksamt klickar på en länk.

Skyddsnät

• Tips
• www.anvandbart.se/ab/skyddsnat

En annan strategi är att skapa ett skyddsnät som fångar upp användaren om hon är på väg att lämna formuläret. För detta krävs javascript. Om användaren börjat fylla i ett formulär och klickar på en länk innan hon avslutat det, visar skriptet en dialogruta som berättar att hon inte fyllt i formuläret färdigt och artigt frågar om hon vill avbryta arbetet med formuläret eller stanna.

Skyddsnätet bör helst aktiveras först när användaren börjat fylla i formuläret och det alltså finns ansträngning nedlagd som riskerar att gå förlorad. Ett tekniskt enklare alternativ är att fråga användaren så snart hon försöker lämna sidan, vare sig hon börjat fylla i eller ej.

Eftersom skriptet i detta fall bara är en säkerhetsåtgärd, inte något som behövs för själva funktionen, är lösningen inget hinder för de användare som inte har javascript.

• Tips - undantag, se boken
• www.anvandbart.se/ab/flersidiga-undvik

Att dela upp ett formulär över flera sidor öppnar för en mängd användbarhetsproblem. Sträva därför i första hand efter att låta det rymmas på en sida.

Detta sagt finns det naturligtvis tillfällen då formuläret måste delas.

Det är till exempel fallet om man vill anpassa senare delar av formuläret utifrån de svar användaren ger.

Långa formulär (mer än tre skärmhöjder på en 1024 x 768-skärm) kan behöva delas upp för att göra dem överskådliga. Ta dock inte måttet alltför bokstavligt – det är viktigare att dela formuläret i naturliga avdelningar, så att användaren känner att hon avslutat ett sammanhang innan hon går vidare, än att hålla sig till ett bestämt mått.

I Guide , sid 288, finns en modell för hur denna uppdelning kan göras.

• Bör - undantag, se boken
• www.anvandbart.se/ab/uppdelad-inskrivning

Sträva efter att låta användaren skriva in uppgifter som hänger samman i ett svep. Ibland kräver dock databehandlingen att uppgifterna delas upp, och då får du bortse från detta råd.

Låt helst användaren skriva in hela sitt namn i ett fält.

Om det är nödvändigt för databehandlingen att få efternamnet separat, dela in det i två fält ordnade så att förnamnet skrivs först.

Gatunamn och -nummer hänger samman

I en adress är det inte så bra att ha ett särskilt fält för gatunumret.

Däremot är det ok att postnummer och postort har olika fält.

Adresser

Om inte uppdelning är nödvändig för databehandling, låt adressfältet vara ett flerradigt textfält, som gjorts lagom högt för tre rader. (Räkna dock med möjligheten att du får in svar på fler än tre rader, t.ex. för utländska adresser.)

Om du ber att få adressen i mindre delar, tänk på att många länder har ett annat adressformat än Sverige. Om du frågar efter adress och det inte är säkert att den är svensk, bör formuläret anpassas så att den ändå går att mata in korrekt.

(Detta är ett exempel på när ett underformulär kan vara användbart, se Flersidiga formulär , sid 280.)

• Skall - undantag, se boken
• www.anvandbart.se/ab/flervalskontroll-ett-inget

Ibland ser man ”valmöjligheter” där det bara finns en sak att välja. Eller inget alls.

Nästan undantagslöst är detta resultatet av att kontrollen fylls på från en databas. Den är utformad för att hantera många alternativ, men ibland finns det bara ett eller inget alternativ i databasen och kontrollen blir som en enpartistat – man får välja, men det finns inget att välja mellan.

Om det finns bara ett alternativ eller inget alls, är det systemets ansvar att presentera detta på ett vettigt sätt. Antingen som underförstått och något som inte syns alls. Eller som en informationstext om vad som gäller.

Systemet får inte av lättja presenterar detta i samma form som när det finns flera alternativ och därigenom lasta på användaren att försöka gissa vad som menas.

Det finns dock kontroller som fungerar även när det bara finns en sak att välja.

• Tips
• www.anvandbart.se/ab/guide-alternativ

Guider har ett stort pedagogiskt värde både för nybörjaren och för den som inte använder funktionen så ofta, men kan vara frustrerande långsam för den vane användaren, speciellt om hon tvingas gå igenom den många gånger. I dessa fall kan det vara uppskattat att ge ett avancerat alternativ, där alla uppgifter samlats i en betydligt kompaktare form.

Samla – granska – godkänn - bekräftelse

Ofta består guiden av tre eller fyra distinkta delar:

• Först ett antal sidor där information samlas in från användaren.

• Därefter en sida där användaren kan granska det hon matat in.

• När användaren är nöjd godkänner hon genom att klickar på sammanställningens skicka-knapp (ibland döpt till ”Slutför”, ”OK” eller ”Jag har granskat och vill skriva under”). Det är inte alltid sammanställningen är ett formulär, men den brukar ändå ha en knapp för att vara konsekvent med de andra guide-sidorna. Det är först i och med godkännandet som användarens inmatning får konsekvenser. Innan dess har det bara varit en insamling av information.

I och med godkännandet passerar användaren i en del applikationer en punkt bortom vilken hon inte längre kan gå tillbaka och ändra. Se Utan återvändo , sid 298 .

• Till slut får hon i många webbapplikationer också en bekräftelse , till exempel genom att komma till den sida som skapats eller ändrats av hennes inmatningar eller i form av ett kvitto.

Det skall dock betonas att det finns gott om mindre guider där en eller flera av dessa delar inte finns med och där till exempel användarens val får effekt direkt, utan att vänta på en sammanställningssida och ett godkännande.

Det finns också speciella rekommendationer om hur dessa steg bör utformas för myndigheters e-tjänster, se Myndigheters e-tjänster, sid 299 .

• Skall
• www.anvandbart.se/ab/guide-skydd

För att inte riskera att användaren tappar spåret brukar guiden skyddas av en tunnel (sid 279 ) eller ett skyddsnät (sid 279 ).

• Skall. 24-timmarswebben: se boken
• www.anvandbart.se/ab/guide-avbrott

Det måste alltid vara möjligt för användaren att lämna guiden. Ofta ges denna möjlighet i form av en avbryt-knapp. När användaren klickar på den skall hon föras till sidan hon var på innan hon gick in i guiden (det vill säga till den senaste sida hon varit på som inte var omgiven av en tunnel eller ett skyddsnät).

Om användaren passerat en punkt utan återvändo (se sid 298 ) skall det inte längre finnas någon möjlighet att avbryta, eller så måste det vara tydligt att det som skett innan denna punkt inte påverkas.

24-timmarswebben

För den som följer 24-timmarswebben gäller inte detta råd. Den rekommenderar att det skall finnas en tillbaka-knapp (se nästa råd), men att det inte bör finnas någon möjlighet att avbryta helt.

Jag har inte lyckats utröna bakgrunden till dess rekommendation, men gissar att den ligger i att medan guider här förutsätts vara inneslutna i tunnlar eller skyddsnät (se Skydda användaren mot att av misstag lämna guiden, ovan) så förutsätts det i 24-timmarswebben att det alltid finns andra sätt att lämna dem.

• Skall - undantag, se boken
• www.anvandbart.se/ab/guide-tillbaka

Det skall alltid vara möjligt för användaren att gå tillbaka och ändra inmatningar hon gjort, åtminstone fram tills hon gjort sitt godkännande.

Detta kan hanteras på flera olika sätt:

• Webbläsarens bakåtknapp

Att klicka webbläsarens bakåtknapp är en instinkt hos många användare och bör vara möjligt också i en guide. Se Låt bakåtknappen fungera, sid 202 .

• ”Föregående”

Guiden kan också ha sin egen bakåtknapp.

• Framstegsindikatorn

Om guiden har en framstegsindikator får gärna passerade steg vara klickbara och föra användaren direkt tillbaka till respektive sida. (Detta är ett alternativ som kan vara tekniskt svårgenomförbart på en del system.)

När användaren är klar med sin ändring skall skicka-knappen föra henne samma väg framåt igen (försök alltså inte underlätta genom att hoppa över oförändrade mellansidor).

Bistå om möjligt användaren genom att komma ihåg och fylla i så många uppgifter som möjligt (det vill säga alla som inte påverkats av det som hon gick tillbaka och ändrade) på vägen framåt.

Utan återvändo

Om användaren passerat en punkt utan återvändo skall det inte vara möjligt att backa tillbaka förbi denna – se Utan återvändo , sid 298 .

• Skall Förutsättningar, se text
• www.anvandbart.se/ab/guide-andra

Om det inte finns sidor i guiden som är beroende av vad som matats in tidigare, kan man låta användaren gå direkt från sammanställningen till rätt ändringsformulär istället för att backa.

Detta görs ofta genom att dela in sammanställningen på samma sätt som inmatningen av uppgifterna delats på olika sidor. Till varje område hör en ”Ändra”-knapp som tar användaren till ett formulär för det aktuella området, förifyllt med de uppgifter hon tidigare matat in, där hon kan göra sina ändringar.

Observera att det inte är fråga om att hoppa tillbaka i flödet, även om formuläret mycket väl kan vara en kopia av det som redan fyllts i på ett tidigare steg. skicka-knappen skall ta henne tillbaka till översiktssidan, inte vandra framåt till nästa steg.

Topologin blir densamma som hos hjulet (sid 293), med sammanställningen som nav och formulären som ekrar.

• Skall
• www.anvandbart.se/ab/ekrar-skydda

Navet skall vara den enda sida varifrån man skall kunna lämna hjulet. Eker­sidor­na läggs i tunnlar (se sid 279) och avbryt-knappen på dem leder tillbaka till navet.

• Bör - undantag, se boken
• www.anvandbart.se/ab/ekrar-ensidiga

Hjulet har en enkel lättfattlig topologi. Det har sitt centrum som man gör snabba utstickare från och sedan direkt återkommer till. För att inte bryta denna tydlighet bör varje utstickare från centrum leda till en ekersida och sedan tillbaka igen.

Ibland görs dock undantag från detta. Om ekersidan visar detaljinformation kan det vara motiverat att man från denna direkt kan nå ett formulär för att ändra.

Så kan till exempel vara fallet för webbaserad e-post . Navet visar listan över alla e-brev. När man klickar på ett brev får man upp en sida där man kan läsa det. När man stänger det kommer man tillbaka till navet – men om man vill svara kommer man istället till ett formulär för att skriva. Först när man skickat svaret kommer man tillbaka till navet.

• Skall
• www.anvandbart.se/ab/ekrar-oberoende

Användaren skall fritt kunna välja vilka ekersidor hon går till och i vilken ordning. Det får inte finnas beroenden mellan dem så att en måste klaras av före en annan.

• Skall - undantag, se boken
• www.anvandbart.se/ab/piruett-bekrafta

Genom att den minimerar antalet klick och sidobyten kan piruetten vara en mycket effektiv form. Men samma sak kan också göra den förvirrande.

Den största källan till förvirring ligger i att den bryter radikalt mot webbens vanliga sätt att fungera. Normalt när användaren klickar på skicka-knappen får hon en tydlig bekräftelse på att webbservern uppfattat hennes klick genom att sidan byts.

Som kompensation måste piruetten därför på något annat mycket tydligt sätt bekräfta användarens klick.

”Sidan är sparad…”

En vanlig lösning är att det högt upp på sidan dyker upp en visuellt framträdande text som säger att sidan är sparad.

Denna lösning är på sätt och vis ur askan i elden – för nu stöter man ihop med ett en annat av webbens grundläggande funktionssätt: det som är sant när sidan kommer till webbläsaren kan vara en lögn en minut senare (se Skillnader mot traditionella applikationer, sid 286 ). Så snart användaren börjar arbeta vidare med sidan stämmer inte längre beskedet att den är sparad.

För att lösa detta bör sidan ha ett javascript som tar bort sparad-beskedet så snart arbetet återupptas. (Eftersom det är en hjälp, inte en nödvändighet, gör det inget om användaren inte har javascript. Inte heller är detta så viktigt att det finns anledning att uppmärksamma användaren på det – det skall alltså inte följa Ändra inte innehåll på sidan utan att ge användaren en möjlighet att bli uppmärksammad på detta, sid 431 .)

Pågående arbete

Om användaren bara är ute efter att spara ett pågående arbete står man inför ytterligare ett dilemma.

För att hon skall märka att något hänt bör sidan laddas om och hennes fokus flyttas till överkanten (där beskedet om att den är sparad dyker upp).

För att hon bekvämt skall kunna arbeta vidare bör hennes fokus (till exempel var markören befann sig i en text hon höll på att skriva) sparas och sedan återställas. Detta kan medföra att användaren överhuvudtaget inte ser beskedet om att sidan sparats – det kan ju befinna sig ovanför skärmens överkant. Å andra sidan skulle det vara en irritationskälla för henne att behöva leta upp stället där hon arbeta omigen.

En möjlighet kan vara att använda javascripts alert-funktion för att berätta att arbetet framgångsrikt sparats. Även detta kan bli irriterande, men är ibland ändå det bästa av alternativen.

• Skall
• www.anvandbart.se/ab/punkt-uppmarksamma

Var tydlig när användaren står inför en handling som inte kan ångras. Det betyder inte att hon måste utsättas för varningstexter eller dialogrutor, men det är viktigt att hon förstår att hon är på väg att göra inte är återkallerligt (åtminstone inte på något enkelt sätt).

Ofta framgår det av sammanhanget – på en e-handelsplats brukar det till exempel sammanfalla med att användaren godkänner att pengar dras från kontokortet.

• Skall
• www.anvandbart.se/ab/punkt-backa

Användaren skall så långt möjligt hindras från att återvända förbi en punkt utan återvändo. Detta är ett av de få fall då webbläsarens bakåtknapp inte skall fungera. Felmeddelandet bör dock inte vara det kryptiska ”Page has expired”, utan tydligt berätta varför det inte går att backa.

• Tips
• www.anvandbart.se/ab/punkt-undvik

Att göra något oåterkalleligt är alltid litet skrämmande och kan få användare att stanna till och kanske hoppa av från en process de påbörjat. För exempelvis en e-handelsplats kan detta innebära förlorade kunder.

Sträva därför alltid efter att minimera ångesten genom att göra det möjligt för användaren att ändra sig så långt det bara är möjligt.

Ett exempel på hur det kan göras är Amazon. Naturligtvis finns det även i deras kassaprocess en punkt där användaren skickar sin beställning, men de bemödar sig att göra denna mindre dramatisk genom att det hos dem alltid är möjligt att gå in och ändra eller avbeställa en order ända fram tills de packat och skickat den.

• Tips
• www.anvandbart.se/ab/etjanstemonster

Eftersom många användare utsätts för dem har myndigheternas utformning av sina e-tjänster ett starkt inflytande på vilka konventioner som utvecklas. Genom att följa samma flöde, och använda samma symboler och formuleringar ökar du chanserna att användarna slipper fundera över hur din webbplats fungerar; www.anvandbart.se/ab/etjanstemonster länkar till de vägledningar som finns för dem.

Bild 112. Symbol för säker autentisering eller legitimering.

Mönstret inleds med att användaren identifierar sig så att systemet vet vem hon är och vad hon har rätt att se.

Detta steg torde bara vara nödvändigt om tjänsten visar information om användaren eller behöver veta hennes identitet för att anpassa vad som kan göras.

Identifieringen kännetecknas av symbolen i Bild 112, och av en knapp med texten ”Jag legitimerar mig”.

Detta kvitterar webbservern med ”Du är identifierad som [namn]”.

När användaren är identifierad kan hon utföra sitt ärende.

Bild 113. Symbol för att granska.

När hon är klar får hon en sammanställning att granska. (Bild 113).

I den mest uppdelade varianten följer nu en trestegsprocess:

• Användaren klickar på knappen ”Jag skriver under” (Bild 114) och legitimerar sig.

• Användaren klickar därefter på knappen ”Skicka” (Bild 114).

• Webbservern svarar med ”[Handlingen] har kommit in till [myndighetens benämning]”.

Bild 114. Symboler för att skriva under och skicka.

Vanligen slås dock steg ihop. Så är det till exempel hos Skatteverket, där användaren efter att ha granskat klickar på knappen ”Jag har granskat och vill skriva under”, som underförstått också sänder iväg handlingen.

Observera att användaren måste bevisa sin identitet två gånger – både för att börja använda tjänsten och för att slutföra det hon gjort på den.

Symboler

De symboler som visats här är när detta skrivs bara förslag. När de är fastslagna kommer de att bli fria för alla att använda. På www.anvandbart.se/ab/etjanstemonster‌ kan du läsa mer om hur detta utvecklas och var de finns att få tag på.

Observera att ett par av symbolerna överlappar tämligen etablerade betydelser i webbvärlden. Förstoringsglaset brukar symbolisera sökning och pennan att redigera. Se därför upp så att det inte blir kollisioner med den övriga ikonografin på webbplatsen.

• Skall - undantag, se boken
• www.anvandbart.se/ab/informationshantering

En vanlig användning av webbapplikationer är informationshantering.

Det finns i grunden bara fyra saker man kan göra med information – skapa den, läsa den, ändra den och ta bort den. För att kunna göra det måste man också kunna hitta den.

Även om detta är en enkel modell, ger den en bra grund för en första rimlighetskontroll av hur väl en webbapplikation fungerar.

För varje bit information, fråga hur…

• …skapar man den?

• …hittar man den?

• …bär man sig åt för att läsa den?

• …ändrar man den?

• …tar man bort den?

Tillsammans med följdfrågan vem får lov att göra det, ger dessa en mycket god bild av applikationens användbarhet.

Det är naturligtvis inte alltid dessa fem hanteringar uppträder som helt skilda saker. Att hitta, ändra och läsa kan helt eller delvis dela samma gränssnitt. Att ändra någonting och att ta bort det, kan ibland vara likartade funktioner.

I en del sammanhang är det inte heller möjligt att göra allting. I ett arkiv eller ett banksystem är det till exempel inte alltid önskvärt att man kan ta bort eller ändra information. I ett publiceringssystem kanske man inte kan ändra i publicerade artiklar – men väl skapa nya versioner av dem.

• Skall
• www.anvandbart.se/ab/skapat-kontroll

En viktig del av att kunna skapa och ändra information är möjligheten att kontrollera att det man gjort blivit rätt.

Visserligen finns alltid möjligheten att titta igenom formuläret innan man klickar på OK. Men för de flesta människor är det mycket bättre att få se resultatet av sin handling i en förhandstitt som är så likt slutresultatet som möjligt, eller i en sammanställning.

Förhandstitten används till exempel i publiceringssystem, där den som skapar en sida kan se och kontrollera den innan någon annan ser den.

Sammanställningen är vanlig på till exempel e-handelsplatser, där användaren som sista steg innan hon skickar sin beställning får se vad den omfattar och vad den kostar.

I en del sammanhang kan dock detta extrasteg störa arbetsflödet och vara en irritation. Ett alternativ är då att ge resultatet direkt, men att göra det lätt för användaren att ändra eller ångra ifall något blivit fel.

Tidsfördröjning

En variant av förhandstitten som ibland används i applikationer där användaren inte fritt får ändra eller ta bort information, men där man inte vill störa hennes arbetsflöde, är en tidsfördröjning. Användaren kan se det hon gjort och har en begränsad tid på sig, typ 15 minuter, att reagera på felaktigheter. När sedan tiden gått ut, utan att användaren reagerat, gäller de vanliga reglerna för att ändra eller ta bort.

• Tips
• www.anvandbart.se/ab/angerratt

Stör inte användarens arbetsflöde genom att ideligen be henne bekräfta att hon verkligen vill göra det hon säger att hon vill göra.

Så långt möjligt bör det istället finnas en möjlighet för användaren att gå tillbaka och korrigera eller återkalla eventuella misstag. Bakåtknappen bör fungera när man kommer på att man gjort ett misstag och omedelbart vill gå tillbaka och korrigera detta (se Bakåtknapp , sid 202 ).

• Tips
• www.anvandbart.se/ab/pausa-inmatning

Ibland är det mycket information som skall matas in i en webbapplikation, och det är inte alltid användaren klarar att göra det vid ett och samma tillfälle. Hon kan till exempel under arbetets gång komma på att hon inte har tillgång till de uppgifter som krävs.

I sådana fall är det uppskattat om det finns en möjlighet att spara den informationen man hittills matat in och slutföra arbetet vid ett senare tillfälle.

Fler råd för webbapplikationer

Det finns även råd i andra delar av boken som är värda att tänka på i sammanhanget:

• När man går från en flik till en annan i ett formulär skall inte inmatningar gå förlorade, sid 136 .

• Ta inte bort webbläsarens kontroller, sid 332 .

• Tillåt att användaren öppnar nya fönster, sid 333 .

• Låt inte upprepade klick på skicka-knappen leda till dubblerad inmatning , sid 262 .

• Kom ihåg användaren länge, sid 309 .

• Tips
• www.anvandbart.se/ab/skapa-signatur

Även när webbplatsen vet användarens verkliga namn, händer det att hon tillåts hitta på en signatur, som är det som visas på webbplatsen. Detta är till exempel vanligt för debattforum.

Roll och kändhet

Det är lätt hänt att man blandar ihop roll och kändhet. I själva verket går de inte att skilja från varandra på de lägre kändhetsnivåerna – alla okända användare måste ha samma roll, och även om det är teoretiskt möjligt att ge olika gäster olika roller vet man inte tillräckligt om dem för att det skall vara intressant. Inloggade användare brukar, som nämnts ovan, få en gemensam roll, men det är i praktiken bara för de identifierade som man har specialiserade roller.

• Skall
• www.anvandbart.se/ab/langt-minne

Sessioner på webben avslutas när användaren under tid inte gått vidare till en ny sida (eller varit aktiv på något annat sätt som webbservern märker).

Om en inloggad eller identifierad användare vill se en ny sida på webbplatsen efter att sessionen är slut, måste hon autentisera sig på nytt.

Hur lång overksamhet som krävs för att sessionen skall avslutas blir en avvägning mellan bekvämlighet för användaren, säkerhet och i någon liten mån resursbehov.

Nackdelen med snåla system, som koppla ner redan efter kort overksamhet, är att om användaren autentiserar sig manuellt så är de en stor källa till irritation – hon tvingas logga in gång på gång. För användare med funktionshinder som gör att de arbetar långsamt kan detta göra webbplatsen helt otillgänglig.

Risken med generös tid ligger i om användaren lämnar sin dator utan att låsa den och utan att logga ut. Då kan någon annan låna den – och därmed stjäla användarens identitet.

Generös tid gör också att användare som egentligen sedan länge är klara och har lämnat webbplatsen tar upp plats i webbserverns minne. I praktiken är detta dock inte något problem om man inte har extrema mängder besökare.

Min personliga inställning är att tidsgränsen bör sättas mycket generöst, minst tio timmar. Då klarar användaren garanterat en arbetsdag med bara en inloggning, även om hon är borta mycket från datorn. (Om du frågar en säkerhetsmänniska istället för en användbarhetsmänniska är det dock möjligt att du får ett helt annat svar.)

Även med en mer restriktiv inställning bör användaren få minst en halvtimme på sig för att sidan skall kunna sägas vara tillgänglig.

Viktigare för säkerheten än att sätta en snål tid är att förse webbplatsen med en tydlig ”Glöm mig” eller ”Logga ut”-knapp.

• Bör - undantag, se boken
• www.anvandbart.se/ab/valja-losenord

Om det är viktigt att användaren inte skriver ner sitt lösenord utan håller det i huvudet, bör hon själv få välja användarnamn och lösenord.

Om det däremot är viktigt att lösenordet inte kan gissas, så bortse från detta råd och generera istället ett lösenord åt henne enligt någon av de två följande.

Eftersom användaren ofta vill använda samma användarnamn och lösenord till flera olika webbplatser bör reglerna för hur de får formuleras vara liberala.

Exakt vad som tillåts blir en kompromiss med tekniken, men om möjligt bör användarnamnet kunna innehålla svenska tecken, punkter, bindestreck, mellanslag och @-tecknet. Det bör tillåtas vara åtminstone 30 tecken långt.

Om användaren väljer ett användarnamn eller lösenord med svenska tecken, påminn henne om att sådana kan vara svåra att använda i utlandet.

Lösenordet bör inte tvingas vara längre än fyra tecken (här kan säkerhetsaspekten dock tvinga fram en högre gräns) och bör helst kunna ha alla sorters tecken i sig.

• Bör
• www.anvandbart.se/ab/ordkombinationer

Ibland behöver webbplatsen generera ett lösenord åt användaren, till exempel för att hon skall kunna logga in och byta till ett eget, eller för att säkerhetspolicyn inte tillåter användaren att välja sitt eget lösenord.

En i mitt tycke underanvänd metod att skapa lösenord (speciellt för det senare fallet) är att kombinera två ord. Detta ger ofta lösenord som är lätta att memorera och med litet tur slipper användaren då besväret att ändra det. Ännu lättare kan man göra det för minnet genom att låta det första ordet vara ett verb och det andra ett substantiv eller ett namn.

Säkerheten beror på antalet ord som kan ingå i kombinationen, men redan med en ordlista på hundra ord ger en tvåordskombination samma säkerhet som en fyrsiffrig pinkod - nästan undantagslöst mer än tillräckligt om webbplatsen har ett system för att upptäcka och blockera upprepade inloggningsförsök.

Med svenskans drygt 10 000 verb och något fler substantiv, 1 000 förnamn och 6 000 ortnamn, torde det inte vara något problem att generera lösenord som ingen gissar i första taget.

Lösenordet bör enbart bestå av små bokstäver (även när de inkluderar namn). Använd inte ord med svenska tecken om användaren skall kunna logga in från lånedatorer utomlands.

• Bör
• www.anvandbart.se/ab/korta-genererade

En alternativ metod för lösenordsgeneration är att låta det bestå av tecken som valts på slump. Människor är inte bra på att komma ihåg långa slumpmässiga teckenblandningar, men ett sådant lösenord kan å andra sidan hållas kort. Redan vid tre tecken finns mångdubbelt fler kombinationer än för en fyrsiffrig pinkod, och vid fyra är antalet över en miljon.

Lösenordet bör kunna bestå av både bokstäver och siffror. Använd inte siffrorna 0 och 1 eller bokstäverna o och l, eftersom dessa kan blandas med varandra. Använd inte svenska tecken, om användaren skall kunna logga in från lånedatorer utomlands. Använd enbart små bokstäver (att minnas blandade små och stora bokstäver är väldigt svårt och det är pilligt att skriva in dem i ett lösenordsfält).

Att ha lösenord som enbart består av siffror, så kallade pinkoder, är ett tekniskt mode som inte har någon fördel på en webbplats (om man inte också skall kunna logga in via mobiltelefon).

• Tips - undantag, se boken
• www.anvandbart.se/ab/byt-ej-losenord

Detta är ett råd vars giltighet beror på vad man tror om användarnas beteende. Om man vill att användarna skall minnas sitt lösenord, inte skriva ner det eller lagra det i datorn, är det korrekt. Om man gett upp och tror att lösenorden ändå lagras, är ett regelbundet bytande inte en jätteansträngning för användaren (om än ett irritationsmoment) och en av de få saker man kan göra för att litet öka säkerheten.

• Bör
• www.anvandbart.se/ab/losenord-gemener-versaler

Ett vanligt misstag är att råka ha skiftlåset nedtryckt, så att gemener blir versaler och vice versa (det senare dock bara på PC, inte på Macintosh).

Irriterande i vanliga fall, men kan vara direkt vilseledande när användaren skriver i lösenordsfält, där hon inte kan se vad hon skrivit.

Låt därför lösenord vara okänsliga för skillnaden mellan versaler och gemener - alternativt förstå dem även om skiftlåset är nedtryckt (så att ett lösenord som aBCd4w godkänns också om det skrivs AbcD4W eller ABCD4W).

• Bör - undantag, se boken
• www.anvandbart.se/ab/byta-anvandarnamn

Speciellt när användare tagit sin e-postadress som användarnamn kan det finnas behov av att byta ut det utan att förlora användarkontot.

Finns ingen information av värde knutet till kontot, gör det naturligtvis inget om enda sättet att byta namn är att överge sitt användarkonto och starta ett nytt.

• Skall
• www.anvandbart.se/ab/eposta-losenord

Eftersom många användare använder samma lösenord till olika webbplatser, bör det behandlas med stor varsamhet, även om säkerhetskraven för just din webbplats inte råkar vara så höga.

Sänd aldrig ut ett lösenord användaren formulerat, vare sig i en bekräftelse på att ett användarkonto skapats eller när användaren glömt sitt lösenord.

När ett lösenord skall sändas via e-post, generera ett nytt och sänd det tillsammans med instruktioner om hur man byter till det lösenord man önskar. Om säkerhetskraven är höga, kan det postade lösenordet vara engångs och bara ge tillgång till sidan där man byter lösenord.

• Skall
• www.anvandbart.se/ab/glomt-losenord

Att användare ibland glömmer sitt lösenord är inget som går att undvika. Därför måste det finnas något sätt att få ett nytt lösenord.

• Personlig kontakt

Den säkraste metoden är att tvinga användaren personligen kontakta hjälpcentralen (supporten) för webbplatsen. Detta är dock mycket resurskrävande (speciellt i slutet av sommaren när folk kommer hem efter semestern), och används bara för webbplatser där säkerhetskraven är mycket höga eller för intranät där det är enkelt att få personlig kontakt.

• Vanligt brev eller SMS

Något mindre resurskrävande är om användaren via webbplatsen kan be att få ett lösenord sänt till en adress som finns registrerad för henne – till exempel som vanligt brev eller som SMS-meddelande. Om säkerhetskraven är höga kan det skickas i rekommenderat brev.

• E-post

En mycket vanlig variant är att användaren kan få lösenordet e-postat till en adress hon uppgav i samband med att hon skapade användarkontot. I dessa fall bör ett nytt lösenord genereras, se föregående råd.

Många användare har utvecklat vanan att inte hålla reda på lösenord för webbplatser som inte är viktiga för dem, utan använder istället regelmässigt ”Glömt lösenordet?”-funktionen.

Säkerheten hos denna metod är låg.

• Kontrollfrågor

En variant är att användaren i samband med registreringen fått skapa en fråga och ett svar. Vill hon ha lösenordet får hon frågan och måste ge svaret.

Säkerheten är låg - speciellt om det finns färdiga alternativ för kontrollfrågor. Den som tagit reda på användarens födelseort och mammans flicknamn har goda chanser att knäcka den.

Därför är det även i detta fall nödvändigt att generera ett nytt lösenord istället för att avslöja det användaren givit.

Säkerheten blir något bättre om användaren själv får formulera frågan, men inte heller då är den särskilt hög.

Engångslösenord

Ett sätt att avsevärt höja säkerheten hos inloggning är att förse användaren med engångslösenord, som hon får från till exempel ett skrapkort eller en dosa. Eftersom varje lösenord bara kan användas en gång är risken att de skall hamna i orätta händer betydligt mindre.

Certifikat

Ett certifikat är som ett papper där det står ”härmed intygas att innehavaren av detta papper är Ann Andersson” ¹⁶. Certifikatet laddas ner till eller installeras på användarens dator och används sedan för att autentisera henne.

Certifikaten skapar ett slags superlösenord, som i praktiken är omöjliga att förfalska. Därför ingår certifikat numera som en del av nästan alla lösningar som kräver hög säkerhet.

Certifikatet skulle inte vara mycket värt om vem som helst som kommer över datorn kan använda det. Därför krävs det nästan alltid någon slags autentisering på användarens dator innan certifikatet går med på att intyga användarens identitet. Det kan vara ett lösenord eller, i avancerade fall, ett pekfinger på datorns fingeravtrycksläsare .

Certifikat behöver inte nödvändigtvis förvaras på datorn, de kan också till exempel finnas lagrat i en krets på ett id-kort. Sådana certifikat kallas hårda , och betraktas allmänt som betydligt säkrare än de mjuka som förvaras på datorn.

Till de hårda metoderna brukar man räkna även andra där det krävs att användaren har tillgång till något fysiskt föremål (utöver datorn) – till exempel ett skrapkort eller en dosa med engångskoder. (Däremot är det tveksamt om identifiering via mobiltelefon kommer att kvalificera sig som hård metod – mobiltelefoner är en slags datorer och möjliga att hacka.)

Även om certifikaten i sig är säkra så finns det svaga länkar. Speciellt mjuka certifikat kan knäckas genom att avlyssna användarens dator efter lösenordet och kopiera certifikatsfilerna. Många kritiker menar därför att mjuka certifikat inte duger för tillämpningar som kräver hög säkerhet, medan försvararna menar att säkerheten är tillräcklig och att krav på hårda certifikat medför onödigt mycket krångel. På www.anvandbart.se/ab/certifikat hittar du länkar till några inlägg i debatten.

Autentisering via annat system (single sign-on)

För intranät och för webbplatser som är uppbyggda av flera olika system, är det vanligt att användaren loggar in på ett ställe och sedan autentiseras på de andra systemen därifrån. Detta brukar kallas singelinlogging eller single sign-on (eftersom användaren bara behöver logga in en gång).

Låt någon annan sköta autentiseringen

Att autentisera användaren med samma säkerhet som om hon personligen skulle visa upp ett id-kort är inte trivialt. Det kräver en betydande insats både av användaren (som till exempel måste hämta ut ett rekommenderat brev med lösenordet) och av webbplatsen. Därför är det för många webbplatser inte realistiskt att bygga upp sitt eget system.

Istället håller det på att utvecklas allmänna system. Till exempel bankerna, som var tidigt ute och nu ett gemensamt system kallat BankID , och Posten som har lanserat ett elektroniskt id-kort med inbyggd datorkrets. Andra organisationer kan (mot en avgift) använda dessa för att identifiera sina användare.

Automatisk autentisering

• Tips. 24-timmarswebben: se boken
• www.anvandbart.se/ab/sparad-autentisering

Ett sätta att göra tillvaron mycket enklare för användaren – till priset av kraftigt sänkt säkerhet – är att automatiskt autentisera henne när hon kommer till webbplatsen nästa gång. Det enda som krävs är att hon använder samma dator. (Eller för att vara exakt, är samma användare på datorn och använder samma webbläsare.)

På ett tekniskt plan görs detta genom att en permanent kaka sparas. Se vidare Kakor , sid 325 .

Säkerheten för den här sortens autentisering är naturligtvis låg, eftersom den är knuten till användarens dator istället för till henne själv. Samtidigt är bekvämligheten hög, när användaren väl loggat in första gången behöver hon sedan aldrig tänka på det igen. För många webbplatser som inte hanterar känslig information, är detta rätt avvägning.

24-timmarswebben rekommenderar dock att man om möjligt inte använder automatisk autentisering.

• Bör
• www.anvandbart.se/ab/glom-mig

En situation där automatisk autentisering inte är bra är när användaren lånar en dator. Därför bör det alltid finnas en knapp typ ”Glöm mig”, och gärna även en förikryssad ruta redan vid inloggningen med en text typ ”Kom ihåg mig”, så att användaren kan välja att inte få sin autentisering sparad.

Autentisering av omedvetet inloggade

Användaren behöver inte alltid aktivt autentisera sig. Är syftet enbart att hålla ett minne av användaren, hennes beteende eller inställningar, kan även den första autentiseringen ske dolt och sedan hållas med hjälp av en kaka (se sid 325 ).

En sådan autentisering blir knuten enbart till datorn, inte till användaren. Det kan leda till missförstånd om olika användare brukar samma dator, till exempel på ett bibliotek.

• Tips
• www.anvandbart.se/ab/skyddande-skal

Det kan det vare en god idé att begränsa möjligheterna att lura systemet genom att reglera varifrån man överhuvudtaget kan autentisera sig. Det är till exempel vanligt att intranät bara får användas från det interna nätverket. Även för publika webbplatser kan behörigheten att utföra säkerhetskänsliga saker, till exempel publicera nya sidor, begränsas till interna användare.

Ibland kontrolleras också datorns IP-nummer som en del av autentiseringen – detta ersätts dock alltmer av certifikat.

• Bör - undantag, se boken
• www.anvandbart.se/ab/lagom-autentisk

För att surfa runt på webbplatsen räcker det ofta att användaren är okänd eller gäst. Då är det onödigt att be henne autentisera sig bara för att komma in på webbplatsen, utan detta kan vänta tills användaren försöker gå in på en sida som kräver högre behörighet.

Om autentiseringen sker via lösenord, kan fälten för användarnamn och lösenord eller en länk till inloggningen finnas på alla sidor, så att användaren kan logga in när det passar henne.

En likartad variant är använda osäkra autentiseringsmetoder, till exempel automatisk autentisering med hjälp av kaka (se sid 317 ), fram till dess användaren vill se eller göra något som kräver större säkerhet. Detta är inte ovanligt till exempel på e-handelsplatser som kan ha en mycket låg säkerhetsnivå när användaren surfar runt (då användaridentiteten används för att anpassa vilka erbjudanden hon får) och en annan, betydligt högre, när hon går till kassan och skall börja hantera personuppgifter och betalning.

Ibland kan det dock vara en bra sak att bryta mot detta råd – om användaren krävs på autentisering så snart hon kommer till webbplatsen kan detta signalera att det är en plats där säkerheten är god.

• Tips
• www.anvandbart.se/ab/sakra-pengarna

Ett alternativ för kommersiella webbplatser är att inte lägga någon större energi på att säkerställa användarens identitet utan istället koncentrera sig på pengarna. Kontokorten erbjuder tillräcklig säkerhet i att binda en beställning till en betalning. Visserligen är säkerheten låg – vem som helst som lyckats komma över kontokortsnumret och de andra uppgifterna på kortet kan utan problem lura systemet. Men fallen av bedrägeri är inte fler än att kostnaderna för dem täcks av systemet.

• Bör
• www.anvandbart.se/ab/utloggning

På webbplatser som hanterar känslig information bör det alltid finnas ett tydligt sätt för användaren att logga ut så att hon kan känna sig trygg i att ingen har möjlighet att ta över hennes autentisering.

Vanligen görs detta med en ”Glöm mig” eller ”Logga ut”-knapp.

• Bör - situationsberoende, se boken
• www.anvandbart.se/ab/lita-ej

En inloggning varar i allmänhet så länge som sessionen varar. Har man en generös tidsgräns för denna (vilket man bör ha) kan detta vara ett säkerhetsproblem om användaren till exempel använder en lånad dator eller lämnar sin egen dator obevakad. (Det bör noteras att en användare som loggar in från till exempel ett internetcafé även utsätter sig för risken att inloggningen avlyssnas direkt på datorn.)

Utloggning kan ha en viss psykologisk effekt – det känns bättre för användaren att uttryckligen kunna avbryta sessionen. Men som säkerhetsmekanism är den inte mycket att lita på. Användare glömmer alltför ofta att logga ut.

Även tidsgränser som skydd är problematiska. Sätts de snålt så blir de snabbt irriterande genom att användaren tvingas logga in igen så snart hon gjort en paus. Sätts de generöst finns risken att någon annan tar över sessionen efter att användaren lämnat datorn.

Vägar att stärka säkerheten kan vara certifikat för att säkra att användaren bara loggar in från sin egen dator och engångslösenord för att hindra lösenordsstöld. Tillsammans med om-autentisering vid säkerhetskritiska ögonblick kan den senare lösningen ge god säkerhet även för cafésurfaren.

Ett mer cyniskt, men möjligen rättvist sätt att se problemet är att faktiskt se det som användarens ansvar att skydda sin användaridentitet, till exempel genom att alltid låsa sin dator när hon lämnar den och inte utsätta sig för de risker som lånade datorer innebär.

• Bör
• www.anvandbart.se/ab/registrering-tillbaka

Om användaren skapar ett användarkonto beror det ofta på att det är något hon vill göra som hon har framför sig och som kräver att man registrerat sig. Det är därför lämpligt att användaren tas tillbaka till sidan hon var på innan hon började registreringen, när den är klar.

Om hon skapade användarkontot från en inloggningssida, bör hon loggas in i samband med att kontot skapas (se nästa råd) och därefter komma till nästa steg i processen.

• Bör - undantag, se boken
• www.anvandbart.se/ab/registrering-inloggad

När användaren har registrerat sig bör hon vara inloggad. Hon har ju lämnat alla de uppgifter som behövs för att vara inloggad, så det finns ingen anledning att tvinga henne till att sedan göra inloggningen i ett separat steg.

Dock kan detta i vissa fall vara tekniskt svårt att ordna. Då bör inloggningen hängas på som sista delen av registreringen, så att användaren efter att hon registrerat sig direkt kan logga in och sedan förs till den sida hon var på innan registreringen inleddes (se föregående råd).

• Tips
• www.anvandbart.se/ab/inaktiva-anvandarkonton

Ett användarkonto som inte längre används tar upp diskutrymme till ingen nytta. I sig kanske inte något stort problem, hårddiskar är billiga. Värre kan vara att populära användarnamn är upptagna utan att komma till bruk.

Därför kan det vara en god idé att bestämma hur länge ett konto får vara inaktivt innan det rensas bort.

Om du har användarens e-postadress, kan det vara uppskattat att sända en varning en månad före och ge användaren en chans att rädda sitt användarnamn. Om användaren inte gör något sänd en sista varning 24 timmar innan kontot utplånas.

Att koppla användarkontot till en verklig människa

För att en användare skall bli identifierad krävs att det finns en koppling mellan användarkontot och den verkliga människan.

Gör kopplingen lagom säker

Kopplingen mellan användarkonto och verklig människa kan göras på en mängd olika sätt, och även på detta område gäller det att hitta en balans mellan bekvämlighet och säkerhet. Ju säkrare man vill vara, desto krångligare och dyrare blir det vanligen att ordna.

Osäkra kopplingar

Ofta räcker det för webbplatsen med en begränsad visshet i kopplingen mellan användaridentitet och verklig identitet. Här är några sådana metoder.

• Användarens egen uppgift

Att användaren säger att hon är en viss person är naturligtvis så långt ner på säkerhetsskalan man kan komma, men i sammanhang där användaren har något att tjäna på att uppge sitt korrekta namn kan det fungera. Räkna dock med att hitta en och annan ”Kalle Anka” bland användarna.

• E-postadress

Ett av de absolut vanligaste sätten är att kräva att användaren uppger en e-postadress och att sedan skicka ett e-brev till denna adress som användaren antingen skall svara på eller klicka på en länk i.

Eftersom det är lätt för vem som helst att skaffa en Hotmail-adress ligger naturligtvis även denna metod långt ner på säkerhetsskalan.

• Personnummer

Att be användaren uppge sitt personnummer är ytterligare en metod. Det är förvånansvärt svårt att gissa sig fram till ett fungerande personnummer (bara vart tionde försök lyckas), men för den som vill lura systemet är det naturligtvis inget hinder.

Att be om personnummer kan vara integritetskänsligt, och utestänger alla människor i hela världen utom de få som har ett svenskt personnummer.

• Vanlig adress

Ett betydande steg i säkerhet – och i krångel – tar man genom att skicka användarnamnet och lösenordet i ett vanligt brev till det namn och den adress användaren uppger.

Även detta går naturligtvis att lura, men bara med visst besvär.

Säkra kopplingar

Var gränsen går för att man skall känna sig trygg i hopkopplingen mellan människa och användarkonto är en bedömningsfråga. Ingen metod kan ge fullständiga garantier mot bedrägerier.

Den nivå man tycks ha valt åtminstone hos svenska myndigheter är att den elektroniska identifieringen måste vara minst lika säker som när någon i den verkliga världen legitimerar sig med sitt id-kort.

Generellt kan man säga att de metoder som godtas är sådana som just kräver att användaren i något skede personligen och med id-kort bevisat sin identitet.

• Konventionell legitimering

Detta görs vanligen genom att skicka inloggningsuppgifterna i ett rekommenderat brev som användaren måste gå till sitt postutlämningsställe och legitimera sig för att få ut.

• Överförd säkerhet

En av de mest spridda autentiseringsmetoderna bland dem som betraktas som säkra är BankID . För att få ett sådant måste användaren ha ett konto i en internetbank (och för att ha det måste hon någon gång ha legitimerat sig på konventionellt sätt).

• Elektroniskt id-kort

Det finns numera elektroniska id-kort. De ser ut som vanliga konventionella, men har dessutom en datorkrets. För att använda det måste användaren ha tillgång till en dator med en kortläsare, samt kunna id-kortets lösenord.

• Visa upp sig

I vissa sammanhang är det lättare att fastställa identitet. Till exempel för intra­nät­en, där kontrollen är informellare men lika sträng. Där får användaren sitt konto i samband med anställningen.

• Tips
• www.anvandbart.se/ab/utestang-spamrobotar

Ett snabbt ökande problem för webbplatser som tillåter sina användare att på något sätt bidra med innehåll (till exempel i form av kommentarer) är att spamrobotar utnyttjar detta för att sprida reklam. Därför finns ibland behovet att fastslå inte vem en användare är, men väl att hon är människa.

Utöver nästa råd kommer jag inte att gå in på hur detta görs – kapprustningen mellan sajter och spammare är för snabb för att fångas i en bok. Länkar finns istället på www.anvandbart.se/ab/utestang-spamrobotar.

• Skall
• www.anvandbart.se/ab/captcha

Ett populärt sätt att säkra att det är en människa som t.ex. försöker registrera sig är att visa upp ett förvrängt ord och be användaren skriva det.

Problemet med metoden är att den är fullständigt otillgänglig för blinda användare. Se WCAG 1.1 (prioritet 1), sid 349 .

Mer acceptabla är tester som kräver att man förstår en instruktion, typ ”Skriv första bokstaven i denna webbplats namn”.

• Bör
• www.anvandbart.se/ab/webblasarens-kontroller

Det är inte alltid man som webbutvecklare är särskilt glad över webbläsarens navigation. Den tar ifrån en kontrollen över hur användaren rör sig genom webbplatsen.

Speciellt i webbapplikationer kan detta ställa till med problem, om användaren plötsligt backar tillbaka till sidor hon redan passerat, stänger ett fönster och därmed avbryter utan att uttryckligen avsluta, eller öppnar ett nytt fönster mitt under inmatningen och därmed ur systemets synvinkel samtidigt är både en och två användare.

Javascript ger möjlighet att ta bort kontrollerna från webbläsaren. Det kan vara frestande, men det är en frestelse man inte bör falla för. Att avlägsna kontrollerna upplevs ofta av användaren som ett oartigt ingrepp i hennes sfär. Det kan också leda till rent praktiska problem, till exempel att det kontrollösa fönster du skapat styr utseendet på nästa fönster användaren öppnar, vilket kan tvinga henne att starta om webbläsaren för att återfå kontrollerna.

• Bör
• www.anvandbart.se/ab/tillat-anvandarfonster

Användare brukar ibland öppna ett nytt fönster (eller en ny flik) med en kopia av sidan. På så sätt kan hon arbeta vidare med två eller flera alternativ jämsides, till dess hon är redo att besluta sig för ett.

Detta är ett ofta mycket produktivt sätt att hantera olika valmöjligheter, och bör tillåtas.

Dock kan det leda till problem för webbapplikationer som inte byggts med detta i åtanke. En användare delas då i två, som delvis är samma delvis olika.

Det finns tekniska lösningar för detta, men på samma sätt som med bakåtknappen hänger möjligheten att tekniskt genomföra dem samman med hur systemet i grunden är konstruerat. Det är därför viktigt att få med detta som ett användbarhetskrav redan vid teknikvalet.

Om tekniken inte klarar det, skall användaren ges ett artigt felmeddelande om att det tyvärr inte är möjligt.