Primary links

UR ANVÄNDBARHETSBOKEN

21 Apr 2011

52.16.5 Koppla samman kontroll och instruktioner

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 11

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 .

11 Om det finns en <label> är det bäst att lägga title-texten i denna och låta den omsluta kontrollen.

UR ANVÄNDBARHETSBOKEN

20 Apr 2011

52.16.4 Ge exempel hellre än mönster

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 (####-####-####-####)”.

Bild 99. Instruktioner som förvirrar mer än de hjälper. (www.bredbandsbolaget.se)

UR ANVÄNDBARHETSBOKEN

16 Apr 2011

52.16.3 Komplettera kontrollen med instruktioner

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.

UR ANVÄNDBARHETSBOKEN

15 Apr 2011

52.16.2 Sätt inte etikett eller instruktioner inuti textfält

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 .

Ur bloggen:

UR ANVÄNDBARHETSBOKEN

12 Apr 2011

52.16.1 Koppla samman etikett och 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 .

UR ANVÄNDBARHETSBOKEN

11 Apr 2011

52.16 Etiketter och instruktioner

Kring formulärets kontroller finns flera olika texter. Den viktigaste är etiketten - den som berättar vad kontrollen frågar efter. Men det finns flera andra, till exempel instruktioner och hjälptexter.

För att dessa texter skall fungera bra - speciellt för synskadade – krävs att de hanteras rätt.

UR ANVÄNDBARHETSBOKEN

5 Apr 2011

52.15.2 Presentera det uppladdade dokumentet så att användaren har kontroll över det

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

UR ANVÄNDBARHETSBOKEN

4 Apr 2011

52.15.1 Gör uppladdningskontrollen pedagogiskt tydligt

Bild 98. Miniformuläret med uppladdningskontrollen har här fått en egen sida. Detta minskar avsevärt risken att användaren går vidare utan att ha klickat båda de nödvändiga knapparna. (Men notera att de gått i språkfällan - ”Bläddra” i instruktionen men datorn som skärmdumpen är gjord på föredrog ”Browse”.) (mail.spray.se)

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.

Rättelser och tillägg

UR ANVÄNDBARHETSBOKEN

31 Mar 2011

52.15 Uppladdning av dokument

Användning

Används för att välja ett dokument från hårddisken, som skall sändas till webbservern.

Utformning

Uppladdningskontrollen består av två delar. En knapp för att välja ett dokument från den egna datorn samt ett textfält där sökvägen till detta dokument står.

Storleken på texten i fältet och knappen kan styras för nästan alla webb­läsare. Bakgrundsfärg för fältet kan sättas och dess kanter påverkas. I övrigt saknas pålitliga möjligheter att påverka utseendet.

Du har ingen kontroll över vad som står i knappen, det bestäms av användarens webbläsare och dator och kan variera inte bara i formulering utan också i språk – tänk på detta när du formulerar hjälptexter.

Stora användbarhetsproblem

Kontrollen för uppladdning av dokument har flera stora användbarhetsproblem inbyggd i sig.

Värst av dem är att användaren måste trycka på två knappar för att uppladdningen verkligen skall ske. Dels kontrollens knapp, dels formulärets skicka-knapp.

Ytterligare en förvirrande faktor är fältet som ser ut som ett textfält. Det går visserligen att skriva i sökvägen till dokumentet, men i praktiken används det bara för att visa vilket dokument man valt – och inte heller det gör det särskilt bra eftersom själva dokumentnamnet försvinner ut till höger och inte syns.

Slutligen, om dokumentet är stort kan väntan sedan man tryckt på skicka-knappen bli lång. Om användaren då går vidare till en annan sida kan hon råka avbryta uppladdningen utan att vara medveten om detta.

Uppladdning av bilagor

En vanlig situation är att uppladdade dokument betraktas som bilagor till informationen i formuläret. I de fallen vill man ofta låta användaren ladda upp dokumenten som ett separat steg, så att hon kan se och hantera dem innan formuläret skickas in.

Detta görs genom att dokumentuppladdningen blir ett eget miniformulär, som bara består av uppladdningskontrollen och en skicka-knapp (döpt till typ ”Bifoga”, ”Skicka” eller ”Lägg till”).

Vinsten detta är att det ger möjlighet att utforma ett gränssnitt där användaren har bättre kontroll över vilka dokument som följer med huvudformuläret.

Bild 97. Ett miniformulär som låter användaren ladda upp dokument (i det här fallet bilder…)

…och sedan se och hantera dem innan huvudformuläret skickas in.

UR ANVÄNDBARHETSBOKEN

30 Mar 2011

52.14.1 Undvik länkar i formulär

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 .

UR ANVÄNDBARHETSBOKEN

30 Mar 2011

52.14 Länk

Användning

Länken tar användaren till en annan sida.

UR ANVÄNDBARHETSBOKEN

29 Mar 2011

52.13.1 Låt de knappar som driver processen framåt synas extra

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

UR ANVÄNDBARHETSBOKEN

26 Mar 2011

52.12 Avbryt-knapp

Användning

Avbryter inmatning i flersidiga formulär och i formulär skyddade av tunnlar eller skyddsnät (se sid 279 ). För vanligen användaren tillbaka till sidan hon var på innan hon kom till formuläret.

Om man ser strikt till tekniken är det normalt ingen skillnad mellan en avbryt-knapp och en vanlig länk, men eftersom den i användarens medvetande gör något mer är det lämpligt att göra den som en knapp. (Se även Låt inte knappar fungera som länkar eller länkar som knappar , sid 120 .)

Utformning

Avbryt-knappen brukar finnas tillsammans med en skicka-knapp, och placeras då till höger om eller under denna.

Konstruktion

Det finns inga särskilda avbryt-knappar i HTML utan dessa måste skapas, antingen genom att ta en vanlig knapp och skriva ”Avbryt” på den eller genom att formge en länk så att den ser ut som en knapp.

UR ANVÄNDBARHETSBOKEN

25 Mar 2011

52.11.2 Rensa-knappen bör sättas ut om formuläret är förifyllt

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.

Extra länkar

UR ANVÄNDBARHETSBOKEN

24 Mar 2011

52.11.1 Sätt aldrig ut rensa-knappen om formuläret från början är 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.

UR ANVÄNDBARHETSBOKEN

22 Mar 2011

52.11 Rensa-knapp

Även kallad ”reset” eller ”återställ”.

Användning

Återställer formuläret så att det ser ut som innan man började fylla i det.

I många fall är avbryt-knappen (se nedan) ett bättre alternativ.

Utformning

Rensa-knappen brukar finnas tillsammans med en skicka-knapp, och placeras då till höger om eller under denna. Det är viktigt att uttryckligen döpa den (till exempel till ”Rensa” eller ”Återställ”), eftersom namnet annars blir godtyckligt bestämt av det system användaren har.

UR ANVÄNDBARHETSBOKEN

21 Mar 2011

52.10.3 Ersätt inte skicka-knappen med 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 .

UR ANVÄNDBARHETSBOKEN

20 Mar 2011

52.10.2 Låt inte upprepade klick på skicka-knappen leda till dubblerad inmatning

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.

UR ANVÄNDBARHETSBOKEN

19 Mar 2011

52.10.1 Döp skicka-knappen efter vad den gör

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.

UR ANVÄNDBARHETSBOKEN

14 Feb 2011

52.10 Skicka-knapp

Skicka-knappen går även under namn som ”OK” eller ”submit”. Ofta står det något annat än ”Skicka” på den.

Användning

När man klickar på skicka-knappen skickas den information som man gett i formuläret till webbservern och man kommer (i normalfallet) vidare till en ny sida.

UR ANVÄNDBARHETSBOKEN

13 Feb 2011

52.9.3 Knappar skall se ut som knappar

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

UR ANVÄNDBARHETSBOKEN

11 Feb 2011

52.9.2 Om knappen görs av en bild, skall den ha alt-text

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.

UR ANVÄNDBARHETSBOKEN

10 Feb 2011

52.9.1 Knapptext bör inte göras som 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.

UR ANVÄNDBARHETSBOKEN

7 Feb 2011

52.9 Knapp

Användning

Ett klick på en knapp avslutar arbetet med ett formulär - antingen för att man är klar eller för att man vill avbryta.

Det är också vanligt att knappar utsträcks till andra arbetsuppgifter (med hjälp av javascript eller genom att vara förklädda länkar).

Detta kapitel behandlar det som är gemensamt för alla sorters knappar. Följande kapitel tar upp mer specifika användningar.

Utformning

Det finns flera olika metoder för att skapa en knapp.

• <input>

Den vanligaste är med hjälp av HTML-koden <input>. För knappar gjorda på detta sätt varierar utseendet kraftigt, inte bara mellan olika webbläsare och mellan Macintosh och PC. Det kan också variera kraftigt på en och samma webbsida, som ett resultat av små ändringar i formatmallen.

Bild 96. Den enda skillnaden i koden mellan dessa två knappar är att den undre fått en bakgrundsfärg i formatmallen. Överraskande nog ger det till resultat en helt annan knapptyp. (Skärmdump från Internet Explorer 6 på PC.)

Det går att styra typsnitt, fet och kursiv, storlek och färg på texten. Även kontrollerna för bakgrundsfärg och kantutseende fungerar relativt väl med nästan alla webbläsare.

• Bild

En variant av <input> gör det också möjligt att använda en bild som knapp. Denna kan dock skapa tillgänglighetsproblem, se Knapptext bör inte göras som bild, nedan. Den kan inaktiveras, men ger ingen visuell ledtråd om att så skett.

• Button

Ett modernare sätt är med HTML-koden <button>. Den gör det bland annat vissa möjligheter att kombinera text och bild utan att offra tillgängligheten. Den kan dock ge problem med gamla webbläsare.

• Länk och javascript

Ett fjärde alternativ är att med hjälp av javascript låta en länk fungera som en knapp. Själva knapputseendet ordnas med hjälp av formatmallar, vilket ger mycket god kontroll över utseendet och konsekvens mellan olika webbläsare.

Som alla metoder som använder ett element till något det inte är avsett för kan denna ge vissa tillgänglighetsproblem – det är inte uppenbart att det är en knapp för den som inte kan se den. Den kräver också att användaren har javascript (se sid 426 ).

Knappen kan inaktiveras, men det är webbmakarens ansvar att i så fall även ändra utseendet.

Mer om länkars förhållande till knappar i Låt inte knappar fungera som länkar eller länkar som knappar , sid 120 .

Ur bloggen:

UR ANVÄNDBARHETSBOKEN

6 Feb 2011

52.8.1 Slå av minnesfunktionen på lösenordsfältet

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 .

UR ANVÄNDBARHETSBOKEN

3 Feb 2011

52.8 Lösenordsfält

Användning

Man kan skriva in text, men på skärmen syns den bara som asterisker. Rutan är tom om man lämnat sidan och senare backar tillbaka till den. Används, som namnet säger, för att fylla i lösenord och andra uppgifter som man inte vill att någon skall kunna spionera på.

I övrigt, se Textfält , ovan.

UR ANVÄNDBARHETSBOKEN

2 Feb 2011

52.7 Flerradiga textfält

Användning

Används för att skriva in större mängder text.

Om texten inte ryms i fältet, kan man använda en rullist för att se hela. I en del webbläsare finns rullisten på plats hela tiden, i andra dyker den upp bara är den behövs.

Utformning

Det finns få möjligheter att påverka texten i detta fält som fungerar någotsånär konsekvent på olika webbläsare. De flesta webbläsare visar texten med typsnittet Courier. Fet text och kursiv går dock ofta att få och storleken på texten kan ändras.

Bakgrundsfärg samt tjocklek och färg för kanter går att ändra i de flesta webbläsare. Kanterna kan dock inte alltid tas bort helt.

UR ANVÄNDBARHETSBOKEN

1 Feb 2011

52.6.3 Döp textfältet så att webbläsaren kan föreslå innehåll

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.

UR ANVÄNDBARHETSBOKEN

1 Feb 2011

52.6.2 Anpassa textfältets storlek till det förväntade svaret

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