Blinkende innhold
Med blink mener man endringer hvor resultatet motsetter hverandre på en måte som skaper en stor forstyrrelse. For eksempel fargeendring på et større område eller et element som hyppig vises/gjemmes.
Universell utforming handler om at vi skal lage løsninger med tanke på at brukere kan ha ulik funksjonsevne, midlertidig eller varig. Ved å ta hensyn til det, når vi alle målgruppene med én og samme løsning.
For å gjøre prosessen enklere for designere, utviklere og testere har vi laget en guide som lar deg huke av type innhold du har i løsningen din. Deretter gir vi deg relevante krav dere må levere på i WCAG.
Med blink mener man endringer hvor resultatet motsetter hverandre på en måte som skaper en stor forstyrrelse. For eksempel fargeendring på et større område eller et element som hyppig vises/gjemmes.
Gi brukeren et tekstalternativ for innhold som ikke er tekst.
Alt-teksten blir lenketeksten for brukere med skjermleser. Da skal lenkens mål beskrives, ikke motivet på bildet. Evt kan man inkludere begge deler, men lenkens mål skal beskrives først.
Noen steder er det nødvendig med bilde av tekst. For eksempel hvis man viser et kakediagram med statistikk.
Det finnes unntak beskrevet hos difi. Blant disse er det verdt å nevne at skjemaelementer som knapper og inndata-felter gir unntak for regelen, da det er andre kriterier som treffer disse. På slike elementer er det krav til beskrivende tekst og du finner en veiledning til bruk på hver enkelt komponent i Jøkul.
Merk at alt-attributt alltid skal brukes på bilder, men på dekorativt innhold skal den være blank: alt=""
.
Et bilde kan være dekorativt når bildet er
Et visuelt element som brukes til innramming
Illustrerende for nærliggende tekst, men bidrar ikke med tilleggsinformasjon
Beskrevet av nærliggende tekst
Det skal være synlig fokus på elementer. Like viktig er det at fokusrekkefølgen ivaretas. Hvis en dialog er tatt i bruk så er det allerede tatt en beslutning på at innholdet som vises er viktig. Derfor skal dialogen være første element i fokusrekkefølgen etter at den er synlig på skjermen. Se artikkelen om fokushåndtering.
Dersom man tar i bruk dialog i tjenesten sin er det særdeles viktig å passe på at bruker ikke havner i en tastaturfelle. Det skal fortsatt være mulig å bruke tjenesten rundt, både med tastatur og mus.
Dersom dialog brukes i kombinasjon med en tidsbegrensning, se artikkelen om tidsbegrensning.
Innhold skal ikke blinke mer enn tre ganger i løpet av ett sekund. Dette er et spesialtilfelle og hvis blinking oppstår ved bruk av dialog er det som regel som følge av en feil som må rettes.
Farger kan være en god meningsbærer og kan brukes for å gi bedre oversikt for bruker. Samtidig er det viktig at farge aldri brukes som eneste informajsonsbærer.
For ytterligere info om farger, se artikkelen om kontrast.
Fokuserbare elementer skal ha synlig fokus.
Fokuserbare elementer må navigeres i en rekkefølge som gir mening for innholdet. Merk at man må være ekstra oppmerksom i dynamiske menyer og dialoger.
Det skal være forutsigbart å bruke nettsiden. Ved fokus skal det derfor ikke foregå automatiske handlinger som at
Tips: Unngå bruk av tabindex for å overskrive dokumentets naturlige fokusrekkefølge. Hvis semantikken (lenke til global kode?) er på plass så er det sannsynligvis ingen feil her.
Ikoner uten en kontekstuell mening skal hvis mulig ha tom alt-attributt for å bli ignorert av skjermleser. Ikoner som er med å sette en stemning som f.eks. emojis kan leses opp. Ikoner kan være et visuelt virkemiddel i tillegg til farge for å gi et element en feilmelding.
Vi bruker sjelden ikoner i Jøkul, men de ikonene og medfølgende retningslinjer vi har kan du se på infosiden om ikoner i Jøkul.
Brukeren skal ha en mulighet til å enkelt kunne hoppe over innhold som er gjentatt på flere sider, for å kunne komme direkte til hovedinnholdet med tastaturnavigasjon.
En vanlig teknikk er å bruke en skip-link beskrevet hos difi. Den skal være blant de 3 første tab-stegene på siden.
Navigeringsmekanismer som gjentas på flere sider skal oppføre seg likt og se like ut på alle sider med mindre brukeren selv gjør en endring.
Inndatafelter skal være knyttet til en ledetekst både visuelt og i kode. Feks ved bruk av aria-labelledby
.
Ledeteksten eller instruksjonen skal få brukeren til å forstå hvordan feltet skal fylles ut.
Endringer i et inputfelt skal ikke gi kontekstuelle endringer uten forvarsel. Eksempler på store kontekstuelle endringer kan være
Elementer som har samme funksjonalitet på tvers av flere sider skal være utformet likt.
For å gjøre det enkelt, bruk felles komponenter fra Jøkul.
For å sikre god lesbarhet skal all tekst ha tilstrekkelig kontrast mot bakgrunnen.
Våre farger i Jøkul er bestemt med hensyn til kontrastnivået.
Lenker kan brukes inline i tekst eller selvstendig. Lenker skal alltid ha en href
attributt og utheves med visuelle virkemidler.
Om farge brukes som et visuelt virkemiddel, må man bruke et annet virkemiddel i tillegg: Understreking, ikon eller lignende.
I Jøkul skiller vi også mellom interne og eksterne lenker samt navigasjonslenker.
Hvis innholdet som presenteres kun er video eller lyd skal det finnes et alternativ som formidler samme informasjon.
Lister benyttes til å ramse opp informasjon. En liste skal være korrekt kodet, enten det er unummerert, nummerert, definisjonliste eller lister over flere nivå så bruk riktig HTML-elementer.
Et konkret eksempel er en liste som definerer hva en forsikring dekker eller ikke. Der er gjerne kulepunktet byttet ut med et eget symbol. Det er viktig at kulepunktet ikke er eneste måte å skille innholdet på. Dette tilsvarer egentlig to lister hvor den ene har overskriften "Forsikringen dekker" og den andre har overskriften "forsikringen dekker ikke". Det er sterkt anbefalt å bruke slike overskrifter for å gjøre det veldig tydelig at det er en forskjell her. Hvis listen mangler slike overskrifter må det passes på at
Jøkuls lister med ikoner har allerede tatt hensyn til dette slik at de kan brukes uten slike overskrifter.
Modal er krevende å implementere da det påvirkes av mange krav. Hensikten til en modal er å tvinge bruker til å utføre en handling før brukeren kan gå videre.
Det er viktig at elementer utenfor modalen ikke skal få fokus, samt at det er synlig fokus på elementene i modalen. Like viktig er det at fokusrekkefølgen ivaretas. Se Fokushåndtering
Dersom man tar i bruk en modal i tjenesten sin er det særdeles viktig å passe på at bruker ikke havner i en tastaturfelle. Handlinger som skal utføres av bruker i modalboksen må derfor være mulig å navigere til med tastatur i tillegg til mus.
Dersom modalen brukes i kombinasjon med en tidsbegrensning gjelder kravene under Tidsbegrensinng.
Innhold skal ikke blinke mer enn tre ganger i løpet av ett sekund. Dette er et spesialtilfelle og hvis blinking oppstår ved modal er det som regel som følge av en feil som må rettes.
Tips
Overskrifter og korrekt bruk av overskriftsnivåer er en av de enkleste måtene å sikre oversiktlighet og korrekt flyt i tjenesten. Alle brukere benytter overskrifter og mellomtitler for å skumlese innhold uavhengig av om de bruker hjelpemidler.
Feilmeldinger i skjema skal identifisere feltet med feil, beskrive feilen og være synlig uten at brukeren må gjøre ekstra handlinger. Feilmeldingen skal være mulig å oppfatte uavhengig av fargesyn:
Feilmeldingen skal være tekstlig og så spesifikk som mulig: "Dette feltet er obligatorisk" er ikke lov. Skriv heller "Du må fylle inn et navn".
Så langt det er mulig skal feilmeldingen inneholde et forslag til hvordan brukeren kan løse det.
Endring av verdien i et skjemalement skal ikke resultere i at det automatisk blir betydelige endringer på siden. Bruker må bli varslet om kontekstendringer på forhånd. Et eksempel på korrekt bruk er at bruker aktivt må trykke "Send inn", "Gå videre" eller lignende før man blir servert nytt innhold.
For feil som oppdages automatisk:
For sider med juridiske forpliktelser må det være mulig å kunne angre, kontrollere eller bekrefte dataene som sendes inn. Et av følgende punkter gjelder
Sørg for at ledetekster og overskrifter beskriver emne eller formål. Mer info om ledetekster ved inndatafelter finnes i artikkelen om inndatafelter.
Alle skjemaelementer må være mulig å bruke med kun tastaturnavigasjon. Det er viktig at ingen elementer fungerer som en tastaturfelle – se artikkelen om tastaturfeller.
En endring i fokus må aldri automatisk medføre en betydelig endring. Bruker må gjøres oppmerksom på slike handlinger på forhånd.
Formålet med en lenke skal kunne fastslås fra selve lenketeksten eller lenketeksten kombinert med programmeringsmessig bestemt lenkekonstekt.
I Norge er loven slik at alle tjenester skal treffe WCAG AA-kravene. For vanskelige ord, forkortelser, fagspråk og idiomer gjelder WCAG AAA. Dette er derfor ikke et lovpålagt krav, men i Fremtind har vi bestemt oss for at vi skal være mestere i klarspråk.
Så langt det lar seg gjøre skal man derfor unngå overkomplisert språk, men dersom det ikke er mulig å komme rundt dette må det eksistere mekanismer som:
Retningslinjer for språk og skriveråd finner du på Jøkuls profilside for "Stemmen vår".
All funksjonalitet skal være mulig å bruke med et tastatur. Dette er noe som treffer superbrukere og brukere med nedsatt motorikk I armer og hender, både varig og midlertidig. Samtidig vil dette sikre at bruken av skjermleser blir enklere.
Innholdet skal være presentert på en måte som gjør at sekvensiell navigering med tastatur føles logisk og intuitiv.
Hvis bruker kommer til et sted på siden hvor tastaturnavigasjon hverken kan ta deg videre eller tilbake så har brukeren havnet i en tastaturfelle. Dette kan typisk oppstå som følge av modal/dialog som er feil implementert.
Det er viktig at tjenesten i sin helhet blir testet med kun tastaturnavigasjon.
Tabeller skal utelukkende brukes til å presentere data, ikke for å styre layout/utseende.
I tillegg til overskrift for tabellen i sin helhet er det viktig at elementet <th>
er tatt i bruk på celleoverskrifter (overskriften på rader/kolonner). Dette er nødvendig for at skjermlesere skal gi fullverdig informasjon i hver enkelt celle. Dersom det er overskrifter på både kolonner og rader må du spesifiere hvilken retning de peker med attributen scope="col"
eller scope="row"
.
En kompleks tabell er en tabell som har flere nivåer med celleoverskrifter. Dette er et spesielt tilfelle som kan dypdykkes i på difi sin oversikt over komplekse tabeller
Sørg for at tekstblokker enkelt kan leses av alle brukere.
Størrelse på tekst skal kunne bli endret opp til 200% uten tap av innhold eller funksjon. Det samme gjelder for å zoome inn 200% på nettsiden. Tekst skal ikke kuttes, bli vanskeligere å lese eller forsvinne selv om brukeren har justert tekststørrelsen.
Dersom tjenesten inkluderer en tidsbegrensning gjelder minst et av følgende
Brukeren kan slå av tidsbegrensningen
Brukeren kan øke tidsbegrensningen med minst 10 ganger standardverdi
Brukeren varsles før tiden går ut og skal få minst 20 sekunder til å forlenge* den minst 10 ganger. Feks "Trykk på mellomromstasten"
Tidsbegr. er en nødvendig del og det finnes ikke noe alternativ (feks auksjon)
Tidsbegr. varer lenger enn 20 timer