Grafisk design / Se (Hela kapitlet)

• www.anvandbart.se/ab/textstorlek-anvandarkontroll

Fördelen med em och % är att de ger användaren möjlighet att själv ställa in en textstorlek som passar henne.

Nackdelen är att många användare utan egen förskyllan drabbas av oläsligt liten text. Detta gäller dem som har grundstorleken inställt på lägre än normalt, en inställning som är rätt att råka göra av misstag och utan att vara medveten om det - och därmed utan att ha en aning om vad man skall göra för att åter få texten läslig.

Vägen ur dilemmat är att inte använda text som är så liten att den kan bli oläslig. Gränsen för hur liten texten får göras är olika för olika typsnitt, men gränserna för hur små några av de vanligaste typsnitten kan göras utan att riskera att bli oläsliga i Internet Explorer är dessa:

• Verdana 69% (eller 0.69em) - men 76% ger påtagligt bättre läsbarhet och är bara aningen större

• Georgia 76% (eller 0.76em)

• Arial 86% (eller 0.86em)

• Times New Roman 86% (eller 0.86em)

Problemet med denna lösning är att ingen text kan göras riktigt liten – och att formgivningsarbetet därmed blir svårt

Relativa mått gör det också litet knepigare att skapa själva formatmallarna.

Se även WCAG 3.4 (prioritet 2), sid 353.

• www.anvandbart.se/ab/fardiga-alternativ

En annan lösning är att göra i ordning flera olika varianter och med hjälp av knappar på webbplatsen låta användaren välja den storlek hon föredrar.

Dessa alternativ kan då göras med px, vilket gör att användaren inte kan få oläsligt liten text. Dock kan den största av textstorlekarna anges med em eller %, så att synsvaga användare fritt kan styra storleken – se i så fall till att ingen text på sidan understiger de storlekar som anges i föregående råd.

Kontrollen för att styra storleken kan antingen finnas på sidan eller vara en del av en mer omfattande inställningssida – se Låt användaren anpassa webbplatsen till sina behov, sid 373.

Nackdelen med den här metoden är att webbplatsen får ytterligare en kontroll för användaren att förstå och använda.

Tekniskt hanteras storlekskontrollen antingen av webbservern, eller via javascript. I det senare fallet, se även råden under Javascript , sid 426. Använd en kaka för att komma ihåg användarens inställning, så att hon slipper göra om den varje gång hon kommer till webbplatsen.

Detta är en möjlig lösning på tillgänglighetskravet WCAG 3.4 (prioritet 2), sid 353. En del automatiska tillgänglighetskontroller tolkar dock användningen av px som att textstorleken är låst, och kommer att falsklarma om detta.

Vilken variant är bäst?

För den som vill följa 24-timmarswebben bokstavstroget är Använd mått som ger användaren kontroll över textstorleken – och aldrig liten text enda alternativet. Det är ett bra alternativ, om man står ut med den inskränkning i formgivningen det innebär att inte kunna använda särskilt liten text.

Ge användaren färdiga alternativ att välja mellan ger bättre kontroll över utseendet och betydligt större spelrum för textstorlekarna, till priset av en något komplexare webbplats.

På bokens webbplats www.anvandbart.se/ab/textstorlek finns länkar till mer hantverksinriktade artiklar om hur textstorlekar skall hanteras.

• www.anvandbart.se/ab/anvandbara-stor

Att låta användaren ställa in textstorleken är inte helt problemfritt. Det är viktigt att testa sidorna så att de fortsätter att fungera, även när en större storlek används.

Problemet är ofta att den tabellstruktur som sidan är uppbyggd på faller samman när långa ord tvingar en del utrymmen att bli bredare än beräknat.

Om layouten är byggd med formatmallar kan olika textytor börja överlappa eller försvinna in under varandra.

Ytterligare en sak att hålla vakt mot är att text i formulärfält kan bli för stor för att synas i sina fält.

Detta råd är svårt eller omöjligt att tillämpa om man inte sätter en gräns för hur stor text man har ambition att klara - nästan alla layouter med mer än en spalt har en smärtgräns.

Min ambitionsnivå brukar sträcka sig till att den löpande texten skall kunna visas i en storlek som motsvarar 24px (all annan text på sidan följer med när man förstorar den löpande texten, men eftersom den är det väsentliga innehållet låter jag den styra). Om användaren har behov av större text än så, använder hon sannolikt redan andra metoder – till exempel att förstora en del av skärmen.

Jag vill betona att detta är ett värde jag valt, ingenting som är vetenskapligt utprovat eller har stöd av handikapporganisationerna. Du får själv välja var du lägger gränsen för din ambition. Dock är ett minikrav att sidorna förblir användbara när Internet Explorers textstorlek är inställd på ”största”.

