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. Denna sidan innehåller en mängd utvalda artiklar om internets historia med start på 1960-talet och framåt. Varje artikel belyser ett visst ämne, fenomen eller händelse som har påverkat internets utveckling. Många artiklar innehåller grymma 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. Jag tycker att du skall ta avstamp i uppgiften genom att läsa igenom denna text.

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

Uppgift: Internets historia

För att lösa denna uppgift så har du antingen fått en genomgång på internetmuseum.se eller så läser du igenom artikeln om internets historia.

  • Välj 2-3 av händelserna(artiklarna) som du tycker verkar intressanta från olika decennier. Läs på mer om händelsen/tekniken/företeelsen och skriv ett inlägg på din Wordpress om just detta. Glöm inte bort ditt valda inläggs påverkan på samhället.

  • Välj nu ytterligare en teknik/företeelse som du ger en historik för, du beskriver nuläget och du försöker dig på en framtidstanke. Hur tror du att detta ser ut om X antal år? (Exempel. Snapchat skapades 2011, hur används det idag? Hur har det påverkat nätet? Vad tror du om Snapchats framtid?)

Uppgiften är väldigt fri att göra vad du vill av den. Det enda fel som kan uppstå är om du inte håller dig till historiska fakta. Framtiden kan ingen sia om så din analys är så god som någon. Glöm inte att ange källor för den fakta som du använder.

Tänk på de kunskapskrav som vi bara testar i detta moment. Du får givetvis chansen att göra om uppgiften senare på en djupare nivå om du vill, men enklast för dig är att göra uppgiften på rätt nivå direkt.

Kunskapskrav

Text

Betyget E

Betyget C

Betyget A

1. Webbens påverkan

Eleven beskriver [1] webbens historia och dess påverkan på samhället och de grundläggande tekniker som webben bygger på.

[1] översiktligt

[1] utförligt

[1] utförligt och nyanserat

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

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.

Denna sidans validering

Som du märker så blir inte denna sidan godkänd vare sig när det gäller html eller css. Målet är naturligtvis att ha noll fel, eller så få fel som det bara är möjligt, men det är inte alltid möjligt.

När jag körde html-valideringen, 2020-10-07, så fick jag 15 noteringar om saker som validatorn inte var nöjd med. Nio punkter var markerade som Error som naturligtvis är av allvarligare karaktär än mina sex Warnings. Fem av felen som markeras gäller kod som jag har kopierat av de som tillhandahåller tjänsten; google fonts, youtube och statcounter.com. Alla dessa koder går att rätta men det innebär också att det finns risk att denna kod inte ger önskat resultat eller att de genererar något fel någonstans. Därför ändrar jag inte dessa koder.

Fyra error beror på att jag använder <strike>-elementet för att skapa genomstruken text. Detta element är föråldrat och skall lösas mha css istället. Detta bör jag ändra för att framtidssäkra webbsidan till kommande uppdateringar av webbläsaren. Detta är också bevis på att något som tidigare var tillåtet nu inte längre är det.
<strike>-elementet kan enkelt bytas ut mot <del>-elementet som formatteringsmässigt gör samma sak. <del> används för att markera borttagen text.

Varningarna består främst av att jag har talat om vilken typ mina <style>- och <script>-element har. Det behövs inte längre så denna koden borde jag ta bort.

När det gäller css-felen så kommer de allra flesta av dessa ifrån mitt css-ramverk som heter mui. Kanske finns det en ny, uppdaterad version av denna kod. Men eftersom utseendet fungerar som jag vill så är jag lite restriktiv med att uppdatera dessa filer. Här kör jag enligt devisen If it ain't broke, don't fix it. Om vi däremot skall leverera detta till en kund som ställer krav på att det inte får finnas fel så behöver vi hitta lösningar på detta.

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 skiter i 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.

Uppgift: Validering

Detta har vi tagit upp tidigare. Har du tidigare validerat dina sidor för html/css så behöver du inte göra denna uppgiften nu. Har du däremot aldrig validerat någon sida så är det hög tid.

