Webbutveckling · område 5

Projekt 4 – Responsiv och tillgänglig sajt

Deadline tisdag 9 februari kl 23:59. Samma sajt som i Projekt 2, nu för telefon, tangentbord och skärmläsare.

1. Uppdraget

Du ska göra din sajt från Projekt 2 responsiv och tillgänglig. Ingen ny sajt och inget nytt ämne. Det är samma sidor, och de ska nu fungera på en telefon och för den som inte använder mus eller inte ser skärmen.

Den här gången bygger du inte efter dina egna beslut. Du bygger efter två listor som andra har skrivit, eller som du skrivit med andra ögon:

Åtgärdslistan från Gränssnittsdesign. En klasskamrat granskade din inlämnade sajt heuristiskt i december och lämnade en prioriterad lista den 10 december. Den har du haft sedan dess.
WCAG-fynden från din egen granskning. Den 18 januari går du igenom sajten mot en checklista i Gränssnittsdesign. Bristerna du hittar där åtgärdar du här, framför allt i passet den 27 januari.

Blocket har en ordning: granskning → åtgärder → test. Gränssnittsdesign granskar, du åtgärdar här, och den 4 februari testar du sajten på riktiga personer i Gränssnittsdesign. Det som är åtgärdat den 4 februari är det som testas. Därför ligger de viktigaste åtgärderna tidigt i området, inte sist.

Tillgänglighet finns i båda kurserna, och här går gränsen:

Här handlar det om	I Gränssnittsdesign om
Koden som uppfyller ett krav: `label`, `:focus-visible`, kontrast i CSS-variablerna, `prefers-reduced-motion`	Kravet: vad WCAG säger, vem det gäller, nivå A och AA
Media queries, flexibla bilder, `srcset`	Designbeslutet om vad som händer i olika bredder. Det finns redan i din mockup
Testprotokollet: validering, två webbläsare, telefon, tangentbord, ett automatiskt verktyg	Testrapporten: granskning mot WCAG, vad verktygen missar, användartest

Vad ett kriterium betyder lär du dig alltså där. Här handlar allt om koden. Står det synlig fokusmarkering i en lista ska du kunna peka på regeln i stil.css som ger den.

Prov 3 ligger dagen efter inlämningen

Onsdag 10 februari. Det bygger på områdets referensprojekt, fyrsajten från område 3 som nu är responsiv och tillgänglig. Det du gör i din egen sajt är det du skriver för hand på provet.

2. Vad du utgår från

Det här har du redan	Var det kommer ifrån
Den handkodade, stilsatta sajten	Projekt 2, inlämnad 1 december
Mockupen i mobil- och desktopbredd	Uppgift 3 i Gränssnittsdesign, 5 november
Åtgärdslistan: nr, var, vad, prioritet	En klasskamrats granskning, uppgift 4, 10 december
WCAG-fynden med skärmbilder	Din egen granskning i Gränssnittsdesign, 18 januari

Sajten i Google Sites från Projekt 3 är inte den här. Det är den handkodade sajten i ditt repo som gäller.

Mockupen visar redan vad som ska hända i mobilbredd, och det var ett designbeslut. Om den inte räcker, till exempel för att den inte visar hur menyn ser ut på telefon, bestämmer du själv och skriver det i dokumentationen. Du behöver inte gå tillbaka och rita om.

3. Ska-krav

Är alla ikryssade och kontrollerade ligger du på E.

4. Bör-krav

Skillnaden mellan en sajt som råkar fungera och en där du vet varför. Nivå C.

Bör-krav — nivå C

Mobile first: grundstilen är mobilens, och media queries lägger till med min-width, inte tar bort med max-width
Varje brytpunkt har ett skäl i innehållet. Du kan säga vad som går sönder utan den, och ingen brytpunkt heter iPad
Minst en stor bild finns i flera storlekar med srcset, och du har mätt sidvikten på telefon före och efter
Hela åtgärdslistan är genomgången. Varje punkt är åtgärdad eller har ett skäl till varför inte
Varje åtgärd har ett eget commit som nämner punktens nummer, så att den går att hitta i historiken
Rörelse respekterar prefers-reduced-motion, om sajten har övergångar eller animationer
Stilmallen följer kodstandarden från passet den 26 januari: avsnitt i ordning, kommentarer där något inte är självklart, konsekventa namn. Kamratgranskad
Testprotokollet visar felet, åtgärden och omtestet, inte bara att något kontrollerats

5. Utmaningar

Nivå A. Ta dem när ska- och bör-kraven sitter.

Utmaningar — nivå A

En skip-länk, Till innehållet, som syns när den får fokus och fungerar
Sajten fungerar med 200 % textförstoring i webbläsaren utan att text klipps eller överlappar
picture med olika beskärning för mobil och desktop, och du kan motivera den med mockupen
En sida provad med skärmläsare, med anteckning om vad som lät fel och vad du ändrade i koden
Layouten håller i bredder du inte har testat, utan brytpunkter för specialfall. Du kan förklara varför

6. Tekniska krav

