Hvordan fĂžlge WCAG

Hvordan

UU-tilsynet gjennomfÞrer tilsyn og det kan ende i dagbÞter sÄ hÞye som 150 000 kroner for brudd pÄ regelverket. Derfor er det viktig Ä ha en metodisk tilnÊrming til universell utforming helt fra start. Har man en strategi for hvordan unngÄ brudd pÄ WCAG fra start vil ikke jobben etter et tilsyn eller en klage fra bruker bli sÄ stor.

UU-tilsynet deler tilsynsrapportene om man er nysgjerrig pÄ hvordan dette foregÄr, se UU-tilsynets sider

Alle som jobber med Ä utvikle digitale lÞsninger har et ansvar for at lÞsningen er tilgjengelig for alle. En produkteier eller teamlead sÞrger for at det er fokus pÄ og tid til universell utforming. Innholdsdesigneren, designere og utviklere passer pÄ at lÞsningen er mulig Ä oppfatte, mulig Ä betjene, forstÄelig og robust. Test jevnlig, bÄde med verktÞy og brukere.

Husk at et Punkt lÞser ikke alt. Det er fortsatt viktig Ä teste komponenter i en helhet. Og ingen er feilfrie, alle har UU-feil, men det blir enklere Ä rette opp i feilene nÄr vi har dette som en rutine.

SÄ hva skal vi passe pÄ for at lÞsningen fÞlger WCAG 2.1? Kort fortalt.

Mulig Ă„ oppfatte

Vi mÄ sÞrge for at alle oppfatter innholdet vi presenterer i lÞsningen.

Bilde, animasjon, lyd og video

  • Ikke-tekstlig innhold, som for eksempel video, lyd og bilde mĂ„ ha et tekstalternativ som samsvarer med det vi skal formidle slik at informasjon er tilgjengelig for en skjermleser. Det er ikke nĂždvendig med tekstalternativ pĂ„ dekorativt innhold.
  • UnngĂ„ bilder som tekst. Alt-tekst hjelper ikke de som trenger stĂžrre skrift, konverteringer eller oversettelser. Hva om bruker trenger Ă„ kopiere teksten?
  • Kan brukeren kjapt og enkelt stoppe, pause eller skjule animasjoner, video og lyd? Dette mĂ„ ogsĂ„ vĂŠre like kjapt og enkelt med tastatur.
  • UnngĂ„ Ă„ starte lyd og video automatisk, la brukeren bestemme.
  • Brukeren skal kunne slĂ„ av animasjoner selv. Brukere kan slĂ„ av animasjoner i sitt operativsystem, men ikke anta at brukeren vet at denne muligheten finnes.

Designere

  • Innhold skal ikke blinke mer enn tre ganger per sekund for Ă„ unngĂ„ anfall og svimmelhet. Dette kan vĂŠre veldig alvorlig for brukeren og derfor skal dette ikke skje.

Utviklere

  • Skriv korte og konkrete alternative tekster. Beskriv hva du formidler i bildet, ikke motivet i seg selv.
  • alt-attributtet skal alltid vĂŠre med. Men om bildet ikke skal leses opp av skjermleser la alt vĂŠre tom. Om alt ikke er i img-taggen vil innholdet i src leses opp, noe som er veldig forstyrrende.
<img alt="" class="dekor" src="bildeavdekoren-2-copy.jpg" />

Semantikk, tekst og struktur

For at brukeren skal kunne oppfatte og forstÄ innholdet i lÞsningen er det viktig Ä ha et forhold til logisk navngiving og struktur.

  • Har vi god tekststruktur pĂ„ siden?
  • Blir lĂžsningen presentert i en logisk rekkefĂžlge? Blir titler og tekst presentert i riktig rekkefĂžlge?
  • Kan innholdet vises i liggende og stĂ„ende retning?
  • Er strukturen slik vi Ăžnsker?
  • Bruk tabeller nĂ„r informasjonen krever en tabell, ikke for visuell effekt.
  • Tekst skal kunne bli endret til 400% stĂžrrelse ved 1280 piksler bredde uten tap av innhold eller funksjon. Dette kan du teste manuelt ved Ă„ zoome nettleseren og se om du fĂ„r med deg innholdet pĂ„ tiltenkt mĂ„te.

Designer

  • Lenkede bilder og tekst bĂžr vĂŠre visuelt synlig klikkbare

Utvikler

  • Bruk semantisk HTML
  • Bruk logisk HTML-struktur, for eksempel rekkefĂžlgen pĂ„ header-tagger skal vĂŠre i riktig rekkefĂžlger
  • Bruk WAI-ARIA med logiske navn og roller hvis HTML-semtantikken ikke strekker til, men vĂŠr forsiktig med bruken av ARIA, vit hva den gjĂžr.
  • UnngĂ„ Ă„ bruke HTML-elementer for visuelle endringer, dette skal CSS brukes til. For eksempel ikke bruk <br> for Ă„ lage avsnitt.
  • Husk at skjermleser er avhengig av at sprĂ„k er satt riktig i HTML. <html lang="nb">