Testa din aktuella landing page mot validatorerna för HTML5 och CSS. Ta en skärmdump (shift+cmd+4 för del av skärm / shift+cmd+3 för hel skärm) på de varningar och/eller error du får och försök se vad validatorn vill att du ändrar. Fundera på vad du vill/(måste) ändra och gör dessa ändringar. När du är nöjd så validerar du sidan igen och tar en skärmdump på resultatet.

Skriv ett inlägg på din Wordpress där du visar den första skärmdumpen, berättar kortfattat vad du ändrar, eller varför du inte ändrar om du nu har valt att inte göra det (att inte ändra för att man inte orkar är inget godkänt argument), samt skärmdump på resultatet efter ändringen.

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.

StatCounter Global Stats - Screen Resolution Market Share

Source: StatCounter Global Stats - Browser Market Share

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.

Blixten McBrackets

Om du har följt Eriks exempel från webbkoda så har du troligtvis lärt dig att använda den blixten som finns inbyggd i Brackets för att snabbt och enkelt kunna se hur dina koder förändrar en sidas utseende direkt.

Fördelen med blixten är uppenbar när vi utvecklar en sida. Nackdelen kommer bli tydlig nu när vi skall kika lite mer ingående i den koden som vi skriver. Blixten använder sig nämligen av en inbyggd server som förändrar koden och lägger framförallt till en hel mängd klasser. Detta gör arbetet som vi skall göra här nedan mycket svårare.

Alternativet till blixten är att öppna webbsidan direkt i en webbläsare utan att gå vägen via blixten. Enklast gör du detta genom att dubbelklicka på html-filen i Finder.

Öppna inspekteraren

Bild

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

Bild

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

Bild

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 har ett verktyg som testar om din webbsida anses mobilanpassad. Numera så är kursolle godkänd utifrån mobilanpassning. Om sidan inte blir godkänd så får jag hjälp med hur jag kan åtgärda problemen. Vi återkommer till detta verktyg och denna validering i nästa moment.

Uppgift: Användande av användaragenter och utvecklingsverktyg

Några småuppdrag blir denna delens uppgift;

  1. Ta en skärmdump på utvecklarläget i dina två valda webbläsare där du visar hur din landing page ser ut på valfri smartphone och tablet. Totalt fyra bilder.
  2. Validera också din landing page och se om den är mobilanpassad, reflektera över ditt resultat utan att behöva ändra, det kommer vi göra i nästa moment. Har du en idé om vad du vill göra för att få ett bättre betyg så får du naturligtvis testa detta. Om du uppdaterar se till att lägga med den nya bilden i din redovisning.

Uppgiften redovisas i ett eller flera inlägg på din Wordpress.

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.

Fördelen med detta avsnittet är att det är relativt enkelt att med hjälp av olika verktyg på nätet. Jag kommer länka till fyra 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 fyra 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. Börja gärna med den.
  • GTmetrix, 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.
  • Webpagetest, liknar GTmetrix.
  • 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 fyra 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, 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.
  • 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å 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.

Uppgift: Prestanda

Uppgiften är att testa prestanda på en sida du har skapat samt att göra en enkel justering och se om du kan påverka prestandan på något sätt.

  • Välj en sida från Paolos Webb som du har skapat. Välj gärna en med några bilder på. Kör nu denna sidan genom alla fyra tjänster som länkades ovan. Ta en skärmdump av varje resultat och skriv gärna någon kommentar om vad du fick fram när det gäller prestanda. Kanske är det så att alla fyra tjänsterna pekar på samma sak?
  • Nu vill jag att du väljer en av verktygen för att komprimera din kod. Komprimera både html och css för den sidan du redan har testat prestandan på. När du har lagt upp de nya filerna så väljer du att köra om det testet som på bästa sättet mätte, och redovisade, resultatet för laddtiden för html och css. Vilket resultat fick du fram nu? Påverkades laddtiden? Påverkades totalbetyget för din prestanda?

Uppgiften redovisas i ett eller flera inlägg på din Wordpress. Träna på att dokumentera denna testprocess, det kommer du att göra i skarpt läge senare i ditt slutprojekt.

5.3.4 Bildformat

