Utkast ny webbriktlinje 81 om HTML-versioner
31 maj, 2018Här följer ett utkast till ny version av riktlinjen Utveckla webbplatsen enligt en standard snarare än för en webbläsare (R81).
OBS! Gå till riktlinjen. Utkastet finns bara kvar av historiska skäl.
Utveckla webbplatsen enligt en standard, snarare än för en webbläsare
Följ en webbstandard när ni utvecklar er webbplats, så kan ni vara mer säkra på att koden kommer att fungera även i kommande webbläsare. Testa med de kombinationer av utrustning som är vanligast i målgruppen.
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).
Kommentarer (2)
Övergripande
Tester ska göras i tre steg:
1. Utvecklaren säkerställer att inga jätteallvarliga brister finns när det gäller kompatibiliteten med hjälpmedel.
2. Systematiska tester görs med avancerade användare.
3. Systematiska tester görs med medelgoda användare.
Detta är extra viktigt vid större uppdateringar, men även en mindre ändring som inte påverkar de flesta användare kan få stora konsekvenser för den som använder hjälpmedel.
Testa och åtgärda problem
”• Testa alltid med åtminstone EN skärmläsare, förslagsvis VoiceOver på iOS.”
Tester med skärmläsare ska alltid göras både på mobiltelefoner/surfplattor (IOS och Android) och på datorer (windows/Mac)
Även förstoringsprogram bör nämnas som ett exempel på hjälpmedel. Förstoring bgöms ofta bort, rent generelllt.
Skriv kommentar
Funktionen för att skriva kommentarer använder kakor. Läs mer om kakorna. Enbart förstapartskakor används. Vill du inte godkänna kakor så kan du ställa in din webbläsare att blockera dem. Funktionen går ändå att använda men den kommer då att ställa vissa frågor om och om igen, och kan inte förhandsvisa dina kommentarer.
För att kunna erbjuda denna funktion behöver vi lagra de uppgifter som du själv skriver in (namn, e-post, eventuell webbadress och själva kommentaren) samt IP-nummer. Den rättsliga grunden är samtycke och informationen ligger kvar så länge DIGG bedömer att den tillför förståelse för riktlinjen, eller tills du begär att den raderas. Läs mer om DIGGs behandling av personuppgifter.