Se även WCAG 3.4 (prioritet 2), sid 353.

• www.anvandbart.se/ab/snygga-stor

Även om sidan inte slutar att vara användbar, kan den ändå blir ganska ful när man ställer upp textstorleken. Detta är naturligtvis av betydligt mindre konsekvens, och personligen har jag en tendens att tycka att den förlorade estetiken är något användaren får acceptera när hon ställer upp storleken.

Du får ta ställning till vilken standard som skall gälla på din webbplats, hur långt upp i storlek utseendet skall hålla samman.

En gräns jag själv ofta tillämpar är att sidan skall se bra ut när man har Internet Explorers textstorlek inställd på ”Största”. Även i detta fall vill jag betona att detta inte är någon vetenskaplig sanning, utan ett värde som man måste sätta utifrån ambition.

Se även WCAG 3.4 (prioritet 2), sid 353.

• www.anvandbart.se/ab/lasbart-typsnitt

Genom formatmallarna kan man styra vilket typsnitt webbläsaren skall visa. Det snitt man väljer bör finnas installerat på praktiskt taget alla datorer där sidorna skall läsas.

Detta gör att alternativen är ytterst begränsade. För löpande text är de läsvänligaste allmänt förekommande typsnitten Verdana och Georgia. Båda är speciellt utvecklade för att användas på skärm och finns på de flesta PC och Macintoshdatorer.

Det är mycket svårt att genom typografin särskilja sin webbplats från andra, att ge den en visuell identitet – de användbara alternativen är helt enkelt för få, så vad du än gör så kommer det att finnas många andra som gör samma sak (förutsatt att du håller dig inom gränserna för läsvänlighet).

Egna typsnitt

Nästan alltid måste man acceptera att typsnitten för webben inte blir desamma som de den grafiska profilen föreskriver för trycksaker. Detta både på grund av att webben ställer andra krav på läsbarhet, och av att endast ett fåtal typsnitt är så allmänt förekommande att man kan räkna med att användaren har dem. (För intranätet kan det dock finnas typsnitt som man vet är installerade hos alla användare.)

Inget hindrar i och för sig att man lägger den grafiska profilens typsnitt som förstahandalternativ, och till exempel Verdana eller Georgia som reservalternativ, så att de som har det installerat på sin dator ser sidorna med profilens typsnitt. Men tänk på att många typsnitt som är utmärkta i tryck är olämpliga för skärm, och att sidorna kommer att se olika ut för dem som har respektive dem som inte har typsnittet installerat.

• www.anvandbart.se/ab/anvandarstyrt-typsnitt

Nackdelen med att ställa in typsnittet i formatmallarna är att det hindrar användaren från att välja. I webbläsaren kan man själv ställa in vilket typsnitt man föredrar, men denna möjlighet sätts ur spel när snittet är bestämt i formatmallen.

Det är visserligen få som känner till möjligheten, och ännu färre som utnyttjar den, men den är viktig för en del människor med syn- eller läsproblem. Genom att välja ett typsnitt som passar dem får de mycket lättare att läsa.

Tyvärr är detta en dålig lösning för den stora majoritet som inte ändrar typsnitt. Times, som de flesta webbläsare visar om man inte anger något annat, är ett ganska dåligt typsnitt för skärm. (Det är däremot ett utomordentligt läsbart typsnitt på papper.)

Typsnittets betydelse minskar med storleken

Skillnaden i läsbarhet mellan olika typsnitt är störst för liten text. Ju större bokstäver, desto mindre betydelse har typsnittsvalet. I storlekar motsvarande 12px och uppåt kan också typsnitt som Times användas utan allvarliga konsekvenser.

• www.anvandbart.se/ab/fardiga-typsnitt

För att slippa välja mellan en lösning som gör det litet bättre för en stor grupp och en som gör det mycket bättre för en liten grupp, kan samma metoder som i Ge användaren färdiga alternativ att välja mellan, sid 48, också användas för att ge användaren kontroll över typsnittet.

• www.anvandbart.se/ab/lasligt-radavstand

Normalt har webbläsare ett radavstånd på 120 %. För löpande text skall detta ökas till 130-150 % – exakta värdet måste provas ut med hänsyn till typsnitt och spaltens bredd.

Generellt kan sägas att bredare spalt kräver större radavstånd.

Samma sak gäller för smala typsnitt som Arial. Typsnitt med seriffer (fötter på bokstäverna) har mindre behov av radavstånd, liksom breda typsnitt som Verdana. Times ligger någonstans mellan – det är smalt men har å andra sidan seriffer – medan Georgia är ett av de typsnitt som klarar tätt radavstånd bäst eftersom det har både bredd och fötter.

