5. Moment05 - Teori

Även om denna kurs till största delen är väldigt praktisk med skapande så måste vi också lära, och förhålla, oss till viss teori. Vi kommer i detta moment kika på internets utveckling fram tills idag, du skall få fundera på internets påverkan på samhället och vi skall lära oss de lagar som vi behöver förhålla oss till när vi utvecklar applikationer till webben.

5.1 Momentets mål

I varje moment så jobbar vi mot ett eller flera mål som skolverket har satt upp i varje kurs.

5.1.1 Centralt innehåll

• Webben som plattform, dess historia och samhällspåverkan.
• Processen för ett webbutvecklingsprojekt med målsättningar, planering, specifikation av struktur och design, kodning, optimering, testning, dokumentation och uppföljning.
• Riktlinjer för god praxis inom webbutveckling.
• Interoperabilitet genom att följa standarder och testa på olika användaragenter.
• Applikationer som fungerar oberoende av val av användaragent, operativsystem eller hårdvaruplattform och hur tillgänglighet uppnås även för användare med funktionsnedsättning.
• Kvalitetssäkring av applikationens funktion och validering av kodens kvalitet.
• Terminologi inom området webbutveckling.

5.2 Internets historia

Vi skall gå igenom webbens historia och för detta använder vi oss av informationen på den utmärkta svenska webbplatsen internetmuseum.se. När internetmuseum öppnade så skapade de en tidslinje över internets historia från den första av en mängd artiklar om det intergalaktiska nätverket hela vägen fram till den senaste artikeln (januari 2025) om att Elon Musk köper Twitter. Varje artikel belyser ett visst ämne, fenomen eller händelse som har påverkat internets utveckling. Många artiklar innehåller fantastiska filmer om hur det var, och några av de saker som forskare och användare förutspådde har slagit in eller inte alls varit i närheten av att slå in. Vi får ha respekt att internets utveckling har gått enormt snabbt, framförallt hur det används på senare år, vilket gör att vi hela tiden måste lära oss att tänka om och tänka nytt. I början av 2000-talet tyckte de flesta att det var helt onödigt att ha en kamera i telefonen, våra krav ser lite annorlunda ut idag. På Internetmuseum finns det också en kortare sammanfattning av det viktigaste om internets historia. Vilken påverkan hade IT-undret i slutet av 1990-talet på internets utveckling och digitalisering? Det finns en film som är nästan en timme lång men som är klart sevärd, IT-bubblan som aldrig sprack.

Under våren 2022 så började internetmuseum publicera guidade turer som är inspelade avsnitt med olika fokus.

En annan historiebeskrivning är att leta upp historiken kring en specifik webbsida. Det kan du göra genom tjänsten archive.org. Det kan ju vara intressant att se hur en webbsida har utvecklats över tid, kanske din egen, kanske den sidan som är din favorit idag eller så finns det ju möjlighet att ta fram en nyhetstjänst en viss dag för att se hur nyheterna presenterades då.
Tidigare var detta öppet och tillgängligt men idag verkar det vara krav på inloggning, kanske finns det alternativ?

5.3 Kvalitetssäkring av webbsidans funktion och kodens kvalitet

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.

Här är det också på sin plats att höja en liten varning för inbyggda servrar i de IDE som ni använder. De har absolut sin funktion och nytta men denna server kan redan innan webbläsaren gör en tolkning av din sida förändra de fel som du eventuellt har skrivit. När du sedan lägger upp sidorna på ditt webbhotell så blir du inte räddad av detta och då fungerar inte din site som det är tänkt. Vanliga problem som de inbyggda servrarna tolkar till din fördel är felaktiga länkar (mappar och undermappar som inte har den strukturen som du hade tänkt) eller problem med versaler/gemener i filnamn.

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.

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

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

En funktionalitet som jag använde mig av på en tidigare version av kursolle var att i sidfoten ha en länk till denna validering, i den nuvarande versionen har jag ingen sidfot och då har jag också tagit bort dessa länkar. Men så här såg länken ut, https://validator.w3.org/nu/?doc=http://www.kursolle.se/weuweb01/moment05.php. Det är ju inget som skall användas på en sida som levereras till kund men kan vara smidigt att använda i test och utvecklingssyfte.