Krav	Vad som gäller
Viewport	`<meta name="viewport" content="width=device-width, initial-scale=1">`, exakt så. Inget `maximum-scale`, inget `user-scalable=no`
Bredder	320 px till 1600 px. Testa båda ändarna och dra långsamt mellan dem
Brytpunkter	`min-width`. Så få som möjligt, två eller tre räcker för de flesta sajter
Stilmall	Fortfarande en, `stil.css`. Media queries skrivs i samma fil, i avsnittet de ändrar
Bilder	`max-width: 100%` och `height: auto`. Stora bilder i högst dubbla visningsbredden
Media	Video och ljud har undertexter eller transkript. Har sajten ingen video eller inget ljud, skriv det i dokumentationen
Dokumentationen	`dokumentation.md` i repots rot, med två avsnitt: Åtgärder och Testprotokoll
Åtgärder	Tabell: nr, källa (åtgärdslistan eller WCAG), vad du gjorde, var (fil och selektor eller element), status (åtgärdad, delvis, inte, med skäl)
Testprotokoll	Tabell: test, med vad (webbläsare och version, telefonmodell, verktyg), sida, resultat, åtgärd. Minst en rad per test i ska-kraven
Validering	W3C för både HTML och CSS, noll fel
Var det lämnas	Repolänk och Pages-adress i itslearning

Raden om viewport

Den brukar glömmas. user-scalable=no stänger av förstoringen för den som behöver den mest. Det är ett tillgänglighetsfel i en enda rad.

7. Bedömningsmatris

Kriterium	E	C	A
Responsiv layout	Sajten fungerar från 320 till 1600 px med minst en media query	Mobile first, och brytpunkterna är motiverade av innehållet	Layouten håller i bredder du inte testat, och du kan förklara varför
Bilder och media	Bilderna är flexibla och har fungerande alt-text	Rätt bildstorlek för rätt skärm, sidvikten mätt före och efter	Beskärningen skiljer sig mellan bredder med `picture`, motiverat ur mockupen
Tillgänglighet i koden	Tangentbord, fokus, `label`, rubriker och kontrast är i ordning	Rörelse respekterar användarens val, och koden bär semantiken utan hjälp av CSS	Skip-länk, 200 % förstoring och skärmläsare fungerar och är prövade
Åtgärdslistan	De tre viktigaste punkterna och alla A-fynd är åtgärdade och dokumenterade	Hela listan är genomgången, och varje åtgärd går att hitta i historiken	Du kan visa vad som ändrades mellan granskningen och testet, och varför i den ordningen
Testning och kvalitet	Testprotokollet finns, sajten validerar och är publicerad	Protokollet visar fel, åtgärd och omtest. Stilmallen följer kodstandarden	Testerna har hittat något du inte väntade dig, och protokollet visar vad du gjorde åt det

8. Kom igång

Lägg in viewport-taggen och öppna sajten på en telefon. Gör det första passet, den 13 januari. Skriv upp allt som går sönder innan du rättar något. Det är din lista för de första veckorna.
För över båda listorna till dokumentation.md innan du skriver kod. Åtgärdslistan nu, WCAG-fynden efter den 18 januari. Numrera, ange källa. Då vet du vad som är gjort och vad som återstår, och det gör den som bedömer också.
Börja med det som stoppar någon. Ett fält utan label, en knapp som inte nås med tangentbordet, text som inte går att läsa. Det testas den 4 februari. Brytpunkter och bildstorlekar gör sajten bättre, men de stoppar sällan någon.
Commita en åtgärd i taget. Åtgärd 3: label på sökfältet är ett commit-meddelande som går att hitta i mars. fixar går inte att hitta.

Validering är fortfarande sista steget. Men testa med tangentbordet varje gång du ändrat något. Det tar en minut och är det test som oftast fäller.

9. Vanliga misstag

Brytpunkter efter enheter. 768 för att det är en iPad. Sajten har inga iPads, den har innehåll som får plats eller inte får det. Dra i fönstret tills något går sönder – där är brytpunkten.
Desktop först och lappar nedåt. En stilmall full av max-width som tar bort saker för mindre skärmar blir svårare att ändra för varje brytpunkt. Börja smalt och lägg till.
outline: none för att ringen var ful. Då kan den som använder tangentbordet inte se var hen är. Byt utseende på den, ta aldrig bort den.
Alt-text som beskriver filen. bild1.jpg eller Bild på en fyr. Skriv vad bilden säger i sammanhanget, eller alt="" om den inte säger något.
Åtgärder utan dokumentation. Det som inte står i dokumentation.md finns inte i bedömningen, även om det är rättat i koden.
Full poäng i verktyget, alltså klart. Ett automatiskt verktyg hittar en del av felen. Vilken del går Gränssnittsdesign igenom den 25 januari. Testprotokollet kräver tangentbordet för att verktyget inte räcker.
Åtgärdslistan i den ordning den skrevs. Den är redan prioriterad. Följ prioriteringen, inte det som är roligast att rätta.

10. Innan du lämnar in

Sista passet, 9 februari, är till för det här. Gå igenom i tur och ordning:

Validera HTML och CSS på varje sida. Laga det översta felet först och validera om
Öppna den publicerade adressen på en telefon, inte i device mode. Device mode visar bredden men inte fingret, och inte bilden som laddar över mobilnätet
Dra fönstret från 320 till 1600 pixlar. Ingen vågrät rullningslist, ingen text som klipps
Tabba igenom varje sida utan mus. Ser du hela tiden var du är? Kommer du fram till allt? Kommer du ut igen?
Läs dokumentation.md som om du vore läraren. Har varje punkt i åtgärdslistan en status? Har varje rad i testprotokollet ett resultat?
Lämna båda adresserna i itslearning: repot och den publicerade sidan

Punkt 4 fäller flest

Tangentbordet är det enklaste testet och det som oftast hoppas över. Det tar två minuter per sida, och det är samma sak som testpersonerna i Gränssnittsdesign stöter på först.