• www.anvandbart.se/ab/storre-punktavstand

I punktlistor skall det vara större avstånd mellan punkterna än mellan raderna. Detta för att göra det lättare för ögat att se vad som är en ny punkt och vad som bara är texten till en punkt som råkat bli lång nog att delas på flera rader.

• www.anvandbart.se/ab/fri-bredd

Ett alternativ är att göra spaltbredden fri, så att den anpassar sig till fönsterstorleken. Det ger användaren frihet att själv välja hur mycket av sin datorskärm hon vill att webbfönstret skall ta upp.

Problemet med denna lösning är att om användaren har stor skärm och låter fönstret uppta hela skärmen så kan spalterna bli för breda för bekväm läsning. Textraderna blir väldigt långa och det är svårt att hitta från slutet av en rad till början av nästa. Denna lösning kan alltså tvinga användaren att anpassa sin fönsterstorlek så den passar för läsning på din webbplats – ett extra arbetsmoment, och en fönsterstorlek som kanske inte alls passar när hon går vidare till nästa webbplats.

Ett annat problem är rent hantverksmässigt. Det är svårt att koda sidor med flera spalter bredvid varandra så att dessa uppför sig på ett vettigt sätt oavsett om användaren har ett smalt eller ett brett fönster.

Å andra sidan kan den som behärskar hantverket bygga sidor som ändrar sin layout beroende på hur mycket bredd det finns.

• Bör - undantag,se texten
• www.anvandbart.se/ab/last-bredd

Ett ofta enklare alternativ är att låsa spaltbredden.

När det gäller läsning av trycksaker finns omfattande forskning som visar att spalter på 45-60 teckens bredd ger den bästa läsningen. För webb finns dock ytterligare ett par faktorer att väga in:

• Eftersom webbtext inte avstavas blir spaltbredden i praktiken mindre än maximum.

• Webben är ett horisontellt medium. Korta rader innebär att jämförelsevis litet text går in på en skärmhöjd, och därigenom att läsningen störs av att man måste rulla oftare.

Tyvärr tycks det inte finnas någon forskning om vad som är en ideal spaltbredd på webben (men håll ögonen på www.anvandbart.se/ab/last-bredd, ifall någon skulle dyka upp). Min personliga bedömning är att det torde ligga kring 50-70 tecken.

Det går att göra bredare eller smalare spalter, men då på bekostnad av läslighet.

För bredare spalter kan läsligheten i någon mån räddas genom att öka radavståndet. (Se sid 53.)

Följer man 24-timmarswebben bör 70-teckengränsen inte överskridas.

Var försiktig med alltför smala spalter. En väsentlig skillnad mellan papper och webb är att webbläsarna inte avstavar ord. Detta gör att textens högerkant blir mycket ojämnare på webb än på papper – en effekt som är extra påtaglig för svenska texter, eftersom vi har betydligt längre ord än till exempel engelskan.

För spalter under 40 teckens bredd blir detta ofta besvärande.

Spaltbredd med relativt mått

Om spaltbredden anges i em anpassar den sig så att om användaren ställer in större text blir också spalten bredare, och läsligheten bibehålls. Se dock upp så att inte spalten riskerar bli för bred för användarens fönster om hon ökar textstorleken (se Sidorna bör se bra ut även när användaren ställer in en större textstorlek , sid 50, och Skärmstorlek , sid 81).

• Skall
• www.anvandbart.se/ab/min-max-bredd

En variant i teknikens framkant är att använda formatmallar för att sätta minimal och maximal bredd för spalten. Mellan dessa mått ställer spalten in sig beroende på bredden på webbläsarfönstret.

För både mini och max gäller samma begränsningar som i föregående råd.

Nackdelen är att detta bara fungerar med nya webbläsare – och inte med Internet Explorer. Ett javascript för att komma runt denna begränsning finns via www.anvandbart.se/ab/min-max-bredd.

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

Att ge texten litet marginaler, typ 2em eller 24px luft på var sida, kan göra den lättare att ta till sig, speciellt för användare med lässvårigheter.

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

Centrerad text är svårläst, eftersom ögat inte får stöd av vänsterkanten. Samma sak med högerjusterad text (där högerkanten är rak och vänsterkanten ojämn). Långa texter måste alltid vänsterjusteras. Korta texter kan undantagsvis centreras eller högerjusteras.

• Skall
• www.anvandbart.se/ab/marginaljustera-aldrig

I tryck kan det vara snyggt när spalterna har både rak vänster- och högerkant – så kallad marginaljusterad text. På webben, där texten inte avstavas, leder detta bara till störande gluggighet. Effekten blir speciellt grov för svensk text, eftersom vi har många långa sammansatta ord.

