1. Følg med
  2. Blogg
  3. 2014
  • Publisert
  • 11 min

Sjekklista du må oppfylle for å lage lovlege nettsider

Frå 1.juli 2014 kan du få bot om nettsida di er ulovleg. Me har derfor oppdatert våre sjekklister til å omfatte WCAG 2.0 AA

Av Aud Marie Hauge

I Epinova har me hatt Quality Assurance (QA) på våre løysingar i nokre år, førre versjon av QA er omtalt på bloggen vår: Sjekklista du treng for å sikre kvalitet på din nettstad

Me utfører QA på alle våre prosjekt for å minimere sjansen for å lansere løysingar som inneheld feil, kontrollere at me ivaretek kvalitet, og for å heile tida sikre at me oppdaterer oss fagleg i takt med utviklinga. Ein utvikler utfører aldri QA på sin eigen kode, og me opplever stort læringsutbytte ved å kvalitetssjekke andre sin kode.

Omlag ein gong i året reviderer me vår sjekkliste. QA består no av ei sjekkliste på 93 retningslinjer. 

Denne gongen har me gjort store endringer: me har teke inn meir på søkemotoroptimalisering, ytelse og universell utforming. 

Ulovlege nettsider

Frå 1.juli 2014 kan eigere av nettsider få bøter dersom nettsidene ikkje oppfyller WCAG 2.0 AA. Me har derfor valt å ta desse retningslinjene inn i vår QA.

Diverre kan retningslinjene til WCAG vera litt vanskelege å forstå, og mange av retningslinjene er litt vage. Det kan derfor vera ei utfordring å vite når du har oppfylt ei retningslinje eller ikkje. 

Me har derfor gjort eit arbeide med å tolke retningsllinjene, og gjort dei meir forståeleg. Me har tolka retningslinjene i forhold til informasjonsnettsider som me plar lage, det kan vera at ein bør tilpasse forklaringen på retningslinjene dersom ein lager andre type nettsider.

Ved å ta desse retningslinjene inn i vår QA, kan me også vise til Difi, kunde, samarbeidspartnere og andre, kva retningslinjer som er oppfylt og kva retningslinje som eventuelt ikkje er oppfylt. Me har også skilt mellom kva retningslinje frontender er ansvarleg for å oppfylle, og kva som er opp til designer, kunde og interaksjonsdesigner å oppfylle.

I kapittel 9 om WCAG kan ein sjå korleis me tolker kvar av retningslinjene til WCAG.

 

1 Prosjekt

  1. QA skal gjøres før lansering
  2. Kravliste er oversendt designer/interaksjonsdesigner
  3. Prosjekter er tilstrekkelig dokumentert i wiki, både funksjonelt og visuelt

 

2 Grafisk leveranse

  1. Leveranse inneholder styleguide
  2. Leveransen viser eksempel på alle unike sidemaler
  3. Grafisk leveranse inneholder kildedokumenter, fortrinnsvis Photoshop-filer eller HTML/CSS
  4. Vektorformat for all grafikk er en del av grafisk leveranse
  5. Leveransen viser design/dokumentasjon på redaktørvisningInformasjonsarkitektur viser innholdstyper, sidemaler og relasjonerGrafisk leveranse viser print-stiler

 

3 Prosjektløsning

  1. Favicon og touch-icon er satt opp
  2. Print-stilark er satt opp med alle sidetyper
  3. Nettstedet er kompatibelt iht. prosjektets nettleserkrav
  4. Det er laget en styleguide i HTML
  5. Filer inkludert i løsningen er i bruk
  6. Løsningen kan navigeres og leses selv om man skrur av bilder
  7. Hovedfunksjonaliteten i løsningen fungerer uten Javascript
  8. Ressurstekster lagt inn av utvikler er uten iøynefallende skrivefeil

 