5.3.1.2 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 nu valideras 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. Länken till denna sidans validering.

Men är det ok att inte rätta de fel som validatorerna ger? I normalfallet så vill jag ju att du använder validatorerna som en hjälp att skriva bra och effektiv kod. Genom att lära sig reglerna så förstår man och vilka regler man kan bryta mot/avvika ifrån och när detta kan göras. Att använda kod från andra tjänster innebär ibland att vi får acceptera fel. Att försöka hänvisa till fel och hitta på en anledning till att inte rätta dessa fel är fel sätt att ta sig an utmaningen.

Typiska varningar som ni kommer stöta på när ni valderar HTML-kod är att validatorn klagar på att ni inte använder rubriker i vissa element som t.ex. section och article. Orsaken till detta är att enligt HTML5-standarden så skall dessa element direkt innehålla en rubrik. Så hur löser vi det?

1. Vi lägger in en rubrik som vi egentligen inte vill ha.
2. Vi lägger in en rubrik som vi sedan väljer att inte visa mha css-instruktioner som t.ex. visibility: hidden.
3. Vi byter ut alla element som ger oss problem mot div-element och väljer att inte följa HTML5-standarden.

Vilken av lösningarna gör oss nöjda? Ingen av dem så vi låter varningen vara men vi kommenterar varför vi låter den vara i vår utvärdering och validering av våra projekt.

5.3.2 Användaragenter

Användaragenter innebär i vår värld olika webbläsare i en dator men också webbläsare i 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 Google Chrome som är den som flest sidvisningar görs i, och sedan en webbläsare till, förslagsvis Mozilla Firefox då många av de som bestämmer standarden för html/css arbetar inom Mozillas organisation.

Safari och Edge är också många som använder och en stor anledning till detta är att det är standardwebläsare i Apples produkter samt Microsoft Windows. Så gör du inget aktivt val så är det dessa webbläsare som du får. Tyvärr så har bägge dessa företagen rent historiskt hittat på lite egna lösningar vilket gör dem problematiska att testa i.

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 landing page 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.

Öppna inspekteraren

Högerklicka på sidan och välj sedan Inspekteraren. Denna bilden visar hur det ser ut i Chrome, andra webbläsare har motsvarande funktioner som heter inspektera element i Firefox och granska element i Opera. I Safari måste du först aktivera utvecklarläget genom att i inställningar/avancerat kryssa i rutan Visa utvecklarmenyn i menyraden för att nå Granska element när du högerklickar.

Inspekteraren

Inne i inspekteraren så ser du webbsidans utseende i den vänstra delen och information om html och css i den högra delen. Den kod som finns är inte den kod du har skrivit utan hur koden ser ut när webbläsaren har tolkat den. Dåligt skriven kod ger mer tolkning av webbläsaren och då är risken större att det blir annorlunda än vad du har tänkt.

I inspekteraren kan du föra muspekaren över ett element och få se info om detta element. Du kan bl.a. se vilka css-instruktioner som är kopplade till elementet eller hur elementet placeras och ser ut när det ritas ut. Just placeringen är extra viktig när det uppstår luft mellan element som du har svårt att lokalisera på annat sätt.

Inspekteraren

I den vänstra delen kan du nu välja att visa hur sidan skall se ut i andra användaragenter, t.ex. en smartphone eller en tablet.

När du kollar hur din webbsida ser ut i ett 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 hade ett verktyg som på ett tydligt sätt kunde göra en enklare bedömning om webbsidan ansågs mobilvänlig eller inte. Tyvärr så stängdes denna ner 1 december 2023 och de flesta verktyg är anpassade för mer avancerade webbutvecklare och innehåller en hel mängd tester, vi kommer kika på dessa tester lite senare i detta momentet. Jag har hittat en ny tjänst som verkar vettig för ändamålet, vilket är att göra en enklare bedömning av en webbsidas mobilvänlighet. Bing har ett Testverktyg för mobilvänlighet som vi testar lite och utvärderar tillsammans.

Bedömning av mobilvänlighet