För användare med lässvårigheter kan gluggighet göra texten mycket svårtillgänglig.

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

För rubrikerna som text gäller ungefär samma sak som för löpande text - det inte finns många typsnitt att välja mellan. Eftersom rubriker är större och därmed lättare att läsa är urvalet visserligen större, men fortfarande väldigt begränsat.

För de flesta webbplatser är detta ändå det bästa alternativet, av flera skäl:

• Rubriken kommer lika snabbt som resten av texten. (Görs den som bild är risken stor att den dyker upp en bra stund efter texten).

• Om inte publiceringssystemet automatiska producerar bildrubriker, är det ett betungande arbetsmoment att göra dessa.

• Det är tillgängligt. (Även bildrubriker kan göras på ett handikappvänligt sätt, men det kräver ganska mycket trixande.)

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

Bildrubriker

Trots textrubrikernas fördelar kan det vara frestande att göra rubrikerna som bilder. Främst för att det ger väldigt mycket större typografisk valfrihet, och en möjlighet att använda samma rubriktypografi för webben som för sina trycksaker.

Tyvärr är detta en dålig lösning, tillgänglighetsmässigt. Även om bildrubriken får en alt-text och HTML-kodas som rubrik (d.v.s. med <h…>-taggar) är det många skärmläsare ⁴ som inte klarar att tolka alt-texten som en rubrik.

Det har kommit en rad olika tekniker som påstås göra det möjligt att använda bilder som rubriker utan att offra tillgängligheten. Många av dessa har visat sig ha problem, andra verkar lovande men är fortfarande för oprövade för att få en rekommendation. Med tiden kommer förhoppningsvis någon att verkligen visa sig hålla. Se länkar via www.anvandbart.se/ab/rubriker.

• Bör
• www.anvandbart.se/ab/skriv-bildtext

De flesta bilder tjänar på att kompletteras med en bildtext, som hjälper tolkningen och att foga in dem i sitt sammanhang.

Bildtexten är dessutom en av de mest lästa texttyperna och därför en utmärkt möjlighet att få användaren att börja läsa sidan.

Ett publiceringssystem bör ha bra stöd för att skriva och placera bildtexter, något som tyvärr många saknar.

• Bör
• www.anvandbart.se/ab/ange-bildskapare

För många bilder är det ett avtalsvillkor att man anger vem som skapat bilden. För andra är det god ton.

Skaparens namn kan anges som en del av bildtexten.

Alternativt kan skaparen anges vertikalt längs med bildens kant (se www.anvandbart.se/ab/ange-bildskapare för hur detta görs).

I värsta fall kan bildens title-text användas. Då bör dock avtalet med bildskaparen kontrolleras för att se om det är accepterat.

I ett publiceringssystem bör enkla funktioner för att ange skaparen finnas inbyggda.

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

Den mest kända av bildens dolda texter är alt-texten. Den finns för att ge en kort beskrivning av bilden så att även den som inte kan se bilden får den väsentliga informationen från den.

alt-texten skall så långt möjligt vara ett likvärdigt alternativ till bilden. Den skall alltså inte i första hand beskriva bilden, den skall fylla samma funktion. Om bilden till exempel är en högerpil länkad till nästa sida, skall alt-texten vara ”Nästa sida”, inte ”Pil som pekar åt höger”.

Några tumregler för alt -texter:

• Tänk dig att du läser upp sidan för någon i telefon. Den beskrivning du då ger av en bild, är en bra startpunkt för att formulera alt -texten.

• Om bilden består av text, kan denna text ofta användas rakt av.

• Bädda inte in innehållet i formuleringar som ”Bild av…”, ”Länk till…” eller ”Klicka här för att gå till…”. Skärmläsare berättar ändå för sina användare vad som är en bild eller en länk, så de extra orden blir bara störande.

• Om det inte finns något vettigt att säga om bilden - var tyst. Bilder som enbart har en dekorativ funktion klarar sig ofta bra utan alt-text. Ge dem en tom alt-text, alt=””. (alt utan något värde, eller alt=” ” med mellanslag får inte användas.)

• Alla bilder skall ha alt – antingen med text eller tom. Att utelämna alt ställer till med problem eftersom många skärmläsare då istället läser upp bildens webbadress.

• Om bilden förekommer flera gånger på sidan, överväg om inte användbarheten blir bäst genom att bara sätta ut alt-texten en gång och låta de övriga kopiorna av bilden ha tomma alt-texter.

• Om bilden ligger nära en länk som säger samma sak och leder till samma mål, ge den en tom alt-text.