Les mer:

Farger og kontrast

  • Ikke illustrer et budskap som bygger utelukkende pĂ„ farge. I tillegg til farge, bruk ikoner og tekstalternativer.
  • Bruker vi hĂžy nok kontrastverdi? Kontrastverdien for tekst og bakgrunn skal vĂŠre 4.5:1
  • Fokusmarkering ved tastaturnavigering skal vĂŠre tydelig i alle nettlerere.

Les mer:

Tilbakemeldinger og skjema

  • SĂžrg for at alle kan fullfĂžre et skjema.
  • Er det gode veiledningstekster?
  • Er det tydelige og tilgjengelige feilmeldinger?
  • Er feilmeldinger forstĂ„elige slik at brukeren vet hvordan feil kan lĂžses?
  • Er obligatoriske felt i et skjema merket?
  • FĂ„r alle med seg statusbeskjeder?

Les mer:

Mulig Ă„ betjene

Alle skal kunne betjene lÞsningen vÄr. GjÞr det mulig for brukerne Ä navigere, finne innhold og vite hvor de befinner seg.

LĂžsningen skal kunne navigeres med tastatur.

  • Er alle interaktive elementer tilgjengelig og i synlig fokus?
  • Er det noen steder brukeren blir stĂ„ende fast i et element? Eller elementer som aldri er tilgjengelig for tastatur eller skjermleser?
  • Tenk brukeropplevelse, for eksempel lag snarveier i navigeringen om det blir for lang vei til hovedinnhold
  • Er det minst to metoder for Ă„ finne innhold pĂ„ nettstedet vĂ„rt? Som for eksempel meny og sĂžk? Og er det enkelt Ă„ finne og gjennomfĂžre et sĂžk og navigere seg rundt?
  • Popup-komponenter, alerts eller informasjon som dukker opp underveis i brukerreisen skal ha direkte fokus slik at alle fĂ„r den med seg. Popup’er skal ogsĂ„ ha godt synlig kryss for Ă„ kunne fjerne den.
  • SĂžrg for at brukeren fĂ„r med seg innholdet i en toast som bare er tilgjengelig i kort periode.
  • Gir vi brukeren nok tid til Ă„ oppfatte og betjene lĂžsningen?

For Ä teste ut om lÞsningen er mulig Ä betjene ved hjelp av tastatur mÄ dette testes manuelt. Dette kan du gjÞre slik:

  • Tab er fremover
  • Tab + shift er bakover
  • Space for Ă„ ta et valg
  • Enter for Ă„ aktivere funksjon
  • Bruk piltaster for Ă„ navigere

Designer

  • Alle lenkers mĂ„l og funksjon skal fremgĂ„ tydelig av lenketeksten.
  • Lenker skal ha synlig fokus ved tastatunavigasjon. Alle elementer som er tilgjenglig med tastaturnavigasjon, skal lenkene fĂ„ fokus nĂ„r de er aktive.

Utvikler

  • SĂžrg for at scrollable komponenter er tilgjengelig for tastaturnavigering med tabindex
  • SĂžrg for at rekkefĂžlgen ved tastaturnavigering er riktig. Siden tastaturnavigeringen fĂžlger kodestruktur kan det noen ganger bli feil, gjĂžr kildekoden bedre eller bruk tabindex(hvis du mĂ„) for Ă„ overstyre rekkefĂžlge.

Les mer


<div style="overflow-y: auto" tabindex="0">
  <div style="height: 2000px">
    <p>Innhold</p>
  </div>
</div>

ForstÄelig

Brukeren skal kunne forstÄ hvordan lÞsningen skal brukes og forstÄ den informasjonen vi formidler.

Forutsigbar og leselig

  • Er lĂžsningen vĂ„r forutsigbar og helhetlig? Det kan bety at innhold ikke endrer seg drastisk om bruker har endret verdi i for eksempel et skjema.
  • SĂžrg for Ă„ hjelpe bruker til Ă„ rette opp feil.
  • For sider som medfĂžrer juridiske forpliktelser mĂ„ det vĂŠre mulig Ă„ kunne angre, kontrollere eller bekrefte dataene som sendes inn.

Designer

  • Er funksjonalitet pĂ„ tvers av hele lĂžsningen utformet likt?

Utvikler

  • SĂžrg for at sprĂ„ket til innholdet pĂ„ alle websider er angitt i koden og at alle deler av innholdet som er pĂ„ et annet sprĂ„k enn resten av siden er markert i koden.

Les mer:

<html lang="nb">
  <p>Dette er norsk tekst <span lang=”en”>This is english.</span> Her er det norsk igjen.</p>
  </html>

Robust

LÞsningn mÄ vÊre robust og kompatibel. Alle sider skal vÊre uten store kodefeil. Komponenter har navn og roller satt i koden.

  • SĂžrg for Ă„ bruke verktĂžy som analyserer koden for syntaksfeil eller kjĂžr koden gjennom en kodevalidator.

Les mer: