Kodestandarder og validering

Standarder er grunnlaget for å få nettsteder, nettlesere og hjelpemiddel til å kommunisere bra med hverandre. Å følge standarder for HTML og CSS er derfor viktig i arbeidet med universell utforming.

Løsninger som møter kravene i forskriften

HTML

Det viktigste er ikke hvilken standard du følger, men heller at du velger en standard og sørger for å følge denne standarden så godt som mulig.

Den nyeste standarden for HTML er HTML5. Du bør unngå for gamle standarder, ettersom de har svakere støtte for universell utforming enn nyere standarder. Bygger du nytt, bør du følge HTML5 eller XHTML 1.0, Transitional eller Strict.

Validering av HTML

Korrekt kode er gunstig for stabil presentasjon på tvers av nettlesere og plattformer, forenkler vedlikehold av nettstedet og er bra med tanke på søkemotoroptimalisering. Ved valg av publiseringssystem kan du med fordel evaluere kvaliteten på koden som systemet genererer.

For å validere HTML-koden kan du bruke W3Cs kodevalidator.

I utviklingsprosessen bør du validere alle sidemaler for å minimere feil i rammeverket. Dette bør gjøres side for side. I tillegg bør det gjøres jevnlige valideringer av et større antall sider for å vedlikeholde kodekvaliteten i redaksjonelt innhold.

Du bør alltid strebe etter å ha fullstendig korrekt kode, men WCAG peker spesifikt ut noen viktige punkt du må følge:

  • Elementene skal ha korrekte start- og avslutningstagger
  • Elementene er strukturert i korrekt hierarki
  • Elementene har ikke duplikate angivelser av samme attributt
  • Hver ID-verdi på en side er unik

Eksempel på korrekt avslutning i XHTML:
<img src=“eksempel.gif“ alt=“element uten egen avslutningstag“ />

Eksempel på feil nøsting av elementer:
<span><p>Block-level elementet for avsnitt inne i inline-elementet span er ikke tillatt.</p></span>

Eksempel på duplikate attributt:
<img alt=“riktig alt-tekst“ alt=“gammel alt-tekst“>

Eksempel på identiske ID-verdier:
<div id=“abc“>Innhold</div>
<div id=“abc“>Relatert innhold</div>

Det er samtidig viktig å være klar over at WAI-ARIA, som er et sett av attributter og verdier laget for å forbedre tilgjengeligheten i HTML, ikke validerer i noen offisielle valideringsverktøy fordi de ikke er offisielt vedtatt. Slike valideringsfeil trenger du ikke ta hensyn til så lenge du bruker WAI-ARIA korrekt.

Noen eksempler på korrekt bruk av WAI-ARIA:

<div role=“button“>Objekt som er klikkbart grunnet javascript.</div>
<div aria-live=“polite“>Område som oppdaterer seg.</div>

Det kan også være andre valideringsfeil som du ikke er nødt til å fjerne. Derfor er det gunstig om rammeverket har færrest mulig feil, slik at det blir enklere å vurdere hvilke feil du bør prioritere å få fjernet.

En utfordring i dag er at mye kode ikke skapes før ved innlasting av siden, eller ut fra brukerens  handlinger. Vanlige tilfeller av innlastet kode er delingsfunksjoner for sosiale medier, dekkende lag som lastes inn eller søkeforslag i den interne søkemotoren. Funksjonene kan være egendefinerte eller utviklet av tredjeparter.

Du må være oppmerksom på all kode som brukeren får presentert, uavhengig av hvor den kommer fra og når den lastes inn. For å kvalitetssikre også den autogenererte koden, vil det være nødvendig med manuell validering og/eller brukertesting med hjelpemidler.

Foreløpig har vi ikke identifisert noen velfungerende valideringsfunksjon som kan validere HTML5 på et stort antall sider på samme tid.

CSS

CSS skal brukes til mest mulig av presentasjonen. Du kan kode mot CSS 2.1 eller CSS 3, men støtten for standardene varierer mellom nettleserne. Blant annet på grunn av dette finnes det også CSS-kode som ikke er en del av standardene, men som brukes for å oppnå ønskede effekter i spesifikke nettlesere.

CSS-koden må være så korrekt som mulig, og du må med andre ord validere denne med en egnet validator som CSS Validation Service (W3C, Engelsk). Du bør minimere bruk av kode utenfor standardene, ettersom disse vil generere feil i valideringen, og det kan gjøre det vanskelig å finne de feilene som kan ha betydning for brukeren.

Anbefalinger utover kravene i forskriften

Generelt er det anbefalt å bygge med HTML5. Hvis du skal gjøre videreutvikling i en eksisterende løsning, eller integrere en eldre løsning i et nytt nettsted, er det ikke alltid mulig å benytte HTML5, men du bør som minimum benytte XHTML. Jo nyere standard du velger, jo mer støtte for universell utforming har du tilgang til.

HTML5

Det er mye bra i HTML5, men det er også mye som ikke er gjennomtestet. Dessuten er det mange eksempler på overivrige utviklere som benytter de nye elementene nærmest bare for å benytte dem , og ikke forholder seg til hvordan elementene er ment å bli brukt.

Gjør veloverveide valg for å inkludere HTML5-elementer som har dokumentert brukernytte, og sørg for å følge retningslinjene for hvordan de nye elementene skal benyttes. Vær også oppmerksom på at det ikke er alle nettlesere og hjelpemidler som er fullt oppdatert til å tolke HTML5, så hold deg oppdatert på hva som er status, og bruk fallback-løsninger hvis nødvendig.

XHTML 1.0 Strict

Dette er antagelig den mest misforståtte standarden. Den har en liten grunnstamme av elementer og attributter, og er tenkt å skulle utvides med ønskede elementer og attributter ved hjelp av en egendefinert Doctype. Av erfaring er det få nettstedseiere som definerer denne utvidelsen, og det er heller ikke laget noen validering som faktisk leser slike utvidelser. Dermed vil du oppleve at koden får mange valideringsfeil uansett om du bruker standarden riktig eller feil.

XHTML 1.0 Transitional

Dette er kanskje den mest brukte standarden, ettersom utvalget elementer og attributter er vesentlig større enn i HTML 4.01 og grunnutvalget i XHTML 1.0 Strict. Av navnet er dette en overgangsstandard som var ment å fungere i overgangen mellom HTML 4.01 og XHTML 1.0 Strict, men Transitional ble værende. Også Transitional kan utvides med ønskede elementer og attributter.

HTML 4.01 Transitional

Dette er den eldste av de vanlig brukte standardene, og også den med færrest muligheter. Har du bygd i HTML 4.01 kan det fungere også fremover, men den bør ikke benyttes når du skal bygge nye løsninger.

Publisert: 01. jul 2015, Sist endret: 18. aug 2017

Deldette

Fant du det du lette etter?

Stjerne(*) er obligatoriske felter som du må fylle ut for å sende skjemaet. 

MERK: Du får ikke svar på denne meldingen. Har du spørsmål du ønsker svar på send oss en e-post til uu@difi.no.

Fant du det du lette etter?
*