• Var kortfattad. Sträva efter att inte vara längre än 80 tecken (och var aldrig längre än 150 tecken, eftersom det för en del skärmläsare är gränsen för vad de klarar). Har du mer att säga, se longdesc nedan.

• Var inte alltför kortfattad. alt-texten bör vara minst 8 tecken lång (om den inte är tom).

• Tänk på läsordningen så att bilden hamnar på en vettig plats även för den som lyssnar på sidan. Finns bildtext bör alt-texten komma alldeles före denna.

• Eftersom alt-texten läses upp med annan text bör den ha normal interpunktion – till exempel avslutas med punkt.

• Om bilden är klickbar skall alt-texten vara begriplig även när den läses upp utanför sitt sammanhang. Se Gör det tydligt vart länken leder, sid 115.

• Ta inte hänsyn till att alt-texten syns när man för pekaren över bilden. Mer om detta under Title nedan.

• Många av råden om hur länkar formuleras i Länk , sid 115, är tillämpliga även för klickbara bilder.

Se även Ge områdena i en multiklickbar bild förklarande texter, sid 127, och WCAG 1.1 (prioritet 1), sid 349.

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

Om bilden behöver en utförligare beskrivning kompletteras alt-texten med en long description – longdesc på HTML-språk. Bilden skall fortfarande ha en alt-text.

longdesc kan vara hur lång som helst. Precis som för alt-texterna gäller att texten inte i första hand skall vara en beskrivning av bilden utan koncentrera sig på att förmedla bildens information och funktion. Ett exempel på användning är att länka diagram till tabeller som innehåller den data som diagrammet bygger på.

En länk till goda råd om hur longdesc-texter kan utformas finns nedan.

Det är en klar fördel om publiceringssystem gör det enkelt att skapa longdesc i samband med att man lägger in bilden.

En praxis som tidigare utvecklats är att lägga ett ”[d]” intill bilden som en länk till den utförligare beskrivningen. Eftersom moderna skärmläsare klarar longdesc behövs detta inte längre.

Se även WCAG 1.1 (prioritet 1), sid 349.

• Skall - undantag, se boken
• www.anvandbart.se/ab/ej-alt-hjalptext

Det kan tyckas som en god idé att lägga in hjälptexter och annat som man vill att bara synskadade skall höra som alt-text till små genomskinliga bilder.

Problemet med detta är att många skärmläsare ignorerar sådana bilder – förmodligen ett arv sedan tiden före formatmallarna då layout i hög grad byggdes med hjälp av små genomskinliga bilder, osynliga för seende användare men ett meningslöst babbel för de blinda.

Hur stor en bild måste vara för att bli uppläst varierar från skärmläsare till skärmläsare. Chansen att alt-texten blir uppläst är betydligt större om bilden är länkad.

• Tips
• www.anvandbart.se/ab/hjalp-title

Eftersom texten i title är dold, och användaren inte ens får en ledtråd om att den finns där, bör title bara användas för sådant som det inte är avgörande att användaren ser. Den kan till exempel vara lämplig för hjälptexter och för att förklara vart man kommer eller vad som kommer att hända när man klickar på en bild.

I princip är arbetsfördelningen att alt-texten beskriver bilden, medan title berättar vilken funktion bilden har. I praktiken kan man inte lita på att alla skärmläsare läser upp title. Att sätta funktionstipset i både alt och title ger visserligen en irriterande dubblering, men är tills vidare det säkraste alternativet.

Att lägga funktionstips bara i alt och inte ha något title-text alls (inte ens tom) fungerar bra för dem med skärmläsare, liksom för dem med Internet Explorer, men gör att tipset inte syns för användare med andra webbläsare.

• Skall
• www.anvandbart.se/ab/tom-title

Om en bild saknar title visar en del (men inte alla) webbläsare istället alt-texten som om den vore en title. Denna måste därför alltid finnas, men kan vara tom, title=””.

• Tips
• www.anvandbart.se/ab/anvand-tumnagel

Om du inte vill lägga in en bild direkt på sidan – antingen för att den skulle ladda för långsamt, eller för att den inte ryms i layouten – kan den istället representeras av en minibild, en så kallad tumnagel (på engelska thumbnail). När användaren klickar på denna kommer hon till originalbilden.

För att betona att tumnageln är klickbar kan man med fördel rama den (se Låt ramen runt klickbara bilder vara kvar, sid 126).

Olika sätt att visa originalbilden

Tumnageln kan vara länkad antingen direkt till bilden, eller till en webbsida med bilden.

Om länken går direkt till bilden är det inte säkert att denna visas i riktig storlek. Är bilden större än fönstret förminskas den i många webbläsare så att hela syns. Användaren kan dock förstora bilden – om hon vet hur man gör.

