Webbutveckling02 [weuweb02]

Kunskap - Validering

Introduktion

Vi har flera gånger pratat om vilken hjälp vi får av webbläsare som tolkar koden åt oss ifall vi skriver inkorrekt kod. Det finns både för- och nackdelar med detta. Fördelen är att sidan visas i webbläsaren medan nackdelarna kan vara flera, dels så kanske sidan visas upp på ett annat sätt än vad vi vill eftersom den tvingas tolka den kod som inte är korrekt. Även om sidan visas korrekt i en webbläsare så är det ingen garanti att den tolkas på samma sätt i en annan webbläsare. Därför är det så viktigt att testa dina applikationer i flera webbläsare, eller användaragenter som det också kallas.

I detta avsnitt så skall vi gå igenom en mängd tester och kontroller som behöver genomföras för att vara säker på att webbsidan håller bra kvalitet.

Validering av kod

I denna kurs så jobbar vi med de två grundteknikerna HTML5 och CSS. Eftersom vi inte naturligt får någon hjälp i webbläsaren med validering av dessa tekniker så måste vi göra det själva. Om du kikar längst ner i sidfoten på alla sidor i kursolle så finns det två länkar som validerar HTML5 och CSS. Det är enkelt sätt för mig att kunna validera alla sidor med bara ett klick.

HTML5

validator.w3.org är en bra valideringstjänst för din HTML5-kod. På sidan kan du välja att klistra in kod (vilket är smidigt när du utvecklar sidan lokalt på din dator), ladda upp en fil eller skriva in en länk till en sida som ligger på en webbserver uppkopplad till internet. När du sedan klickar på check så valideras kod och ger dig information om saker som är direkt felaktiga, som bör ändras eller som kan ändras. Valideringen sker mot standarden men ibland kan det finnas anledning att inte följa standard. Ju duktigare du blir på både kodning och felsökning desto bättre beslut kan du ta om vad som behöver ändras.

CSS

jigsaw.w3.org/css-validator är en tjänst från samma organisation, W3, som ovan och den funkar på i stort sett samma sätt fast validerar CSS. Du skall för så bra kod som möjligt göra så få avvikelser från standard som möjligt och det kan vara skönt att få koll på saker som är obsolete vilket innebär att det är attribut som inte längre används och snart inte finns stöd för.

JavaScript

JavaScript kan vara klurigt att validera då det oftast ger en felkod i konsollen när koden körs men sedan inte kommer köraspå webbsidan. Det är alltså svårt att veta exakt vad det är som är fel. För att få lite mer hjälp med detta så kan du testa ditt JavaScript på följande två onlinetjänster, jshint.com eller jslint.com. Många IDE har också inbyggt stöd för validering av JavaScript eller så finns det någon plugin som kan installeras. Du får själv hitta det sätt som passar dig bäst.

Jämförelse av kod

Om du vill jämföra två olika versioner av samma sida så finns det två bra tjänster online för detta, diffnow.com och diffchecker.com.

Användaragenter

Användaragenter innebär i vår värld olika webbläsare i en dator men också smartphones och tablets. För att göra ett fullständigt test i varje användaragent så behöver du testa i alla webbläsare och i alla typer av smartphones/tablets men det är ju orimligt för våra applikationer. Jag kommer dock kräva att du alltid testar på minst två olika webbläsare där den ena skall vara Chrome som är den som flest sidvisningar görs i [browsersverige.se, avläst 2017-03-23], och sedan en webbläsare till. De stora webbläsarna har idag alla någon form av utvecklarläge där det finns ett antal hjälpverktyg för webbutvecklare. Dessa verktyg behöver du lära dig att dra nytta av. När du ändå håller på kika om du kan hitta läget där du kan se hur din sida ser ut i en smartphone eller en tablet. I nästa moment kommer vi lära oss bygga webbsidor som är mer anpassade för olika användaragenter.

När du kollar hur din webbsida ser ut i et mobilläge från utvecklarverktyget så kanske du tycker att den ser väldigt bra ut och är synnerligen mobilanpassad men är det verkligen så? För att testa detta så använder vi oss av verktyg för att få en objektiv bedömning. Google har ett verktyg som testar om din webbsida anses mobilanpassad. Givetvis gillar inte Google kursolle.se för denna sidan har blivit underkänd utifrån mobilanpassning. Jag får också hjälp med vad jag kan ändra så att sidan blir mer mobilanpassad.

Ett annat verktyg från Google, PageSpeed Insights visar hur snabbt din webbsida laddas i dator och i smartphone. Även här får jag tips på saker som kan/behöver förbättras, vissa saker är enklare att åtgärda medan andra saker kräver lite mer kunskap. Omdömet på kursolle hittar du här.

