Web standards checklist
Postad: 22 oktober 2008 | HTML-guider · UX Design · UX-guider | No CommentsGuiden Web Standards Checklist är ett hjälpmedel i hur du gör tillgängliga och användbara webbplatser.
Artikeln Web standards checklist är ursprungligen skriven av Russ Weakley på https://www.maxdesign.com.au. Kaxigt.com har fått tillåtelse att översätta den från engelska till svenska.
Web standards – mer än bara ’tabellfria sidor’
Termen web standards kan betyda olika saker för olika människor. För vissa är det ’tabellfria sidor’, för andra är det ’användadet av valida koder’. Oavsett vilket, web standards är ett mycket vidare begrepp än just detta. En sida som är byggd i web standards skall ansluta sig till standards (HTML, XHTML, XML, CSS, XSLT, DOM, MathML, SVG etc) och sträva efter bästa utformandet (valida koder, koder för tillgängligheten, semantiskt korrekta koder, användarvänliga URLs etc).
Om checklistan
Det här är ingen ”uber-checklista”. Det finns troligen många fler punkter. Mest viktigt, det här ska inte ses som en punktlista som måste finnas på varje site du gör. Det är en enkel guide som kan vara användbar för:
- att visa hur brett web standards är
- som ett bekvämt redskap för utvecklare under produktionsfasen av webbsidor
- som en hjälp för utvecklare vilka är intresserade av att övergå till web standards
Checklistan
- Kvalitén på koden
- Används korrekt Doctype på sidan?
- Finns det character set på sidan?
- Använder sidan Valid (X)HTML?
- Använder sidan Valid CSS?
- Används några CSS hacks på sidan?
- Används några onödiga classes eller id på sidan?
- Är koderna väl utformade?
- Finns det några brutna länkar?
- Hur uppför sig sidan i termer gällande hastighet/sidstorlek?
- Har sidan några JavaScriptfel?
- Graden av separation mellan innehåll och presentation
- Tillgänglighet för användare
- Används ”alt” attributet för alla descriptiva bilder?
- Använder sidan hellre relativa enheter än absoluta enheter för textstorleken?
- Finns det några aspekter som syftar på att layouten bryter samman ifall fontstorleken ökas?
- Använder sidan synliga ”skip menus”?
- Använder sidan tillgängliga formulär?
- Använder sidan tillgängliga tabeller?
- Finns det adekvata färg ljushet/kontraster?
- Används enbart en färg för viktig information?
- Finns det någon fördröjd respons i dropdownmenyerna (för användare med reducerade motoriska färdigheter)?
- Är alla länkar deskriptiva (för blinda användare)?
- Tillgänglighet som anordning
- Fungerar sidan acceptabelt både i moderna som äldre webbläsare?
- Är innehållet fortfarande tillgängligt om CSS tas bort eller om det inte finns stöd för css?
- Är innehållet fortfarande tillgängligt ifall bilderna tas bort eller om det inte finns stöd för bilder?
- Fungerar sidan i textbaserade webbläsare som Lynx?
- Fungerar sidan bra vid utskrift?
- Fungerar sidan bra i handhållna anordningar (Hand Held Devices)?
- Finns det en inkluderad detaljerad metadata på sidan?
- Fungerar sidan bra i frekventa webbläsares olika fönsterstorlekar (upplösningar)?
- Grundläggande användbarhet
- Finns det en synlig och klar hierarki?
- Är nivåerna på rubrikerna lätta att urskilja?
- Är navigeringen på sidan lätt att förstå?
- Är navigeringen på sidan konsekvent?
- Använder sidan ett konsekvent och lämpligt språk?
- Finns det en sidkarta eller kontaktsida? Är dessa lätta att finna?
- För stora siter, finns det ett sökredskap?
- Finns det en länk till första sidan (home) på varje sida?
- Är länkarna understukna?
- Är de besökta länkarna tydligt definierade?
- Handhavande av siten
1. Kvalitén på koden
1.1 Används korrekt Doctype på sidan?
Ett doctype (kort för ’document type declaration’) informerar validatorn vilken version av (X)HTML du använder, och måste finnas högst upp på varje webbsida. Doctypes är en nyckelkomponent för underordnandet av websidor: din markup och CSS kommer inte att validera utan dessa.
Mer att läsa:
- http://www.w3.org/QA/2002/04/valid-dtd-list.html
- http://css.maxdesign.com.au/listamatic/about-boxmodel.htm
- http://gutfeldt.ch/matthias/articles/doctypeswitch.html
1.2 Finns det character set på sidan?
Om en användaragent (ex. en webbläsare) inte kan finna att någon character encoding används i ett webbdokument, så kommer användaren troligtvis få en icke-läsbar text presenterat för sig. Den här informationen är särskilt viktig för de som tillhandahåller och erbjuder en flerspråkig site, dock; att uppge dokumentets character encoding är viktigt för alla som producerar XHTML/HTML eller CSS.
Mer att läsa:
1.3 Använder sidan Valid (X)HTML?
En valid kod renderar snabbare än en kod med fel. En valid kod kommer att rendera bättre än en invalid kod. Webbläsarna kommer att bli mer ”standards compliant”, och det kommer alltmer att bli nödvändigt att skriva valid och ”standards compliant HTML”,
Mer att läsa:
1.4 Använder sidan Valid CSS?
Du måste göra dig säker på att det inte finns några fel vare sig i din HTML eller din CSS, eftersom misstag oavsett plats kan resultera i att dokumentet ser ut som ett ”hafsverk”.
Mer att läsa:
1.5 Används några CSS hacks på sidan?
Egentligen, hacks handlar om ett personligt val, ju mer kunskap du har i ”workarounds” (att hitta en lösning utan hacks), desto mer specifik design kommer du att försöka uppnå.
Mer att läsa:
1.6 Används några onödiga classes eller id på sidan?
Jag har upptäckt att när utvecklarna lär sig nya färdigheter så slutar det ofta med en bra CSS fast svag XHTML. Mer specifikt, XHTML-koderna tenderar att bli fulla av onödiga divvar och id:n. Det här resulterar formligen i en meningslös HTML och svällande stilmallar.
1.7 Är koderna väl utformade?
En semantisk korrekt markup använder html-element för dess givna syfte. En väl utformad HTML har en semantisk innebörd för ett brett fält av användaragenter (webbläsare utan stilmallar, textbaserade webbläsare, PDA:s, sökmotorer osv.)
Mer att läsa:
1.8 Finns det några brutna länkar?
Brutna länkar kan frustrera användare och kan driva potentiella besökare iväg. Brutna länkar kan också göra så att sökmotorerna inte indexerar din sida ordentligt.
Mer att läsa:
1.9 Hur uppför sig sidan i termer gällande hastighet/sidstorlek?
Få mig inte att vänta… Det är meddelandet som användarna ger oss i enkät efter enkät. Till och med bredbandsanvändarna kan lida av den långsam-laddade visan.
1.10 Har sidan några JavaScriptfel?
Internet Explore för Windows tillåter dig att sätta på en ”debugger” som kommer att poppa upp ett nytt fönster för att göra dig uppmärksam om det finns några javascriptfel på din sida. Det här finns tillgängligt under ’Internet Options’ och de avancerade tabbarna. Bocka ur ’Disable script debugging’.
2. Graden av separation mellan innehåll och presentation
2.1 Används CSS för alla aspekter gällande presentationen (fonts, colour, padding, borders etc)?
Använd en stilmall för att ta kontroll över layout och presentation.
2.2 Är alla dekorativa bilder CSS, eller förkommer de som (X)HTML?
Målet för webutvecklarna är att ta bort all presentation från html-koderna, att lämna denna ren och semantiskt korrekt.
3. Tillgänglighet för användare
3.1 Används “alt” attributet för alla descriptiva bilder?
Tillhandahåll en likvärdig text för varje icke-text element.
3.2 Använder sidan hellre relativa enheter än absoluta enheter för textstorleken?
Använd heller relativa än absoluta enheter för attribut-värdena i språkets markup och stillmallens värde-egenskaper.
Mer att läsa:
3.3 Finns det några aspekter som syftar på att layouten bryter samman ifall fontstorleken ökas?
Prova detta enkla test. Titta på din website i en webbläsare som stöder enkla förstoringar av din font. Öka nu din webbläsares fontstorlek, igen, och igen… Titta på din sida. Håller layouten fortfarande ihop? Det är farligt för utvecklare att anta att alla webbläsare använder samma standard på fontstorleken.
3.4 Använder sidan synliga “skip menus”?
En metod bör erbjudas som tillåter användaren att slippa återkommande länkar i navigeringen.
Grupprelaterade länkar, identifierar gruppen (för användaragenter), och, till användaragenter gör det, tillhandahåller en lösning att kringgå gruppen.
…blinda besökare är inte de enda som är besvärade av för många länkar i en navigations area. Ha i minnet att en person med nedsatta rörelser och med dålig anpassad teknologi kan fastna i röran av länkar.
3.5 Använder sidan tillgängliga formulär?
Formulär inte det enklaste att använda för människor med funktionsnedsättningar. Att ha navigationen runt sidan med skrivet innehåll är en sak, att hoppa mellan formulärfält och mata in information är en annan.
Mer att läsa:
3.6 Använder sidan tillgängliga tabeller?
För datatabeller, identifiera rad och kolumnrubriker… För data som har två eller fler logiska nivåer av rad eller kolumnrubriker, använd markup för att associera datacellerna och cellerna för rubrikerna.
Mer att läsa:
3.7 Finns det adekvata färg ljushet/kontraster?
Försäkra dig om att kombinationen för- och bakgrundsfärg erbjuder tillräcklig kontrast för de som är färgblinda.
Mer att läsa:
3.8 Används enbart en färg för viktig information?
Försäkra dig om att all information visas med färger som även är tillgängliga utan färger, exempel från innehåll eller markup.
Det finns tre olika typer av färgblindhet; Deuteranope (en form av röd/grön färgbrist), Protanope (en annan form av röd/grön färgbrist) and tritanope (en blå/gul brist som är mycket ovanlig).
Mer att läsa:
3.9 Finns det någon fördröjd respons i dropdownmenyerna (för användare med reducerade motoriska färdigheter)?
Användare med reducerade motoriska färdigheter kan uppleva att dropdownmenyer är svåra att använda om de är inställda på en snabb svarstid utan fördröjning.
3.10 Är alla länkar deskriptiva (för blinda användare)?
Länktexter bör vara tillräckligt signifikanta för att kunna förstås om de läses utanför innehållet – eller var för sig själv. Länktexter bör också vara korta och koncista.
4. Tillgänglighet som anordning
4.1 Fungerar sidan acceptabelt både i moderna som äldre webbläsare?
Innan du börjar att bygga en css-baserad layout så bör du besluta dig om vilka webbläsare du vill stödja och på vilken nivå du planerar att stödja dem.
4.2 Är innehållet fortfarande tillgängligt om CSS tas bort eller om det inte finns stöd för css?
En del människor kanske besöker din site antingen med en webbläsare som inte har stöd för css eller en webbläsare som har sin css avstängd. Om innehållet då är väl utformat så har det ingen betydelse.
4.3 Är innehållet fortfarande tillgängligt ifall bilderna tas bort eller om det inte finns stöd för bilder?
En del människor surfar runt bland hemsidorna med bildfunktionen avstängd – särskilt de som har mycket långsamma uppkopplingar. Innehållet bör trots detta vara tillgängligt för dem.
4.4 Fungerar sidan i textbaserade webbläsare som Lynx?
Det här är som en kombination där både bilder och css är avstängda. En textbaserad webbläsare kommer att förlita sig på ett väl utformat innehåll.
Mer att läsa:
4.5 Fungerar sidan bra vid utskrift?
Du kan ta vilket (X)HTML-dokument och lätt formatera det för utskrift, utan att beröra märkningen.
Mer att läsa:
4.6 Fungerar sidan bra i handhållna anordningar (Hand Held Devices)?
Det här en svår sak att ha att göra med tills handhållna anordningar konsekvent stöder dess rätta media typ. Å andra sidan, vissa layouter fungerar bättre i handhållna anordningar. Vikten i stödet av handhållna enheter kommer att vara beroende på vilken målgrupp det riktar sig åt.
4.7 Finns det en inkluderad detaljerad metadata på sidan?
Metadata är en apparatteknisk och förståelig information för webben.
Metadata är strukturerad information som är speciellt skapat för att beskriva andra resurser. Med andra ord, metadata är ’data om data’.
4.8 Fungerar sidan bra i frekventa webbläsares olika fönsterstorlekar (upplösningar)?
Det är ett vanligt antagande bland utvecklare att den genomsnittliga storleken på skärmstorleken ökar. Vissa utvecklare antar att den genomsnittliga storleken i dag är 1024px bred. Men vad händer med besökarna som använder mindre skärmupplösningar och användare med handhållna enheter? Är dessa en del av din målgrupp eller är de missgynnade?
5. Grundläggande användbarhet
5.1 Finns det en synlig och klar hierarki?
Organisera och prioritera innehållet på sidan genom att använda storlek och tydliga kopplingar till innehållet.
5.2 Är nivåerna på rubrikerna lätta att urskilja?
Använd rubrikindelningar till att fördela dokumentets struktur och använd dessa enligt specifikationen.
5.3 Är navigeringen på sidan lätt att förstå?
Ditt navigationssystem bör ge dina besökare en uppfattning om vilken sida de befinner sig på och var de kan fortsätta navigeringen.
5.4 Är navigeringen på sidan konsekvent?
Om varje sida på din website har en konsekvent presentation kommer dina besökare att ha det lättare att navigera mellan sidorna och få information.
5.5 Använder sidan ett konsekvent och lämpligt språk?
Användandet av ett rent och enkelt språk leder till en effektivare marknadsföring.
Att försöka ta sig igenom en sida utan att förstå språket kan vara lika svårt som att läsa dåligt skriven grammatik, i synnerhet om besökaren har ett annat modersmål.
5.6 Finns det en sidkarta eller kontaktsida? Är dessa lätta att finna?
De flesta sidkartor felar i att förmedla flertalet nivåer av sidans informativa struktur. I användbarhetstester, brukar besökarna ofta förbise sidkartan eller så kan de helt enkelt inte hitta den. Komplexiteten är också ett problem: en karta bör vara en karta, inte en utmanande navigering i sig själv.
5.7 För stora siter, finns det ett sökredskap?
Medan sökredskap inte är nödvändiga för mindre siter, och vissa personer inte heller använder dem, så ger site-specifika sökredskap ändock besökarna en valmöjlighet i att navigera.
5.8 Finns det en länk till första sidan (home) på varje sida?
Vissa användare tycker om att backa tillbaka till sidans förstasida efter att ha navigera runt i sidans innehåll. Förstasidan är därför utgångspunkten för dessa besökare, och tillåter dem att göra en sammanfattning innan de utforskar nytt innehåll.
5.9 Är länkarna understukna?
För att maximera uppfattningen om vad som är klickbart, färglägg länkarna och ge dem en understrykning. Besökarna ska inte behöva gissa sig till var på sidan de kan klicka sig vidare.
5.10 Är de besökta länkarna tydligt definierade?
Det mest viktiga, att veta vilken sida besökaren redan har varit på underlättar för besökaren så denna av misstag inte besöker samma sida om och om igen.
6. Handhavande av siten
6.1 Finns det en meningsfull och behjälplig 404 error sida som fungerar oavsett nivå i siten?
Du har efterfrågat en sida – antingen genom att skriva in URL direkt i adressfältet eller genom att ha klickat på en bruten länk och du upptäcker att du plötsligt befinner dig någonstans i mitten av ”cybervärlden”. En användarvänlig sida kommer att ge dig en hjälpande hand medan andras sidor inte gör ett enda dugg, utan förlitar sig på att webbläsarens inbyggda system ska tala om vilket problem som har uppstått.
6.2 Använder sidan vänliga URLs?
De flesta sökmotorer (med några undantag – mer exakt Google) kommer inte att indexera någon sida som har ett frågetecken eller andra tecken (som ampersand & eller liknande tecken) i webbadressens URL. Vad är det för bra sida om ingen kan hitta den?
En av de sämsta faktorerna på nätet, utifrån besökarens perspektiv, är just URL. Emellertid, om dessa är korta, logiska, och självkorrigerande, kan URLs vara acceptabelt användbara.
Mer att läsa:
6.3 Fungerar dina URLs utan “www”?
Medan detta inte är så farligt, och i vissa fall inte ens möjligt, är det alltid bra att ge personerna en möjlighet att välja alternativ. Om en besökare skriver in ditt domännamn utan www och sedan hamnar någon annanstans, kan det vara till nackdel både för dig och besökaren.
6.4 Har siten en favicon?
En favicon är en bild som i princip alla professionella utvecklare inkluderar på sina siter. Faviconen tillåter ägaren att marknasföra sin site, och att skapa en mer personlig anblick i besökarens webbläsare.
Faviconer är definitivt inte livsviktiga. Emellertid, om de inte finns så kan det orsaka 404-felmeddelande i dina loggar (statistiken). Webbläsare som IE kommer att begära dem från servern om sidan är bokmärkt. Finns det då ingen favicon kommer den troligtvis att generera ett 404 felmeddelande. Av den anledningen kan en favicon stoppa eventuella 404 felmeddelanden. Samma sak gäller ’robots.txt’ filerna.
Mer om denna lista
Den här checklistan var först ett grovt sammanfattat formulär på the Web Standards Mail list i Maj 2004. Det blev presenterat på the Sydney Web Standards Group den 5 augusti 2004. Det är också tillgängligt som en nedladdningsbar pdf checklist för utvecklare.
Thanks as always to Rose for proof reading and Lea de Groot for her developer checklist suggestions.