När jag testar denna sidan i Testverktyg för mobilvänlighet så får jag godkänt på alla punkter som testas. Om sidan inte blir godkänd så kommer du se info om vad som inte bedöms godkänt men det är dåligt med tips och hjälp om hur det skall fixas, där var Googles test bättre. Vi återkommer till mobilvänlighet och hur vi kan testa och åtgärda våra sidor i nästa moment.

5.3.3 Prestanda

En sak som är viktig när vi bygger våra webbsidor är att skapa förutsättningar för att vi skall ha så kort laddtid på våra sidor som möjligt. En viktig del är att skriva korrekt kod, html och css, vilket vi kontrollerat genom att validera koden. Men det finns fler sätt att optimera våra sidor och det skall vi kolla på i detta avsnitt.

Det finns flera användbara tjänster på nätet som gör analysen av vår sida och även ger oss bra tips på hur sidan skall förbättras. I denna kursen så fokuserar vi på de stora justeringarna för att förbättra våra webbsidor och webbplatser, det är lätt att fastna även i smådetaljer och jaga millisekunder men det är inte fokus för oss utan mer för de som jobbar med detta professionellt. Det är ändå kul att vi till viss del använder samma verktyg, men det innebär också att vissa råd kräver en högre kunskapsnivå än vad vi lär oss i denna kursen. Jag kommer länka till tre olika verktyg som alla är bra och som testar lite olika saker och ger råd på lite olika sätt. För att du skall känna vilken du tycker passar dig bäst så vill jag att du testar alla tre verktyg iaf en gång var. När du sedan testar dina webbsidor så handlar det ju hela tiden om att du skall få den bästa hjälpen för att göra bra förändringar som gör dina sidor snabbare.

• Google PageSpeed Insights, denna ger dig förklaringar och tips på svenska så börja gärna med den. PageSpeed Insights bygger på Lighthouse vilket är Googles verktyg och Lighthouse går också att använda via Inspekteraren i Google Chrome, här finns en instruktion på YouTube.
• Webpagetest, gör flera analyser på samma gång och betygsätter din sida på flera olika områden vilket gör det enklare att avgöra prioritetsordningen för vad som skall åtgärdas. Ger dig också en bra förståelse för vad som eventuellt bromsar upp en sida då du tydligt ser i vilken ordning olika saker sker.
• Pingdom, överskådlig men ej så detaljerad. Den talar om vilka prestandaproblem som finns generellt men inte exakt var dessa finns. Länken är ändå med eftersom Pingdom ofta används och hänvisas till när det pratas om prestanda.

Alla tre tjänsterna analyserar din sida och ger olika riktvärden för vilken prestanda en webbsida har och ger sedan tips på hur du kan förbättra denna. Nu kommer du märka att detta är verktyg som även används av professionella webbutvecklare. Här kommer du kunna få tips att ta bort kod som inte används, tex css och javascript, minifiera koder, välja andra bildformat, komprimera bilder och också komprimera text och kod (vilket ligger utanför denna kursen). Här gäller det att se vad som kan åtgärdas av oss för tillfället.

Det enklaste vi kan göra i denna kursen är att skriva kompakt kod, ta bort onödiga mellanslag och mängder av luft vilket 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 används 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.
• Compress HTML kan användas ifall du vill ta bort alla white spaces i din html-kod.
• csscompressor.com 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å komapakt som möjligt, för att optimera hastigheten. Senare i kursen så kommer du stöta på filer som har namn som style.min.css och dessa är oftast maximalt komprimerade. 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.

5.3.4 Bilder och prestanda

När du testar dina webbsidor med t.ex. Lighthouse eller PageSpeed Insights får du ofta återkoppling som handlar om bilder. Det beror på att bilder nästan alltid står för den största delen av datamängden som måste laddas när en sida visas. Små förbättringar av bilder kan därför ge stor effekt på sidans laddningstid.

Elevexempel

I detta test ser vi flera varningar som handlar om bilder: fel storlek, onödigt stora filer och äldre bildformat. Detta är mycket vanligt, särskilt i början när man fokuserar mer på layout och design än på prestanda.

Vi ska nu titta på några grundläggande sätt att förbättra bilder på en webbsida. I många fall räcker det att använda en eller två av dessa metoder för att få tydlig förbättring i prestandatestet.

5.3.4.1 Bilder i rätt storlek