När du gör en speedtest på en webbsida så är det inte ovanligt att kommentaren blir att bilder inte är komprimerade och tar lång tid att ladda. Två användbara verktyg för detta är compressor.io och tinyjpg.com. Hur du komprimerar kod hittar du längre ner.

Strukturerad eller komprimerad kod

Att skriva korrekt kod gör att webbläsaren snabbare kan rita upp sidan. Att skriva kompakt kod, ta bort onödiga mellanslag och mängder av luft, gör att det går fortare att hantera filen och skicka den till användaren. Här pratar vi om korta tider men om vi kapar tid i varje led så finns det faktiskt en hel del tid att vinna. Vilka verktyg kan vara intressanta att använda här?

  • dirtymarkup.com för att snygga till kod i html/css/javascript vilket gör koden lättare att läsa men den tar också bort onödig luft. Skriver du extremt tight kod så kan en körning i detta verktyg göra att det tillförs luft.
  • phpbeautifier.com gör samma sak som ovan fast med php-kod.
  • css compressor tar bort mycket, eller all luft i ett css-dokument. Hur mycket du vill ta bort handlar om vilken läsbarhet som du vill ha. I ett färdigt projekt där det finns många eller stora css-filer så kan det vara värt att låta verktyget ta bort all luft och göra det så litet, och oläsligt som möjligt, för att optimera hastigheten. Verktyget kan också göra en decompress så att koden blir lättare att läsa.
    Andra verktyg som gör liknande saker htmlcompressor.com, jscompress.com, miniwebtool.com/html-compressor. Det finns fler på nätet, hitta din favorit.

Tillgänglighet

Tillgänglighet på webben innebär att vi hela tiden måste tänka på att skapa webbsidor som är anpassade för alla, eller i varje fall så många som möjligt. Det som är enkelt att inse är de personer som har olika synsvagheter som gör att de har svårt med mindre texter, dåliga kontraster mellan text och bakgrundsfärg samt vissa färgkombinationer som flyter ihop. Men det handlar också om att ta hänsyn för de som är helt blinda och som använder sig av verktyg som läser upp webbsidan. Tillgänglighetsproblem kan vi också skapa genom att länkar, menyer och klickytor blir för små, detta är främst vanligt när vi använder en smartphone för att titta på en webbsida. Detta är några exempel på problem som vi ofta glömmer bort att ta hänsyn till när vi skapar en webbsida.

W3.org tar fram Web Content Accessibility Guidelines (WCAG) 2.0 som är guidelines för hur webbplatser med god tillgänglighet skall skapas. Det finns flera checklistor på nätet att följa och många av dem är inriktade på att myndigheter och organisationer skall vara förutseende att skapa god tillgänglighet för sina webbplatser. Om vi kikar på WCAG 2.0 Riktlinje så finns det fyra stycken principer som den som utvecklar eller publicerar information på webben bör ta hänsyn till.

Princip 1: Möjlig att uppfatta – Information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta.
https://www.w3.org/Translations/WCAG20-sv/#perceivable, avläst 2017-03-29.

Princip 2: Hanterbar - Komponenter i ett användargränssnitt och navigering måste vara hanterbara.


https://www.w3.org/Translations/WCAG20-sv/#operable, avläst 2017-03-29.

Princip 3: Begriplig - Information och hantering av användargränssnitt måste vara begriplig.


https://www.w3.org/Translations/WCAG20-sv/#understandable, avläst 2017-03-29.

Princip 4: Robust - Innehåll måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av olika användarprogram, inklusive hjälpmedel.


https://www.w3.org/Translations/WCAG20-sv/#robust, avläst 2017-03-29.

Till varje princip finns det flera riktlinjer samt tips och råd till hur dessa skall kunna uppfyllas. Vill du läsa mer så klicka på länken ovan och lär dig bygga mer tillgängliga webbplatser. En sista sida som jag vill ge tips om är webbriktlinjer.se som i första hand riktar sig till de som arbetar med webbplatser för offentlig sektor i Sverige. Men många av råden är generella och ger ett väldigt bra underlag för att höja kvalitén på de webbplatser du skapar. Vad säger tex Riktlinje91? Detta är något vi skall jobba med i nästa moment.

Nu är det ju massor av principer, riktlinjer och tillgänglighetsaspekter att ta hänsyn till. Som tur är så finns det flera verktyg för att få hjälp att bygga tillgängliga webbplatser. Vi skall kika på några av dessa.

  • wave.webaim.org är en enkel webbtjänst för att mäta tillgängligheten. WAVE finns som tillägg till flera webbläsare.
  • Eiii Page Checker testar din kod mot WCAG 20 regelverk. Här får du också tips på hur du kan rätta koden för att följa reglerna.
  • På webbriktlinjer.se så finns det en lista på automatiska testverktyg som både finns som webbtjänster och/eller plugin för olika webbläsare. Kika gärna och se om du hittar din egen favorit.