Om detta är en för- eller nackdel beror på om det är viktigast att användaren får se hela bilden, eller att hon får se bilden i korrekt storlek (till priset att hon tvingas rulla för att se alla delar av den).

Det andra alternativet är att lägga bilden på en webbsida.

En sådan sida behöver inte anstränga sig för att se ut som resten av webbplatsen, den kan till exempel vara utan logotyp och utan den navigation som finns på andra sidor.

En god idé kan vara att förse den med en kontroll för att hoppa mellan att se bilden i full storlek eller (om den är större än fönstret) anpassad till fönstrets storlek. Kontrollen för att byta storlek måste vara synlig direkt, utan att man behöver rulla. För att få bilden att anpassa sig till fönstret krävs javascript (se sid 426).

Samma eller eget fönster

Ytterligare ett val måste göras för originalbilden: skall den visas i samma fönster eller öppna ett eget. I det senare fallet, se Nytt fönster , sid 329.

Ögonblicklig förstoring

Ett helt annat angreppssätt är att använda javascript för att visa den större bilden i samma ögonblick som pekaren förs över tumnageln, och sluta visa den när pekaren förs utanför bilden. En ögonblicklig zoom-funktion som har fördelen att användaren slipper klicka sig fram och tillbaka mellan sidan och bilden. Kan vara ett bra alternativ här användarens huvudfokus ligger på sidan och hon bara tillfälligt behöver se bilden större, till exempel på en produktsida på en e-handelsplats. Passar inte om bilden i sig är viktig och användaren till exempel kan behöva skriva ut den.

Eftersom effekten i hög grad bygger på snabbhet är det en god idé att förladda den större bilden.

Låt fortfarande tumnageln vara klickbar, så fungerar den även för användare som inte har javascript.

• Tips
• www.anvandbart.se/ab/beskar-tumnaglar

Enklaste sättet att skapa en tumnagel är att förminska originalbilden. Detta fungerar ofta utmärkt, men ibland kan det leda till att det inte längre går att uppfatta vad bilden föreställer eller till att det väsentliga i den inte syns.

I dessa fall är det bättre att först beskära den bild som skall förminskas, så att den koncentreras till det väsentliga.

• Bör
• www.anvandbart.se/ab/gor-sajtikon

Webbplatsen behöver även en speciell minimal version av logotypen – en så kallad sajtikon (på engelska favicon). Denna syns tillsammans med webbadressen i adressfältet, men även i bokmärkes/favoritmenyn.

Sajtikonen är ofta inspirerad av logotypen, men eftersom utrymmet är så ytterligt begränsat brukar den oftare ta fasta på en detalj än på helheten.

Bild 13. Sajtikonen är en igenkänningssymbol för webbplatsen, som till exempel hjälper användaren att hitta den bland sina bokmärken.(www.ams.se)

• Skall
• www.anvandbart.se/ab/tillganglig-mm

Till visuell multimedia måste det finnas en textmotsvarighet, så att även synskadade så långt möjligt får samma information, funktion och upplevelse. Se WCAG 1.1 (prioritet 1), sid 349.

Naturligtvis finns här en rimlighetsaspekt. Är multimediepresentationen något som roar men som inte har någon större funktion för webbplatsen är det inte någon direkt katastrof om man inte lyckas få till en fullgod textmotsvarighet och en del användare stängs ute. Om den å andra sidan är väsentlig måste man antingen lyckas med beskrivningen eller så måste man tänka om lösningen helt och hållet.

För multimedia vars väsentliga effekt är en sinnesupplevelse som inte låter sig översättas till ett annat medium, till exempel en vacker film eller en musikkonsert, räcker det att man uppger fakta om den, till exempel titel och vem som skapat den. Ibland kan det passa i sammanhanget att även beskriva den stämning som den förmedlar.

För interaktiva inslag som kräver syn bör man i första hand försöka ändra dem så att det kravet försvinner, men även där kan man tvingas att bara berätta i grova drag vad de är.

Synkronisera texten

Texten skall synkroniseras med det visuella, så att det visuella mediet och i texten visas parallellt. Se WCAG 1.4 (prioritet 1), sid 351.

Enklast löses detta genom att ge multimediet en textremsa, på traditionellt TV-vis.

Lägg på berättarröst

Så länge det inte finns webbläsare som klarar av att läsa upp text till multimediepresentation, måste det också finnas en berättarröst som läser upp texten, som en del av presentationen. Se WCAG 1.3 (prioritet 1), sid 350.

Hur man gör med berättarrösten om multimediepresentationen i sig redan innehåller ljud framgår inte av WCAG, utan man får här lita till omdöme och hantverksskicklighet, och sträva efter att på bästa möjliga sätt förmedla innehållet.

Tre versioner

