Verifiering och utvärdering

Verktyg testar det mätbara, du testar resten

Validatorn, WAVE och Lighthouse ger dig objektiva siffror. De kan inte avgöra om din hamburgermeny känns förvirrande att använda på en riktig telefon. De kan inte säga om texten är förståelig. De kan inte testa om din webbplats fungerar i din besökares webbläsare.

Det är ditt jobb.

Testning-sektionen i din README

Slutresultatet av den här delen är en kort Testning-sektion i företagsprojektets README, en del av dokumentationen som följer med i inlämningen. Så här ser den ut när den är klar:

## Testning

Testad i Chrome 125 och Firefox 127 på Mac, samt Safari på iPhone 15 (iOS 17).

| Verktyg                  | Score / Status   | Datum      |
| ------------------------ | ---------------- | ---------- |
| Validator.nu             | Inga fel         | 2026-05-15 |
| WAVE                     | Inga röda ikoner | 2026-05-15 |
| Lighthouse Accessibility | 96               | 2026-05-15 |
| Lighthouse Performance   | 78               | 2026-05-15 |

**Kända kvarstående problem:**

- Lighthouse Performance 78, bilder är inte WebP-optimerade fullt ut.

Verktygsraderna har du redan, de kommer från testprotokollet i Automatiserad testning. Det som är nytt är första raden och sista stycket: vilka webbläsare och enheter sidan faktiskt testats i, och en ärlig lista över det som återstår. Det är de delarna resten av den här texten handlar om, och varje test utför du på din egen företagssida medan du läser. När du är klar med delen är sektionen ifylld.

Interoperabilitet, fungerar på fler än din dator

Interoperabilitet (ett ord som verkligen är lätt att uttala) betyder att webbplatsen fungerar korrekt i olika webbläsare, på olika enheter och med olika skärmar.

Minimistandard: Testa i Chrome, Firefox och om möjligt Safari. Det finns webbsidor där du kan testa i olika webbläsare utan att installera dem, men många kostar pengar.

Chrome och Firefox är vanligtvis lika. Safari avviker mest, speciellt på iOS där alla webbläsare (även Chrome på iPhone) använder WebKit under huven.

DevTools Device Toolbar är inte riktigt mobilt

DevTools Device Toolbar i Chrome ändrar viewport-storlek och emulerar touch-events. Den kör fortfarande Chromes renderingsmotor. En riktig iPhone kör WebKit. Lägg till det faktum att Safari på iOS har ett eget adressfält som tar plats (därav 100dvh i stället för 100vh i din hero).

Använd Device Toolbar för snabba layoutkontroller. Testa på riktig hårdvara när du kan.

Manuell tillgänglighet

Tangentbordsnavigering

1. Stäng av musen.
2. Tryck Tab. Flyttar sig fokus till rätt element? Syns fokusringen?
3. Tabb dig igenom hela sidan. Kan du nå alla knappar, länkar och formulärfält?
4. Tryck Enter på en knapp. Händer rätt sak?
5. Testa hamburger-menyn: Tab till knappen, Enter för att öppna, Tab till nav-länkarna.

Om fokus hoppar slumpmässigt, försvinner, eller om fokusringen inte syns så är webbplatsen oanvändbar för tangentbordsanvändare.

Snabb skärmläsartest

Du behöver inte vara expert. Aktivera VoiceOver (Mac: Cmd + F5) eller ladda ner NVDA (Windows, gratis) och navigera 30 sekunder. Lyssna:

• Annonseras din hamburgermeny-knapp som “öppen” eller “stängd” (aria-expanded)?
• Läses alt-texter upp för bilderna?
• Hoppar skärmläsaren förbi landmärken (<header>, <nav>, <main>) eller läser den allt?

Testa med en kompis

Ge en klasskamrat din URL och dina uppgifter utan att förklara hur webbplatsen fungerar. Ställ en uppgift: “Hitta kontaktinformationen” eller “Ta dig till sidan Om oss”. Observera tyst:

• Förstår de genast vad webbplatsen handlar om?
• Hittar de menyn utan att du pekar?
• Fastnar de någonstans?

Det du ser är din webbplats genom en ny besökares ögon. Det är din bästa buggrapport.

Formulera motiverade omdömen

Sista stycket i Testning-sektionen, och utvärderingen i README:n, kräver något verktygen aldrig kan ge dig: omdöme. En professionell kan inte svara “det ser bra ut” på frågan varför de valde en viss lösning.

Utan motivering:

“Jag valde mörkblå bakgrund i hero.”

Med motivering:

“Jag valde #1e3a5f som hero-bakgrund eftersom den är mörk nog för att WCAG AA-kontrastkravet uppfylls mot vit text (kontrastförhållande 9.4:1), och den blå tonen matchar företagets varumärkesfärger.”

Koppla alltid ditt val till ett syfte: tillgänglighet, användarbehov, teknisk anledning, eller branschkonvention.

Pröva i DevTools: tillgänglighetsträdet

1. Högerklicka på din hamburger-knapp och välj Inspektera.
2. I DevTools högra panel, klicka på fliken Accessibility (dold? klicka på >> för fler flikar).
3. Ser du knappens namn och expanded: false? Då har du byggt ett korrekt tillgängligt element.
4. Jämför med ett <div> utan aria-attribut, vad visas?