En bild bör laddas ner i ungefär samma storlek som den visas på webbsidan. Om du laddar upp en mycket stor bild (t.ex. 4000 px bred) men bara visar den i 400 px på sidan, så laddas ändå hela den stora bilden ner.

Detta leder till två problem:

1. Filen blir onödigt stor och tar längre tid att ladda.
2. Webbläsaren måste skala om bilden, vilket tar extra resurser.

Det är också viktigt att förstå att när både bredd och höjd minskar så minskar bildens yta ännu mer, eftersom ytan beräknas som bredd × höjd.

Varför storlek gör så stor skillnad

I bilden nedan ser du att om både bredd och höjd minskas till 1/3 av originalet så återstår bara 1/9 av bildens yta (ca 11 %). Eftersom en bild består av pixlar över en yta kan även filstorleken minska ungefär lika mycket, vilket ofta ger stor förbättring i laddningstid.

När du arbetar med egna HTML-sidor bör du därför alltid anpassa bildens storlek innan du använder den på sidan, t.ex. genom att ändra storlek i ett bildredigeringsprogram eller med ett enkelt onlineverktyg.

Om du snabbt behöver ändra storlek på en bild kan du använda imageresizer.com. Där kan du ange ny bredd eller höjd och ladda ner bilden i rätt storlek direkt.

Om du senare publicerar samma innehåll i WordPress skapar WordPress automatiskt flera storlekar av varje bild, men det är ändå bra att inte ladda upp onödigt stora originalfiler från början.

5.3.4.2 Komprimering – mindre filer med samma bild

Även om en bild har rätt storlek kan filen vara onödigt stor. Bilder innehåller ofta mer information än vad som behövs för att se bra ut på en skärm. Genom att komprimera bilden kan filstorleken minska mycket, ibland utan att man ser någon tydlig skillnad i kvalitet.

De vanligaste bildformaten du kommer att möta är:

• JPEG – passar bäst för fotografier
• PNG – används för grafik och när man behöver transparens
• SVG – vektorformat, mycket bra för logotyper och ikoner

GIF används idag främst för enklare animationer och är sällan ett bra val för vanliga bilder på webbsidor.

För JPEG och PNG kan man ofta minska filstorleken kraftigt med komprimering. Ett enkelt sätt att testa detta är att använda tinypng.com. Du laddar upp din bild och får tillbaka en version med betydligt mindre filstorlek men nästan samma kvalitet.

När du jobbar med egna HTML- och CSS-sidor är detta ett enkelt sätt att förbättra prestanda utan att behöva ändra din kod.

I WordPress sker viss komprimering automatiskt, men den är inte alltid tillräcklig för bästa prestanda. Därför är det fortfarande bra att optimera bilder innan de laddas upp.

5.3.4.3 Moderna bildformat: WebP och AVIF

Utöver JPEG och PNG finns idag modernare bildformat som är särskilt anpassade för webben. De två viktigaste är WebP och AVIF. Dessa format kan ge mycket mindre filer än JPEG och PNG, samtidigt som bildkvaliteten ofta är lika bra eller bättre. Alla moderna webbläsare har idag stöd för dessa format, vilket gör dem lämpliga att använda på vanliga webbsidor.

Det är därför idag vanligt och rekommenderat att konvertera bilder till WebP eller AVIF, särskilt för fotografier. När du arbetar med egna HTML-sidor kan du själv göra detta med hjälp av olika verktyg eller bildredigeringsprogram. Ett enkelt sätt är att använda freeconvert.com, där du väljer vilket format bilden ska konverteras till och sedan laddar ner den färdiga filen.

I WordPress skapas ofta WebP-versioner automatiskt (beroende på version, tema och webbhotell), vilket innebär att besökaren kan få en mer optimerad bild även om du laddat upp en JPEG- eller PNG-fil.

När man använder nyare tekniker på webben är det viktigt att kontrollera att de faktiskt stöds av de webbläsare som användarna har. En vanlig tjänst för detta är caniuse.com, där du kan söka på en teknik och se vilka webbläsare som har stöd för den och från vilka versioner. Det är också ett bra sätt att se hur webben förändras över tid, eftersom tekniker som är aktuella idag kan ersättas av nya lösningar i framtiden.