Enklaste sättet att klara kraven är förmodligen att göra tre olika versioner av multimediepresentationen – en vanlig, en textad och en som både är textad och har berättarröst.

• Skall
• www.anvandbart.se/ab/tillgangliga-ljud

Om information, funktion eller upplevelse förmedlas genom ljud, skall det även finnas en textmotsvarighet som så långt möjligt förmedlar samma sak. Se WCAG 1.1 (prioritet 1), sid 349.

Samma begränsningar och resonemang som i föregående råd gäller även för ljud. Texten behöver dock inte vara synkroniserad med ljudet.

• Bör
• www.anvandbart.se/ab/inga-ljud

Ljud är en mycket stark uppmärksamhetsfångare, bär stark identitet och har utomordentlig förmåga att förmedla stämning.

Trots detta bör man vara mycket restriktiv med att använda ljud på webbplatsen. Många användare reagerar klart negativt på webbplatser som låter.

Detta kan vara en vanesak. Men det har också att göra med integritet, att inte vilja störa arbetskamrater.

Ljud i samband med till exempel en video eller någon annan slags multimedia som användaren valt att se är däremot inget problem.

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

Om det finns ett ljud kopplat till någon händelse, exempelvis till att användaren kommer till ingångssidan, spela det en gång per session, inte varje gång användaren kommer tillbaka till ingångssidan.

• Tips
• www.anvandbart.se/ab/siddelar-placering

För många av de inslag som är vanliga på en webbsida har det etablerats konventioner för var de placeras. Användaren har lärt sig var på sidan hon kan förvänta sig att hitta logotypen, menyn, sökningen etc.

Om du följer dessa konventioner gör du webbplatsen aningen lättare att använda. Men ibland kan det ändå vara värt att bryta mot dem för att inte se ut som alla andra.

• Logotyp

Nästan utan undantag finns någon form av logotyp som sammanhållande symbol för webbplatsen. Ofta är logotypen avsändarens, men ibland har webbplatsen sin egen.

Placeras ofta överst till vänster. Skall vara länkad till ingångssidan.

(Se Logotyp , sid 69.)

• Rubrik

Sidans mest framträdande element är vanligen dess rubrik, som berättar vad det är för sida, vad den handlar om, har för syfte eller vilken funktion den erbjuder.

Finns inte alltid på ingångssidan, speciellt inte om denna har löpsedel eller på annat sätt täcker många saker samtidigt.

• Global meny

Om det finns en global navigation till webbplatsens huvudavdelningar placeras denna ofta horisontellt någonstans nära sidans övre kant eller logotypens undre. (Se Global meny , sid 134.)

• Huvudmeny

Menyn läggs vanligen överst i en spalt till vänster. Ibland istället till höger.

Den kan även kombineras med den globala menyn, i form av en rullgardin. I så fall blir placeringen som för den globala navigationen.

(Se Meny , sid 128, och Rullgardinsmeny , sid 137.)

• Hjälpmeny

Ofta liten och tämligen diskret, placerad antingen vid sidans övre kant eller nära logotypens undre (alltså samma ställen som även den globala menyn aspirerar på).

Ibland sätts den tvärtom nära sidans undre kant.

Finns innehållssida eller sakregister är ofta länkarna till dem med i hjälpmenyn.

(Se Hjälpmeny , sid 135.)

• Språkmeny

Om webbplatsen även finns på andra språk brukar länkarna till dem normalt placeras vid sidans överkant. (Se Språk , sid 175.)

• Sökfält och sökknapp

Placeras vanligen nära den globala menyn eller i vänsterspalten ovanför eller under huvudmenyn. Ligger ibland ihop med hjälpmenyn. (Se Sök­ning , sid 203.)

• Synlig sökväg (breadcrumbs)

Brukar placeras ovanför eller i överkant av sidans huvudinnehåll.

(Se Synlig sökväg , sid 152.)

• Kontaktuppgifter

Adress, e-post och telefonnummer (och ibland även en länk till mer utförliga kontaktuppgifter) läggs vanligen vid sidans underkant, eller i vänsterspalten under huvudnavigation och sökning.

Finns ibland bara på ingångssidan, ibland på alla.

(Se Gör det lätt att komma i kontakt med organisationen som står bakom webbplatsen , sid 337.)

• Genväg

Genvägar är litet speciella, eftersom de är en tämligen ny företeelse på webben, och dessutom vanligen osynliga. För att göra nytta för skärmläsare bör de ligga allra först på sidan. (Se Genvägar på sidan , sid 232.)

• Annonser (banners)

En del webbplatser har annonser. Dessa lyder inte riktigt under användbarhetens lagar eftersom deras syfte är att försöka tränga sig in i användarens medvetande vare sig hon vill det eller inte.