När du har gjort prestandatester på dina webbsidor så återkommer hela tiden olika kommentarer om bilder och hur detta påverkar sidans prestanda. Då är det väl dags att vi kikar även på detta.

Elevexempel

Bild

Här har jag testat med en sida från Paolos Webb som en elev har lämnat in. Här är det ganska tydligt att det är bilder som på olika sätt tar mest tid för att ladda ner.

5.3.4.1 Bilder i rätt storlek

En bild som du publicerar på en webbsida bör visas upp i den storlek som bilden har. Om du väljer att skala ner en stor bild till ett mindre format på webbsidan så får du två problem när det gäller prestanda.

  1. En större bild, som innehåller fler pixlar, tar mer utrymme och kommer då också behöva mer bandbredd för att skickas till användaragenten där den skall visas upp.
  2. En bild som inte är i rätt storlek måste förminskas, eller förstoras, i webbläsaren vilket tar onödig tid.

Enklast är att skapa filen i rätt storlek från början i något bildredigeringsprogram men det finns också tjänster online för detta. Två av dessa tjänster är resizeimage.net och picresize.com.

5.3.4.2 Optimera bilder

Det finns flera olika bildformat som kan användas på webben. De klassiska formaten är JPEG/PNG/GIF/SVG. PNG och JPEG lämpar sig bäst för bilder, GIF lämpar sig för enklare bilder som logotyper och SVG är vektorbaserad vilket gör att den är knivskarp även om man zoomar in den bilden.

Om du använder bilder som finns på nätet så är du oftast fast i den typ som bilden redan har. Att konvertera från ett bildformat till ett annat är sällan bra då du tappar kvalitet i konverteringen. Mer intressant är det om du skapar egna bilder i tex Photoshop och kan välja vilket format och kvalitet som bilden skall visas i. Läs mer om de vanligaste bildformaten.

Det som däremot är intressant att göra med redan skapade bilder är att optimera dem och se till att bilden får en mindre filstorlek. Denna funktionen finns i de flesta bildredigeringsprogram men det finns också tjänster på nätet för detta. Här brukar jag använda tinypng som komprimerar både jpeg och png på ett bra sätt.

5.3.4.3 Nya bildformat

I statistik som httparchive.org presenterar så är ca 50% av den totala vikten på en hemsida bilder. De äldre bildformaten har vissa problem med komprimering och det har länge varit tydligt att det är dags att uppgradera bildformaten. De senaste åren har de kommit fram flera olika exempel på nya bildformat och Metamatrix har en bra genomgång av dessa. De nya formaten är inte kompatibla med alla webbläsare i skrivande stund (oktober 2020) men kompabiliteten kommer bli bättre och bättre ju längre tiden går. WebP är det bildformatet som för tillfället har kommit längst då det endast är Safari som inte har full kompabilitet. Vill du se vilka format som är kompatibla med vilken webbläsare så finns den infon här.

5.3.4.4 Bildredigeringsprogram

Denna kursen kräver inte att du skall kunna skapa egna bilder i ett bildredigeringsprogram men om du är van vid att använda tex PhotoShop så har du ju där ett verktyg som hjälper dig att skapa content till dina webbsidor. Det finns användbara program såsom Gimp att ladda ner från nätet och det finns också flera kraftfulla photoshopliknande onlineapplikationer.

Uppgift: Optimerade bilder

Gå tillbaka till de prestandatester du gjorde i förra uppgiften. Troligtvis har du fått information om att du kan/bör optimera dina bilder på något sätt.

  • Visa med en skärmdump vilken feedback du fick angående dina bilder. Ta en ny om du behöver.
  • Gör en kort analys om vad du kan göra för att förbättra prestandan enligt den information du har fått.
  • Utför det som du har kommit fram till.
  • Lägg upp de nya bilderna, den nya koden, eller vad du nu har gjort för att förbättra prestandan.
  • Kör samma test som tidigare för att få ett nytt värde.
  • Resonera om din åtgärd fick väntad effekt. Om den fick önskad effekt, är du nöjd? Om den inte fick önskad effekt, kan du göra någon annat åtgärd?