5.3.4.4 Bildredigering och verktyg

Denna kurs kräver inte att du ska kunna arbeta avancerat i bildredigeringsprogram, men ibland behöver du ändå kunna:

• ändra storlek på bilder
• beskära bilder
• spara i lämpligt format

Det finns många verktyg för detta, men nedan är några enkla och tillräckliga alternativ som fungerar bra för kursens behov:

• Pixlr Express – webbaserat bildredigeringsprogram där du kan beskära, ändra storlek och göra enklare justeringar.
• ImageResizer – mycket enkelt verktyg för att snabbt ändra storlek på bilder.
• TinyPNG – komprimerar JPEG- och PNG-bilder så att filstorleken minskar.
• FreeConvert – konverterar bilder mellan olika format, t.ex. till WebP eller AVIF.

Du behöver inte använda alla dessa verktyg. Ofta räcker det med ett eller två, beroende på vad du behöver göra med bilden. Det viktiga är att du anpassar bilderna för webben innan du använder dem i din HTML och CSS.

5.4 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 för så många som möjligt. Ungefär var femte person har behov av någon form av tillgänglighetsanpassning. Här är några vanliga behov som vi behöver bygga in lösningar för:

• Synnedsättning – till exempel nedsatt syn, färgblindhet eller blindhet. Kan innebära behov av skärmläsare, hög kontrast, möjlighet att förstora text och tydlig struktur.
• Hörselnedsättning – till exempel dövhet eller nedsatt hörsel. Kan innebära behov av textning på video och att viktig information inte bara ges via ljud.
• Motoriska svårigheter – till exempel skakningar, förlamning eller svårigheter att använda mus. Kan innebära behov av att kunna navigera med tangentbord och ha tillräckligt stora klickytor.
• Kognitiva svårigheter – till exempel koncentrationssvårigheter, minnesproblem, dyslexi eller språkstörningar. Kan innebära behov av tydligt språk, enkel navigation och förutsägbar layout.
• Tillfälliga eller situationsberoende begränsningar – till exempel brutna armar, starkt solljus på mobilen, dålig internetuppkoppling eller stress. Samma tillgänglighetslösningar hjälper ofta även här.

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/WCAG20-sv-20121023/#perceivable, avläst 2020-09-28.

Princip 2: Hanterbar - Komponenter i ett användargränssnitt och navigering måste vara hanterbara.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#operable, avläst 2020-09-28.

Princip 3: Begriplig - Information och hantering av användargränssnitt måste vara begriplig.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#understandable, avläst 2020-09-28.

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/WCAG20-sv-20121023/#robust, avläst 2020-09-28.

Innan vi kikar vidare lite mer detaljerat så behöver vi få koll på vissa saker. DOS-lagen är det första och det står för Lag om tillgänglighet till digital offentlig service och är en lag som tagits fram för att statliga organisationer skall tvingas hålla en viss kvalitet i sin tillgänglighet. WCAG har tre nivåer som man behöver förhålla sig till, A (lägsta nivån), AA och AAA (högsta nivån) där lägsta nivån är relevant även för våra applikationer. Under 2025 så införs också Tillgänglighetsdirektivet 2025 som är ett krav från EU och som kompletterar DOS-lagen så att det även ställs krav på att företagens digitala tjänster har god tillgänglighet.

5.4.1 Webbriktlinjer.se

DIGG (Myndigheten för digital förvaltning) har en hemsida,Webbriktlinjer, där de listar alla riktlinjer för tillgänglighet på webben. Här går det att visa alla riktlinjer men också söka efter alla WCAG-krav på nivå A, vilket är den lägsta nivån och de kraven som är mest aktuella för oss. För oss är det naturligtvis intressant att kika på alla krav som gäller koden också.

Det finns andra tjänster som är intressanta att kika på när det gäller tillgänglighet. Webaim har relativt tydliga instruktioner vad varje krav innehåller på ett lättöverskådligt sätt och weboverhauls har en smidig checklista som kan användas när du testar av en webbsida.