Den traditionella placeringen är som en banner högst upp på sidan. Men eftersom användarna lärt sig att det som ser ut så knappast är värt uppmärksamhet, söker sig annonserna numera till andra ställen på sidan. Till skillnad från andra element, där det är en fördel om användaren vet var hon skall titta för att hitta dem, strävar annonserna efter att överraska.

Tunnlar och bildsidor

Det finns ett par former av webbsidor som inte följer konventionerna ovan.

En av dem är tunnlarna, som är så rensade som möjligt för att inte användaren av misstag skall lämna det formulär hon håller på att fylla i. Se Tunnel , sid 279.

En annan är sidor vars uppgift endast är att visa stora bilder (som man kommer till genom att klicka på minikopior av dem). Se Tumnagel , sid 63.

Bottenbädd

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

Webbläsare är dåliga på att hantera hopp i slutet av texten, vare sig dessa sker genom klick med musen i rullisten eller page down-knappen.

Längre upp på sidan hoppar man en knapp skärmhöjd i taget, och ögat lär sig snabbt att det kan fortsätta läsa på översta raden. Men vid slutet av sidan byter plötsligt webbläsaren beteende och slumpen får avgöra hur stort det sista hoppet blir och var fortsättningen av texten hamnar. Till följd av detta tvingas ögat ut på en vild sökning i texten.

Samma problem drabbar länkar till ankare inne i texten. I de flesta fall blir det länkade bekvämt placerat i överkant av sidan – men om länken går till text någonstans nära botten av sidan så blir även denna placering slumpmässig och ögat tvingas ut på jakt.

En logisk lösning vore att låta sina webbsidor fungera ungefär som till exempel ordbehandlingsprogrammen – skärmhöjdshoppen fungerar som förväntat (det vill säga fortsättningen på texten är alltid i överkant), och i slutet av texten blir det luft när det behövs. Tyvärr fungerar det inte så bra på webben att lägga luft i slutet av sidan. Dels beror mängden luft som behövs på fönstrets storlek, dels avviker det på ett störande sätt från hur webbsidor brukar se ut.

Istället kan en lösning vara att lägga så mycket kringmaterial som möjligt i botten av sidan. Till exempel 'läs mer'-länkar (sid 125), kommentarer och annonser. En enkel webbkarta (sid 149) fyller bra och brukar dessutom vara mycket uppskattad. Tillsammans kan dessa åtminstone delvis skapa den nödvändiga buffertzonen och minska problemet.

• Skall
• www.anvandbart.se/ab/dop-ram

Ramar har ett oförtjänt rykte om att vara dåliga för blinda läsare, men om man använder dem för att tydligt dela upp sidan i olika områden med klara funktioner och ger dessa tydliga namn, kan de tvärtom underlätta orienteringen.

För att göra ramade sidor möjliga att navigera med en skärmläsare måste de enskilda ramarna döpas utifrån sin funktion eller sitt innehåll. Det kan till exempel vara ”Sidhuvud”, ”Navigation”, ”Huvudinnehåll” etc.

Tyvärr tittar olika skärmläsare på olika saker när de skall ange namn på ramen, så man måste för säkerhets skull döpa dem på flera olika sätt.

• Varje ram skall ha en title. (Detta är vad standarden anger och det kommer förhoppningsvis att snart gå segrande ur förvirringen.)

• Varje ram skall ha ett name. I princip är det bara är datorn som skall se det, men i praktiken läser en del skärmläsare upp det som namn på ramen. name får inte innehålla mellanslag och kan ge problem med svenska tecken. Detta kan hanteras till exempel genom att skriva på engelska och med versal på varje ord, typ ”MainContent”; en dålig lösning, men den bästa som står till buds.

Därtill skall man vara medveten om att en del skärmläsare istället läser upp titeln på den sida som för ögonblicket visas i ramen.

Ramar kan också ha longdesc-text för att ytterligare klargöra vad de gör, men om man behöver använda den bör man fundera över om det inte är ett tecken på att layouten blivit alldeles för komplex.

Se även WCAG 12.1 (prioritet 1), sid 366, och 12.2 (prioritet 2), sid 367.

• Bör
• www.anvandbart.se/ab/ej-layoutram

Uppdelningen i ramar bör göras så att varje ram är funktionellt motiverad, inte utifrån att man vill uppnå en viss layouteffekt.

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

Komplettera rampaketet med <noframes>, som läses av de webbläsare som inte klarar ramar och av söktjänster. Detta kan till exempel ge länkar till de sidor som ligger i ramarna.

Se även WCAG 1.1 (prioritet 1), sid 349, och 6.5 (prioritet 2), sid 359.