4 Redaktørgrensesnitt

  1. Visningsmodus og redigeringsmodus er så like som mulig
  2. Det er lagt til thumbnails til sidetyper og blokktyper og sidetyper er gruppert ved bruk av GroupName (CMS 7)
  3. Webdelsoner har overskrifter (CMS 6)
  4. Webdelsoner er satt opp likt i visningsmodus og redigeringsmodus (CMS 6)


5 HTML

  1. Alle sider på nettstedet validerer
  2. Document outline er semantisk korrekt
  3. Elementer er brukt korrekt (lister, avsnitt, adresse, table o.l.)
  4. Tabeller er ikke brukt til layout
  5. <header>, <main>, <footer> er brukt korrekt
  6. <article>, <section>, <aside>, <nav> er brukt korrekt
  7. inputtype er korrekt til oppgaven den skal løse og er brukervennlig
  8. input types er optimalisert mht. mobil
  9. <fieldset>, <legend>, og <label> er brukt korrekt
  10. meta viewport er satt opp riktig i løsningen
  11. alt/title er brukt riktig på bilder
  12. WAI-ARIA-attributter er brukt der det er hensiktsmessig
  13. ID-er og klasser har meningsfulle/semantiske navn
  14. Lenker er <a>, knapper er <button>

 

6 CSS

  1. CSS validerer (unntak for legacy)
  2. Unngå bruk av inline CSS
  3. Begrens bruk av ID-selektor
  4. Begrens bruk av * selektor
  5. Unngå utstrakt bruk av element selektor, og at CSS er minst mulig avhengig av HTML-rekkefølge
  6. Unngå bruk av !important
  7. Begrens bruk av px til størrelser
  8. Bruk CSS3 fallback-egenskaper
  9. CSS inneholder ikke duplikate regler eller ubrukte selektorer
  10. CSS er ikke minimalisert i kildefiler

 

7 SEO (gjelder ikke intranett)

  1. Open Graph meta tagger er satt opp riktig
  2. Twitter Cards er konfigurert
  3. Begrens antall lenker per side til 100-150
  4. rel=prev/next brukt til paginering
  5. Referanser til alternativt språk
  6. schema.org brukt der det er hensiktsmessig


8 Ytelse

  1. PageSpeed score > 80
  2. UI-bilder er optimalisert
  3. Innholdsbilder i løsningen har fornuftig størrelse
  4. Data URI til bilder er brukt der det er hensiktsmessig
  5. Bilde-sprites er optimalisert 
  6. CSS er brukt isteden for bilder der det er mulig

 

9 WCAG 2.0 AA (Epinova sin tilnærming)