5.4.2 Tjänster för att testa tillgänglighet

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. Fördelen med denna plugin är att du kan testa sidan utan att behöva ladda upp den på din domän.
• 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.
• En sida, PageSpeed Insights, som vi använde tidigare när vi kollade på prestanda ger också tips på tillgänglighet och även lite annat smått och gott som kollas. Vill man gå på djupet av en av testerna kanske det inte är den bästa sidan, men som en generell översikt över vad som bäst behöver förbättras så borde den fungera bra.

5.4.3 Manuell testning och vanliga fel

Automatiska testverktyg som WAVE och Eiii är bra hjälpmedel, men de kan inte hitta alla tillgänglighetsproblem. Därför är det viktigt att också förstå vanliga fel i HTML och CSS som påverkar användare med olika behov, och att kunna kontrollera dessa manuellt i koden.

Nedan följer några av de vanligaste tillgänglighetsproblemen på enklare webbplatser och vad du som utvecklare bör tänka på.

5.4.3.1 Bilder utan alternativ text

Alla bilder som förmedlar information ska ha ett alt-attribut.

• Om bilden är viktig: beskriv innehållet kort i alt.
• Om bilden bara är dekoration: använd tom alt-text alt="".

<img src="hund.jpg" alt="En brun hund som springer på stranden">
  

Skärmläsare läser upp alt-texten för användare som inte ser bilden.

5.4.3.2 Fel rubrikstruktur

Rubriker ska användas i rätt ordning och för struktur, inte bara för att ändra storlek på text (då skall css användas).

• Det ska bara finnas en <h1> per sida.
• Hoppa inte över nivåer (t.ex. från <h2> direkt till <h4>).

<h1>Startsida</h1>
<h2>Nyheter</h2>
<h3>Senaste uppdateringarna</h3>
  

Korrekt struktur hjälper skärmläsare, användare som snabbt vill skumma sidan och sökmotorer.

5.4.3.3 Länkar med otydlig text

Länkar ska fungera även om de läses utan sammanhang.

<a href="info.html">Klicka här</a>
  

<a href="info.html">Läs mer om utbildningen</a>
  

Skärmläsare kan lista alla länkar på en sida – då måste varje länk vara begriplig i sig.

5.4.3.4 Formulär utan koppling mellan label och input

Alla formulärfält ska ha en tydlig etikett som är kopplad till rätt input.

<label for="email">E-post</label>
<input type="email" id="email">
  

Detta är viktigt för skärmläsare och för användare som klickar på texten istället för i fältet.

5.4.3.5 Låg kontrast mellan text och bakgrund

Text måste ha tillräcklig kontrast mot bakgrunden för att vara lätt att läsa.

Problem uppstår ofta när man använder ljus text på ljus bakgrund, text ovanpå bilder eller grå text på vit bakgrund.

Detta påverkar särskilt personer med nedsatt syn och användare i starkt ljus (t.ex. mobil utomhus). Kontrastfel är ett av de vanligaste problemen som automatiska tester hittar.

<p style="color:#cccccc; background:#ffffff;">
  Text som kan vara svår att läsa
</p>
  

5.4.3.6 Klickbara element som inte är riktiga knappar eller länkar

Interaktiva funktioner ska använda rätt HTML-element.

• Använd <a> för länkar.
• Använd <button> för knappar.

<div onclick="skickaForm()">Skicka</div>
  

<button type="submit">Skicka</button>
  

Undvik att göra klickbara funktioner med bara <div> och JavaScript, eftersom de inte alltid fungerar med tangentbord och hjälpmedel inte alltid tolkar dem som klickbara.

Tillgänglighet handlar inte bara om att klara tester, utan om att bygga sidor som fungerar för olika typer av användare. Genom att använda korrekt HTML, tydlig struktur och bra kontraster kan många tillgänglighetsproblem undvikas redan från början.

5.5 Redovisning

5.5.1 Frivilliga uppgifter

Ett ganska teoritungt moment där du förhoppningsvis har lärt dig en hel del saker som givit dig inspiration till att förändra webbsidor du har byggt tidigare, söka mer information om något område vi har tagit upp under momentet eller skapat sug att bygga någon ny webbsida.

Har du tid över så använd denna på något bra sätt inom webbutveckling. Har du planer på att göra ditt gymnasiearbete inom webbutveckling så kanske delar av detta momentet kommer vara en del av det arbetet.