Rekommendationer för HTML-kompatibilitetLänk hit

• Följ en HTML-standard från W3C
• Testa och åtgärda problem i de kombinationer av webbläsare, operativsystem och hårdvara som är vanligast i målgruppen.
• Testa och åtgärda problem med de hjälpmedel (exempelvis skärmläsare) som är vanligast i målgruppen
• Var lyhörd för användarnas problem och följ upp användningen

Följ en HTML-standard från W3CLänk hit

Grundkravet att webbplatsen ska följa standarder (R80) innebär när det gäller sidans grundläggande kod att det är HTML enligt rekommendation från webbens standardorganisation W3C (the Worldwide web consortium).

För nya webbplatser bör den senaste stabila rekommendationen användas, så snart det finns tillräckligt stöd för den i de webbläsare som används av målgruppen. För närvarande (maj 2018) är detta version 5.2.

Att byta html-version för en befintlig webbplats innebär i praktiken oftast en fullständig omdesign. Eftersom html-specifikationen ställer stora krav på webbläsare att vara bakåtkompatibla så är det sällan nödvändigt att byta version bara för att det  finns en nyare version. Byt istället när det blir naturligt i samband med en större förnyelse av webbplatsen eller när ni behöver använda er av egenskaper som bara finns i en nyare version.

Oavsett val av HTML-version är det viktigt att följa Se till att koden validerar (R84).

Att använda en standardiserad html-version korrekt är en relativt enkel och billig åtgärd som gör att resultatet blir bra för de flesta användarna.

Testa och åtgärda problem i de kombinationer av webbläsare, operativsystem och hårdvara som är vanligast i målgruppenLänk hit

Ni är inte skyldiga att stödja webbläsare som kraftigt avviker från standarden, till exempel äldre webbläsare. Dessa kan fortfarande visa innehållet, men presentationen och funktionerna kanske inte fungerar som ni avsett. Följ webbstatistik och gör en bedömning vilka ni behöver stödja.

Men eftersom vissa organisationer använder gamla webbläsare, och det finns brister även i uppdaterade webbläsare räcker inte grundkravet för att skapa en webbplats som fungerar för precis alla. Varje projekt behöver alltså, förutom att uppfylla grundkravet, se till att resultatet i praktiken blir tillräckligt bra för tillräckligt många. Det finns verktyg för systematisk (delvis automatiserad) testning i olika kombinationer av webbläsare, skärmstorlek och operativsystem men tyvärr är det omöjligt att uppnå 100%. Var gränsen för tillräckligt går behöver därför anpassas efter behov, konsekvenser och resurser:

• För en webbplats med höga krav (exempelvis Skatteverkets e-tjänst för deklaration) kanske det, förutom grundkravet, är rimligt att varje sida testas och åtgärdas för att fungera i de webbläsare som tillsammans har en marknadsandel på exempelvis 99%.
• För en webbplats med mer genomsnittliga krav (exempelvis en skolas webbplats) kan det vara rimligt att förutom grundkravet om validerande kod även testa varje sidtyp med de fem vanligaste webbläsarmodellerna på åtminstone tre olika typiska skärmupplösningar.
• För en webbplats med fokus på budget och snabbhet  (exempelvis en projektsajt) kan det kanske räcka att validera koden, testa all ny funktionalitet med de två webbläsare som är vanligast i målgruppen, och uppmana användare att rapportera in problem.

Det finns webbläsarstatistik på till exempel https://browsersverige.se men kanske får du mer relevant statistik för just din målgrupp i din egen webbanalys.

Testa och åtgärda problem med de hjälpmedel (exempelvis skärmläsare) som är vanligast i målgruppenLänk hit

Även när det gäller test i hjälpmedel måste ambitionsnivå anpassas efter behov, konsekvenser och resurser.

Utifrån statistik om skärmläsare och tips från Synskadades riksförbund föreslår vi följande:

• För en webbplats med höga krav, testa och åtgärda problem med åtminstone skärmläsarna Jaws, Supernova, VoiceOver, Narrator.
• För en webbplats med mer genomsnittliga krav, testa och åtgärda problem med skärmläsarna VoiceOver/iOS och Jaws/Windows.
• Testa alltid med åtminstone EN skärmläsare, förslagsvis VoiceOver på iOS.

Var lyhörd för användarnas problem och följ upp användningenLänk hit

Oavsett kravnivå är det alltid lämpligt att, så långt som resurserna räcker, följa upp användningsstatistik och kundtjänstärenden för att kunna åtgärda återkommande problem. Se artikeln Följ upp hur webbplatsen används.

Och självklart är det viktigt att vara lyhörd för kommentarer från användarna. Se Möjliggör synpunkter, frågor och dialog (R38).

MätbarhetLänk hit

För att kontrollera om en sida följer den standard ni valt för uppmärkningskod kan ni använda W3C:s valideringsverktyg. Verktyget kan utgå från länkar till sidor eller uppladdad HTML-kod för sidor som ännu inte är publikt tillgängliga. W3C har även ett verktyg för att kontrollera stilmallar.

FördjupningLänk hit

• Generell statistik om olika webbläsare: internationellt och i Sverige.
• Can I Use är ett bra verktyg för den som vill undersöka vilka webbläsare som har stöd för olika delar av html, javascript och css.
• Tillgänglighetssupport i olika webbläsare för HTML 5
• Senaste versionen av HTML 5

TerminologiLänk hit

Webbutvecklare som vill använda funktioner som vissa användares utrustning ännu inte kan hantera väljer ibland att använda så kallade shims eller polyfills. En shim eller polyfill för HTML5 är ett tillägg som tillför funktionalitet som saknas (oftast JavaScript-kod). Metoden har sina fördelar, men tänk på grundprincipen om progressiv förbättring, som beskrivs i webbriktlinjen Använd Javascript för att öka tillgängligheten – inte tvärtom (R93).