Ressurser: http://uu.difi.no/krav-og-regelverk/losningsforslag-web

  1. Ikke-tekstlig innhold:
    Alt ikke-tekstlig innhold som presenteres for brukeren, har et tekstalternativ som har samme formål, med unntak av noen få situasjoner.  (1.1.1)
    - Oppfylles dersom 5.11 er oppfylt.
     
  2. Bare lyd og bare video:
    For forhåndsinnspilt innhold som bare er lyd eller video gis det tilgang til alternativer, bortsett fra når lyden eller videoen utgjør et mediealternativ til tekst og er tydelig merket som det.  (1.2.1)
    - Redaktøransvar/kundens ansvar. Det kan være krevende å transkribere lyd og video. Det viktigste er at budskapet i video/audio også er tekstlig beskrevet, dette har også verdi for søkemotorer. Man bør ikke fjerne video/audio fra et nettsted selv om man ikke har mulighet til transkripsjon. 
     
  3. Teksting:
    Det gis tilgang til teksting for alt forhåndsinnspilt lydinnhold i synkroniserte medier, bortsett fra når mediene fungerer som mediealternativer til tekst og er tydelig merket som det. (1.2.2)
    - Redaktøransvar/ kundens ansvar. Det kan være krevende å transkribere lyd og video. Det viktigste er at budskapet i video/audio også er tekstlig beskrevet, dette har også verdi for søkemotorer. Man bør ikke fjerne video/audio fra et nettsted selv om man ikke har mulighet til transkripsjon. 
     
  4. Informasjon og relasjoner: Informasjon, struktur og relasjoner som formidles via presentasjonen, kan bestemmes programmeringsmessig eller gjøres tilgjengelig(e) som tekst. (1.3.1)
    - Her kan WAI-ARIA brukes til å definere roller, landmarks. I denne omgang tolker vi denne retningslinjen som at oppfylles dersom punkt 5.2-5.9 er oppfylt.
     
  5. Meningsfylt rekkefølge:
    Når rekkefølgen som innholdet presenteres i, påvirker meningsinnholdet, kan en korrekt leserekkefølge bestemmes programmeringsmessig (1.3.2)
    - Løses dersom punkt 5.2 er oppfylt.
     
  6. Sensoriske egenskaper:
    Instruksjoner som gjelder for forståelse og betjening av innhold, er ikke utelukkende avhengige av komponentenes sensoriske egenskaper, for eksempel form, størrelse, visuell plassering, orientering eller lyd. (1.3.3)
    - Unngå tekster som viser til elementer andre plasser på siten. Eksempler: Klikk på knappen neders til høyre, klikk på lenke i høyrekolonne etc. Redaktøransvar.
     
  7. Bruk av farge:
    Farge blir ikke benyttet som det eneste visuelle virkemiddelet for å formidle informasjon, angi en handling, be om respons eller skille ut et visuelt element. (1.4.1)
    - Lenker skal være markerte med andre effekter enn farger. Understreking er anbefalt de facto standard. 
     
  8. Styring av lyd:
    Hvis lyd på en webside spilles av automatisk i mer enn 3 sekunder, finnes det enten en mekanisme for å stoppe lyden helt eller midlertidig, eller en mekanisme som kan regulere lydstyrken uavhengig av det generelle systemvolumet. (1.4.2)
    - Kontrollsjekk at videoplayer som blir brukt i prosjekt kan regulere lydstyrke, samt skru helt av lyd.
     
  9. Kontrast:
    Den visuelle presentasjonen av tekst og bilder av tekst har et kontrastforhold på minst 4.5:1, unntatt i noen få tilfeller. (1.4.3)
    - Verktøy for å teste kontrast: http://www.paciellogroup.com/resources/contrastAnalyser 

  10. Endring av tekststørrelse:
    Med unntak av teksting og bilder av tekst kan tekst forstørres opp til 200 % uten bruk av kompenserende teknologi og uten at innhold eller funksjonalitet går tapt (1.4.4)
    - Anbefalt måte dette løses på er å definere breakpoints i em.
     
  11. Bilder av tekst:
    Hvis teknologien som brukes kan håndtere den visuelle presentasjonen, brukes det tekst i stedet for bilder av tekst til å formidle informasjon, unntatt i 2 tilfeller (1.4.5)
    - Ikke bruk tekst i bilde, både frontend og redaktøransvar.
     
  12. Tastatur:
    All funksjonalitet i innholdet kan betjenes via et tastaturgrensesnitt uten at det er behov for tidsberegning av de enkelte tastetrykkene, unntatt hvis den underliggende funksjonen krever inndata som er avhengige av rekkefølgen på brukerens bevegelser, og ikke bare av sluttpunktene.  (2.1.1)
    - Løsningen fungerer å navigere med tastatur (med :focus)
     
  13. Ingen tastaturfelle:
    Hvis tastaturfokus kan flyttes til en av komponentene på siden ved hjelp av et tastaturgrensesnitt, kan fokus flyttes fra den aktuelle komponenten bare ved hjelp av tastaturgrensesnittet. Hvis det er behov for noe annet enn standard pil- eller tabulatortaster eller andre standardmetoder for navigering, får brukeren informasjon om hvilken metode som må benyttes for å flytte fokus. (2.1.2)
    - Løsningen fungerer å navigere med tastatur (med :focus). Dersom tastaturfeller oppstår kan tab-index løse floken.
     
  14. Justerbar hastighet:
    For hver tidsbegrensning som er angitt av innholdet, gjelder minst ett av følgende punkter: Man kan slå av, justere eller forlenge begrensningen, eller begrensningen er en nødvendig del i sanntid, en forlengelse skulle gjøre handlingen ugyldig eller tidsbegrensingen varer lenger enn 20 timer. (2.2.1)
    - Skjelden case for oss, gjelder spesielt dersom utfylling av skjema har tidsbegrensning. det må da være mulig å påvirke denne, da personer med nedsatt funksjonsevne kan trenge mer tid til utfylling. 
     
  15. Pause, stopp, skjul:
    For bevegelse, blinking, rulling eller automatisk oppdatering av informasjon finnes det en mekanisme som brukeren kan benytte til å sette den på pause, stoppe eller skjule den.  (2.2.2)
    - Kontrollsjekk at videoplayer har mulighet for pause, stopp. Elles pleier vi ikke lage ting som beveger seg automatisk på nettstedet. 
     
  16. Terskelverdi på maksimalt tre glimt:
    Websider har ikke innhold som glimter mer enn tre ganger i løpet av ett sekund, eller glimt er innenfor terskelverdiene for generelle glimt og røde glimt. (2.3.1)
    - Ikkje så relevant lenger, med unntak av video. Elles redaktøransvar.
     
  17. Hoppe over blokker:
    Det finnes en mekanisme for å omgå blokker med innhold som gjentas på flere websider. (2.4.1)
    - Skjulte snarveilenker fungerer med bruk av tabulatornavigasjon (synlig ved :focus) Disse peker på innholds-container og ikke tomme lenker
     
  18. Sidetitler:
    Websider har titler som beskriver den aktuelle sidens emne eller formål.  (2.4.2)
    - Redaktøransvar, EPiServer legger tilrette for å legge inn title.
     
  19. Fokusrekkefølge:
    Hvis en webside kan navigeres sekvensielt og navigeringssekvensen påvirker betydning eller betjening, får fokuserbare komponenter fokus i en rekkefølge som ivaretar betydningen og betjeningen. (2.4.3) 
    - Oppfylt dersom punt 5.2 er oppfylt.
     
  20. Formål med lenke (i kontekst):
    Formålet med hver lenke kan fastslås ut fra bare selve lenken eller ut fra lenketeksten kombinert med programmeringsmessig bestemt lenkekontekst. Unntaket er hvis formålet med lenken ville vært flertydig for alle brukere. (2.4.4)
    - Radaktøransvar å gi lenker meningsfult innhold.
     
  21. Det finnes flere måter å finne frem:
    Det finnes mer enn én måte å finne frem til en webside på innenfor et sett av websider. (2.4.5)
    - Oppfylles dersom man har søk og menyer. Ekstra forsikring for dette punktet er å presentere en sitemap eller table of content.
     
  22. Overskrifter og ledetekster:
    Overskrifter og ledetekster beskriver emne eller formål. (2.4.6)
    - Redaktøransvar, med unntak av tekster vi legger inn i språkfiler.
     
  23. Synlig fokus:
    Tastaturbetjente brukergrensesnitt har en betjeningsmodus der fokusindikatoren for tastaturet er synlig (2.4.7) 
    - Løsningen har :focus stiler, eller nytter standard nettleser stiler for :focus. Husk at <input type="text" /> i FF ikke har focusstil.
     
  24. Språk på siden:
    Standard naturlig språk på hver webside kan bestemmes programmeringsmessig. (3.1.1)
    - Det finnes lang-attributt på HTML-elementet for aktivt språk. 
     
  25. Språk på deler av innhold:
    Naturlig språk i de enkelte avsnittene eller setningene som innholdet består av, kan bestemmes programmeringsmessig. Unntaket er egennavn, tekniske termer, ord av ubestemmelig språklig opphav samt ord eller uttrykk som har blitt en del av språket i den omkringliggende teksten. (3.1.2) 
    - Det finnes lang-attributt på HTML-elementet for aktivt språk. Dette er ikke mulig i EPiServer i dag. Bør løses.
     
  26. Fokus: Når en komponent kommer i fokus, medfører det ikke kontekstendring. (3.2.1)
    - Kanskje ikke så relevant, men bør kontrollsjekkes.
     
  27. Inndata:
    Endring av innstillingene til en brukergrensesnittkomponent medfører ikke automatisk kontekstendring med mindre brukeren er blitt varslet om det før bruk av komponenten. (3.2.2)
    - Gjelder spesielt js.
     
  28. Konsekvent navigering:
    Navigeringsmekanismer som gjentas på flere websider innenfor et sett av websider, opptrer i samme relative rekkefølge hver gang de gjentas, med mindre brukeren selv foretar en endring. (3.2.3)
    - Globale menyer er konsistente og endrer ikke rekkefølge på presentasjon. Løsningen skal gå an å navigere og lese selv om man skrur av bilder i nettleseren
     
  29. Konsekvent identifikasjon:
    Komponenter som har samme funksjonalitet innenfor en samling av websider, identifiseres på en konsekvent måte (3.2.4)
    - Oppfylles av punkt 5.2-5.9 er oppfylt.
     
  30. Identifikasjon av feil:
    Hvis en inndatafeil oppdages automatisk, identifiseres elementet som feilen berører, og brukeren får en tekstbeskrivelse av feilen (3.3.1) 
    - Skjema: presentasjon av feilmeldinger og forslag til hvordan feilen kan rettes opp er gjort i kontekst. Unntak kan være xForm. 
     
  31. Ledetekster eller instruksjoner:
    Det vises ledetekster eller instruksjoner når innholdet krever inndata fra brukeren (3.3.2)
    - Løses i punkt 5.9
     
  32. Forslag ved feil:
    Hvis en inndatafeil oppdages automatisk og det finnes forslag til hvordan den kan rettes, presenteres forslagene for brukeren, med mindre dette innebærer risiko for sikkerheten eller formålet med innholdet (3.3.3) 
    - Skjema: presentasjon av feilmeldinger og forslag til hvordan feilen kan rettes opp er gjort i kontekst. Unntak kan være xForm. Tips til løsning finnes på "kodebasen".
     
  33. Forhindring av feil (juridiske feil, økonomiske feil, datafeil):
    For websider som medfører juridiske forpliktelser eller krever økonomiske transaksjoner fra brukeren, som endrer eller sletter brukerstyrte data i datalagringssystemer, eller som sender svar på tester utført av brukeren, gjelder minst ett av følgende punkter: Reverserbarhet, kontroll, bekreftelse (3.3.4) 
    - Interaksjonsdesigner og kunde ansvar. xForm tilbyr bekreftelsesside.
     
  34. Parsing (oppdeling):
    I innhold som implementeres ved hjelp av oppmerkingsspråk, har elementene fullstendige start- og sluttkoder, elementene er nøstet i henhold til spesifikasjonene, elementene inneholder ikke dupliserte attributter, og eventuelle ID-er er unike. Unntaket er hvis spesifikasjonene tillater disse funksjonene (4.1.1) 
    - Oppfylles av punkt 5.1 -5.9
     
  35. Navn, rolle, verdi:
    For alle brukergrensesnittkomponenter (blant annet skjemaelementer, lenker og komponenter som genereres ved hjelp av skript), kan navn og rolle bestemmes programmeringsmessig. Tilstander, egenskaper og verdier som kan angis av brukeren, kan angis programmeringsmessig, og informasjon om endringer i disse elementene er tilgjengelig for brukeragenter, inkludert kompenserende teknologi (4.1.2)
    - Oppfylles av punkt 5.1 -5.9

 

Kommentarer

Kom gjerne med kommentarer på sjekklista, eller kanskje ha du laga di eiga sjekkliste med litt andre vinklinger?

 

Relevante lenkjer