Uppgiften redovisas i ett eller flera inlägg på din Wordpress. Träna på att dokumentera denna testprocess, det kommer du att göra i skarpt läge senare i ditt slutprojekt.

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 hittar du exempel på användare med olika behov.

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.

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. Här finns möjlighet att filtrera riktlinjerna på ett antal sätt, kanske vill du ha koll på vad man behöver tänka på när vi skall bygga en användarvänlig navigation eller så kikar vi på alla riktlinjer som har klassificeras med prio 1. Vad säger tex Riktlinje91? Detta är något vi skall jobba med i nästa moment.

Ur ett tekniskt perspektiv tycker jag att följande filtrering Teknik & kod, prioritet 1 kan vara en bra sammanfattning av de viktigaste sakerna vi behöver tänka på inom ramen för denna kursen.

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.
  • 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. Tänk på att verktyg både kan tillkomma och försvinna.
  • 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.

Uppgift: Tillgänglighet

Några småuppdrag blir denna delens uppgift, vid tillgänglighetskontroller vill jag minst att du förhåller dig till WCAG's nivå A (den lägsta nivån) då detta är ett grundkrav för kursen. För högre betyg kommer du inte kunna blunda för samtliga AA-krav heller.

  1. Kör en kontroll av din landing page med wave.webaim.org. Ta en skärmdump av resultatet, ändra det som eventuellt behöver ändras och testa igen. Dokumentera och resonera kring de ändringar du har gjort.
  2. Gör också en kontroll av din landing page med Eiii Page Checker. Ta en skärmdump av resultatet, ändra det som eventuellt behöver ändras och testa igen. Dokumentera och resonera kring de ändringar du har gjort.
  3. Om du blev nyfiken på någon annan tjänst och har testat den så lägg upp resultat och reflektioner av detta test.

Uppgiften redovisas i ett eller flera inlägg på din Wordpress.

I detta avsnitt så testar vi följande kunskapskrav. Flera av dessa kommer vi senare testa även i slutprojektet.

Kunskapskrav

Text

Betyget E

Betyget C

Betyget A

3. Kodkvalitet

I arbetet utvecklar eleven kod som med [5] resultat följer standarder och som omfattar [6] av de grundläggande teknikerna för märkspråk och stilmallar. [7]

[5] tillfredsställande

[6] några

[7] [inget]

[5] tillfredsställande

[6] några

[7] I produkten infogar eleven enkla diskreta domskript.

[5] gott

[6] flera

[7] I produkten infogar eleven diskreta domskript.

6. Produktens kvalitet

Produkten är av [11] kvalitet och följer etablerad god praxis. [12]

[11] tillfredsställande

[12] [inget]

[11] tillfredsställande

[12] Detta kontrollerar eleven med några tester.

[11] god

[12] Detta kontrollerar eleven både manuellt och med flera tester.

7. Testning

Eleven testar produkten [13], samt [14] för att åstadkomma snabb överföring [15].

[13] i några webbläsare

[14] vidtar några enkla åtgärder

[15] av bilder och andra mediafiler.

[13] på flera plattformar, inklusive traditionella datorer och mobila enheter

[14] vidtar några åtgärder

[15] av bilder och andra mediafiler.

[13] på flera plattformar, inklusive traditionella datorer och mobila enheter

[14] optimerar bilder och andra mediafiler

[15] och vidtar åtgärder för att reducera antalet överföringar per sida.

8. Tillgänglighet

Dessutom bygger eleven en webbplats som med [16] resultat följer grundläggande principer för tillgänglighet [17].

[16] tillfredsställande

[17] [inget]

[16] tillfredsställande

[17] och kontrollerar detta med några automatiserade tester.

[17] gott

[18] och kontrollerar detta med automatiserade tester och simuleringar.

5.5 Redovisning

Inlämningsuppgift: Redovisning av Moment05

Under momentets gång har du gjort flera olika uppgifter, dessa skall publiceras på något sätt på din WordPress. Enklast är nog att hålla isär de olika uppgifterna och presentera dem var och en för sig. Men det är ditt beslut, du avgör själv.

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.