W3C SVG

Bufdir Fosterhjem - Useit analyse av universell utforming

03.12.2021

  • [ny.bufdir.no/fosterhjem](https://ny.bufdir.no/fosterhjem/)

  • Windows 10
  • Firefox with NVDA 2020.1
  • Lenovo nettbrett med Talkback.
  • iPhone 8 with iOS 12.1
  • VoiceOver for iOS og Mac

Sammendrag

Useit har gjennomført en analyse av utvalgte sider på Bufdir sitt nettsted etter avtale for å undersøke hvor godt grensesnittet oppfyller lovkravene i WCAG 2.1 AA.

Grensesnittet fungerer bra i mange aspekter, men har noen problemer som påvirker flere brukergrupper. Det er få kritiske problemer hvor brukeren blir fullstendig eksludert fra å ta del av grensenittet. Det er imidlertid et flertall problemer som har høy prioritet og som påvirker brukere i den grad at det vil bli ekstra krevende å bruke nettstedet optimalt.

Dette gjelder spesielt brukere som er avhengig av tastatur og navigere, for svaksynte brukere, for døve eller de med nedsatt hørsel og for brukere som ikke kan se og er avhengig av hjelpemidler.

Når det gjelder tastaturnavigering bør dere prioritere at:

  • Navigering ikke sker i bakgrunn av modaler/overlays.
  • Fokus blir satt riktig etter utført handling, som for eksempel ved “Til topp” knapp.
  • Visuell fokus er synlig hele tiden.

For svaksynte brukere er det store problemer fremforalt ved bruk av menyen ved innzoomet grensesnitt. Per nå vises ikke alle kategorier i menyen og det er umulig å skrolle seg nedover i listen. Samme problem gjelder i mobilt grensesnitt. Bortsett fra menyen fungerer ellers zoom bra, tekst går an å forstørre uten problemer og brukeren kan stille inn avstand i tekst uten at det påvirker innholdet negativt.

For brukere som er avhengig av skjermleser for å ta del av og navigere seg på nettstedet, kan det bli utfordringer i å forstå den visuelle strukturen og forholdet mellom ulike elementer. Dette gjelder fremforalt inndatafelt hvor ledetekst ikke er koblet, feilmeldinger som ikke gjengis og til landemerker som ikke er oppmerket.

En skjermleser er et hjelpemiddel som fremst brukes av brukere med nedsatt syn. Den kan også brukes som et hjelpemiddel for personer med kognitive nedsettelser, som for eksempel de med lesevansker. En skjermleser konverterer alt som finnes på skjermen i form av tale eller punktskrift. For en person som ikke kan se, stoler de helt på det som leses opp av skjermleseren. Hvis ting ikke er kodet for å være tilgjengelig og tolket riktig for skjermlesere, vil dette skape enorme barrierer for denne brukergruppen.

For att nettstedet skal fungere optimalt for denne brukergruppen må dere hovedsakelig prioritere:

  • Bruken av WAI-ARIA

    • Forsikre at statusmeldinger gjengis til skjermleser.
    • At det er en programmatisk relasjon mellom elementer, slik som lenkelister, inndatafelt, feilmedlinger og tabeller.
    • At skjermleser ikke når innholdet bak modalvinduer.
    • Bedre tekstbeskrivelser på elementer.
    • Forbedring av struktur med landemerker.

  • Fokushåndtering

    • At fokus blir satt riktig etter handling, slik som med “Til topp” knappen.

  • Hovedmenyen.

    • Hovedmenyen er noe som ofte er vel brukt på nettsider og bør derfor ha høy prioritet. For øyeblikket påvirker de største problemene i menyen alle mobilbrukere, brukere som er avhengig av tastatur for å navigere og brukere med skjermleser.

Generelt må dere også prioritere at:

  • Interaktive elementer har tillstrekkelig klikkeområde

  • Videoer har en beskrivende tittel

    • At de er tekstet
    • Synstolking finnes

Bortsett fra ovennevnte fungerer grensesnittet godt i forhold til responsivitet av innhold og tekst og koden genererer ingen kritiske feil i henhold til HTML5 standarden. Det er en gjennomgående god overskriftstruktur som også gjengis riktig programmatisk i koden og hver side har en unik tittel som gjør at brukeren kan skille innholdet mellom de ulike sidene. Oppsummert har grensesnittet et godt fundament og vi bedømmer at det ikke vil være store utfordringer i å gjøre det universellt utformet og i henhold til lovkravene.

Resultat

Videoer mangler synstolking

Problembeskrivelse

I følge WCAG 1.2.5 skal videoer være synstolket. I Norge i dag er dette ikke et lovpålagt krav men det vil tre i kraft i forbindelse med innføringen av Webtilgjengelighetsdirektivet (WAD). Synstolking betyr at man gir en beskrivelse i lyd på det som visuelt vises i innholdet i videoen og som er viktig for forståelsen.

UU-tilsynet beskriver begrepet som:

“formidling av visuelt innhold i en video, som ikke allerede blir presentert som lyd.”

og mener at:

“Om all informasjon i videoen allerede er med som lyd, er det ikke nødvendig med synstolkning.”

Synstolking av video skal presenteres som et separat lydspor som spilles av sammen med lyden fra videoen.

Kravet er også godkjent dersom det gis en tekstlig beskrivelse av alt innhold i videoen, slik som et transkript.

I deres videoer blir det for eksempel presentert en tekst på slutten av hver video. Den teksten gjengis ikke i lyd og dermed får brukere som ikke ser tilgang til den samme informasjonen.

Løsningsforslag

  • Forsikre at alle videoer enten har et separat lydspor for synstolking, at videoen blir beskrevet i tekst eller at all viktig informasjon i videoen blir beskrevet i lyd fra start. For att dette skal bli bra er det viktig at man tenker på dette i forkant i planleggingen.

Prioritet

Kritisk prioritet (1)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Videoer mangler tekstbeskrivelse

Problembeskrivelse

Alle videoer på siden Hør fosterforeldre fortelle mangler undertekster. Det betyr at en person som ikke hører, ikke får med seg hva som blir sagt i videoen og blir strengt tatt utelukket til å kunne ta del av samme informasjon som en person som hører. Det er også viktig å tenke på at alt lyd som har betydelse for forståelsen av innholdet, også skal tekstes. For eksempel når personer som prater ikke synes i bilde.

Løsningsforslag

  • Forsikre at alle videoer er tekstet. Som nevnt er det også viktig å gjengi lyd i tekst som er viktig for forståelsen av innholdet.
  • Beste praksis er at underteksten er en separat tekstfil og ikke direkte festet i videoen. Det gjør at brukeren selv kan velge dersom den vil ha tekst eller ikke og det sikrer også at brukere med hjelpemidler får tilgang til teksten.

Prioritet

Kritisk prioritet (1)

Brukere som påvirkes

  • Døve og hørselshemmede brukere
  • Alle brukere

WCAG 2.1 (AA)

Autogenerert feilmeldinger skaper utfordringer for flere brukergrupper

Problembeskrivelse

På flertallet sider har dere inputfelt med autogenererte feilmeldinger. Dersom brukeren ikke fyller ut noen informasjon dukker det opp en feilmelding som kun er synlig i noen sekunder før den forsvinner. Dette skaper utfordringer for brukere som har kognitive vansker, for brukere med nedsatt syn og for brukere som ikke ser og er avhengig av skjermleser for å ta del av grensesnittet.

Per nå blir feilmeldingen gjengitt til skjermleser og det er synlig for alle brukere, men på grunn av at den viser så kort og at brukeren ikke har mulighet til å selv styre hvor lenge den skal synes, er det stor risiko at de ikke får med seg meldingen. Derfor anbefaler vi alltid å etterstrebe å utforme egne feilmeldinger som man har kontroll over.

Slik det er satt opp nå er dessuten ikke feilmeldingen koblet til respektive inndatafelt, så hvis statusmeldingen blir avbrutt på grunn av aktivitet i skjermleser, vil ikke feilmeldingen gjengis.

Løsningsforslag

  • Unngå autogenererte feilmeldinger. Utform feilmedlingene selv og tenk på å ha tekst som beskriver feilen, hva brukeren må gjøre for å rette opp det (hvis mulig), ha et ikon som forsterker status og forsikre at det er programmatisk koblet til repsektive inputfelt.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Brukere med kognitive funksjonsnedsettelser
  • Svaksynte brukere

WCAG 2.1 (AA)

Enkelte interaktive element har ikke tilstrekkelig klikkeområde

Problembeskrivelse

I følge WCAG 2.5.5 skal klikkbare elementer ha et klikkeområde på minimum 44px x 44px, inklusive padding. Dette er fremfor alt viktig dersom det ligger flere klikkbare elementer ved siden av hverandre eller ovenfor/nedenfor. Per nå oppfyller ikke deres lenker i bunnteksten (engelsk:footeren) dette, se figur nedenfor.

Lenkeliste med fem lenker, bunntekst Bufdir. Kontakt oss markert med klikkeområde 94 x 20px.

Tilstrekkelige klikkeområder er fremfor alt viktig for brukere med nedsatt motorikk, men også for alle mobilbrukere.

Dette er et kriterie som per i dag er satt på nivå AAA i WCAG, noe som betyr at det ikke er lovpålagt. Det vil imidlertid endres når Webtilgjengelighetsdirektivet trer i kraft fra og med januar 2022 da kriteriet blir satt til nivå AA.

Løsningsforslag

  • Fosikre at alle klikkbare elementer har et klikkeområde på minimum 44px x 44px.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Alle brukere

WCAG 2.1 (AA)

Enkelte lenketekster bør forbedres

Problembeskrivelse

For å gi brukeren mulighet til å få større klikkeområde på det vi kaller for lenkepuffer, er det vanlig at hele området blir satt som en lenke, se eksempel nedenfor.

Bilde fulgt av overskrift, tekst og en lenketekst. HTML elementet a er markert rundt hele området.

En utfordring dette gir er for brukere som ikke ser og som er avhengig av opplesende hjelpemiddel, slik som skjermleser. Ved navigering med skjermleser blir enten hver del opplest som en lenke dersom de navigerer med piltaster eller så blir alt innenfor området lest opp samtidig dersom de navigerer ved bruk av TAB-tast.
Dette er noe som resulterer i en veldig lang lenketekst og det kan bli utfordrende å fange opp det som er det viktigste i lenketeksten, noe som i sin tur kan føre til at WCAG 2.4.4 ikke blir godkjent.

Løsningsforslag

  • Marker kun overskriften som lenke. I enkelte tilfeller kan også lenketeksten nedenfor blir satt som lenke, så lenge den ikke blir redundant for de som ikke ser.

  • Utvid klikkeområdet ved hjelp av javaskript, se eksempelkode nedenfor.

    <div
onClick[()=>document.GetElementById(cardLinkId)?.click()]
>

  • I DOM (koden), gjør rekkefølgen anderledes enn det som visuelt synes å forsikre at overskriften og teksten kommer først, fulgt av bilde og deretter lenketeksten nederst, se illustrert eksempel nedenfor.

    Bilde, overskrift, tekstavsnitt og lenketekst. Overskrift og tekstavsnitt markert med 1, bilde med nummer 2 og lenketekst nederst som nummer 3.

  • Følg våre anbefalinger i “Innholdsstruktur bør programmatisk forbedres” og “Bruk av landemerker bør forbedres”, slik at lenketekster for en programmatisk kobling til området og overskriften de tilhør.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Enkelte tekstbeskrivelser på knapper må forbedres

Problembeskrivelse

For å melde seg på et informasjonsmøte finnes to knapper med like tekstbeskrivelse. Er dette til samme møte eller to ulike. Hvis det leder til samme møte bør det kun finnes en knapp, hvis det leder til to ulike, bør dette bør tydeliggjøres.

Informasjonsmøte vindu. To knapper hvor brukeren kan melde seg på informasjonsmøte.

Steng knapp i hovedmenyen sier “Åpne globalmeny”. Her burde det snarere vært beskrevet som eksempelvis “Lukk globalmeny”. Per nå vil det være veldig vanskelig for en brukere som ikke ser å forstå at samme knapp lukker menyområdet, siden det spesifikk sier åpne. Som nevnt i , bør menyknappen også ha aria-expanded, som tilsier når menyområdet er utvidet eller minimert.

I modalvinduet for påmelding finnes ingen tekstbeskrivelse i det hele tatt for steng knappen. Det betyr at det kun gjengis som en knapp, men sier ikke hva det er eller hva den gjør for noe.

Påmeldingsskjema med inputfelt. Ikon med et kryss som stenger ned modalvinduet.

Løsningsforslag

Forsikre at tekstbeskrivelse på knapper er tydelige. Brukeren skal kunne forstå hva som skjer etter at de trykket på knappen. Dersom knappen ikke har en synlig tekst, må dere bruke aria-label for å gi beskrivelse til en brukere som ikke ser, eller som er avhengig av stemmestyring for å kontrollere grensesnittet.

<button class="bd-icon-cross" aria-label="Lukk påmeldingsskjema"><svg><use xlink:href="/dist/spritemap.svg#close-cross"></use></svg></button>

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Brukere med nedsatt motorikk

WCAG 2.1 (AA)

Feilmeldinger blir ikke gjengitt til skjermleser

Problembeskrivelse

I følge et av de nye kravene som kommer, WCAG 4.1.3, skal alle statusmedlinger gjengis til hjelpemidler, slik som skjermleser. Dette kan være søkeresultat, sideomlastinger eller for eksempel når det har skjedd en feil på siden. Tar vi en titt på deres påmeldingsskjema for informasjonsmøter så er alle inputfelt påkrevd. Det er enkelte felt hvor det krever at brukeren taster inn riktig format.

Dersom bruker skriver feil format eller glemmer @ i epostadresse gis feilmelding som oppfordrer brukeren til å se over formatet som kreves. Det gir også spesifikk beskrivelse på at @ mangler, noe som er veldig bra. Derimot blir det ikke gjengit at feil har oppstått.

Dette gjelder også for automatiske feilmeldinger beskrevet i .

Løsningsforslag

  • Koble feilmelding til respektive inputfelt ved bruk av aria-describedby + ID på elementet hvor feilmeldinger ligger i koden, se kodeeksempel nedenfor.

    <input class="bl-input bl-input--error" id="telephone" type="tel" name="phone" placeholder="" pattern="^[0-9]{8,12}" required="" value="" aria-describedby="error-message-tlf"><div class="error-message bl-validation bl-validation--error" id="error-message-tlf">Vennligst fyll ut dette feltet.</div>

  • Sørg for at fokus blir plassert i første inputfeltet hvor en feil har oppstått.

  • Dersom dere har skjemaer med mange inputfelt hvor det kan bli feil, ha et samlet område øverst som viser til alle felt hvor feil har oppstått.
    Se eksempel fra Gov.uk - feilmeldinger for inspirasjon.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Fokus blir ikke satt riktig etter å ha trykket på Til topp knapp

Problembeskrivelse

Når man trykker på knappen for å komme til toppen av siden, blir fokuset ikke satt i starten på siden. Per nå havner fokuset oppe i første fanen i nettleseren, noe som både leder til forvirring for en som ikke ser, men også unødvendige navigasjonssteg for alle som navigerer med tastatur.

Løsningsforslag

  • Forsikre at fokuset blir satt riktig etter at brukeren trykket på Til topp knapp, for eksempel til deres logo.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Alle brukere
  • Brukere med nedsatt motorikk

WCAG 2.1 (AA)

Ledetekster er ikke koblet til inputfelt

Problembeskrivelse

Det er flertallet ledetekster til inputfelt som programmatisk ikke er satt riktig. Visuelt kan man se hvilken ledetekst som tilhør hvilket felt, men for en brukere som ikke ser, vil ikke dette være like tydelig dersom en koppling mellom de ikke gjøres i koden.

Et vanlig bruksmønstre ved bruk av opplesende hjelpemiddel, slik som skjermleser, er ofte at man navigerer ved bruk av TAB-tast når det er flere skjemaobjekter på siden. Det gjør at navigeringen raskere mellom de ulike inputfeltene. Dersom ledetekst ikke er koblet sammen med inputfelt, vil skjermleser ikke gjengi hva brukeren må fylle ut.

Løsningsforslag

For at dette skal bli riktig må dere koble ledeteksten sammen med label elementet og ID:et på inputfeltet, se kodeeksempel nedenfor.

<label for="postnr-search" class="bd-search-service__label">Postnummer:</label>
<input type="search" value="" class="bd-search-service__input-field" pattern="^[0-9]{4}" maxlength="4" required="" id="postnr-search">

Per i dag er det brukt aria-labelledby som er koblet til et ID som ikke eksisterer.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Modalvinduer er ikke kodet riktig

Problembeskrivelse

Dere har tenkt riktig i forhold til at modalvinduer må ha en tekstbeskrivelse, men, derimot har dere brukt aria-labelledby og-/eller aria-describedby til et ID:er som ikke eksiterer.

<div class="bd-modal__content is-open"><div role="dialog" aria-labelledby="modal-heading" aria-describedby="modal-content">
<h2 class="bl-size-2 bl-p-b-4">Påmelding</h2>

Dersom dere ønsker å gi modalvinduer en tekstbeskrivelse manuelt, må dere bruke aria-label. Hvis ikke, så må aria-labelledby og aria-describedby være koblet til et spesifikk ID som finnes i koden hvor modalen ligger. Som for eksempel overskriftens ID, se oppdatert kodeeksempel nedenfor.

<div class="bd-modal__content is-open"><div role="dialog" aria-labelledby="modal-heading">
<h2 class="bl-size-2 bl-p-b-4" id="modal-heading">Påmelding</h2>

Løsningsforslag

  • Forsikre at alle modalvinduer er koblet til overskriften ved bruk av aria-labelledby + ID på overskrift. Alternativt at dere bruker aria-label og gir selv en tekstbeskrivelse.
  • Bruk aria-modal=“true” for å sikre at innholdet bak ikke blir tilgjengelig for skjermleser. Bruk også aria-hidden=“true” på alt innhold bak så lenge modalvinduet er åpent.
  • Forsikre at innholdet bak ikke er tilgjengelig med tastatur.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Brukere med nedsatt motorikk

WCAG 2.1 (AA)

Statusmeldinger gjengis ikke til opplesende hjelpemidler

Problembeskrivelse

På siden informasjonsmøter har brukeren mulighet å søke opp informasjonsmøter etter et spesifikk postnummer. Selve søkeresultatet gjengis ikke, hverken når ingen treff er funnet eller hvor mange som vises. Visuelt kan vi se dette enten via en tekst som dukker opp ved ingen treff, eller ved å telle antallet treffer i listen. For en brukere som ikke ser må vi også gjengi samme informasjon uten at de må navigere seg videre på siden.

Det samme gjelder for den globale søkefunksjonen hvor teksten “Søket ga ingen treff” mangler aria-live.

Løsningsforslag

Siden søkreresultatet presenteres i en liste, også programmatisk, kan man gjør den koblingen og gjengi antallet i et skjult span element, se kodeeksempel nedenfor.

<div class="bd-pointer-link-list">
    <span class="sr-only" aria-live="polite" aria-atomic=”true”><span class ="number-meeting">2</span> <span> informasjonsmøter funnet</span>

Da kan dere med skript si at antallet i listen skal gjengis i span med class .number-meeting. 

Ved hjelp av aria attributtet aria-live=“polite”, vil meldinger gjengis til skjermleser. Ved bruk av aria-atomic=“true” sikrer man at hele teksten blir opplest og ikke kun antallet. 

Dersom søkeresultatet ikke skulle gi noen treff, må dere sette en aria-live på teksten som blir vist.

Varningstekst etter søkeresultat som ikke gitt noen treff. Pil peker mot feltet med tekst som sier aria-live.

<div class="bl-validation bl-validation--warning" aria-live="polite">OBS! Vi kunne ikke finne søket ditt..</div>

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Utvidet meny er ikke kodet riktig

Problembeskrivelse

Når menyen er utvidet er det fortsatt mulig å navigere i innholdet bak. Det skaper problemer for seende brukere som er avhengig av tastatur for å navigere da det er vanskelig å oppdage hvor man befinner seg. Dette påvirker fokusrekkefølge og det påvirker visuell fokus da det blir skjult bak den utvidede menyen. Det skaper også forvirring for brukere som ikke ser.

Når det gjelder megamenyer generelt kan det forårsake problemer for svaksynte brukere som bruker skjermforstørrelser for å forstørre små deler av skjermen. Med en skjermforstørrelse kan det hende at bare en liten del av megamenyen er synlig av gangen og dermed anta at det synlige innholdet er alt innholdet som er tilgjengelig. At dere visuelt skiller innholdet i menyen kan hjelpe på dette men det kan fortsatt bli en problematikk.

Løsningsforslag

  • Når menyen er utvidet må bakgrunnen bli låst for navigering med tastatur. Det bør også være skjult for skjermleser med for eksempel attributtet aria-hidden. Når meny er utvidet skal alt innhold bak være satt med aria-hidden=“true” når menyknappen har aria-expanded=“true” og motsatt.

  • På div elementet som er nestet rundt hele menyen, bruk aria attributtet aria-modal=“true” sammen med role=“dialog” og aria-label=“Meny” som gir modalvinduet en tekstbeskrivelse, se kodeeksempel nedenfor.

    <div class="bd-header__megamenu" aria-modal="true" aria-label="Meny" role="dialog"

  • For inspirasjon, se WAI-ARIA 1.2 Authoring practices pattern for dialogs.

Prioritet

Høy prioritet (2)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Brukere med nedsatt motorikk

WCAG 2.1 (AA)

Bruk av landemarker må forbedres

Problembeskrivelse

Landemerker lar hjelpemidler navigere og raskere finne innhold på siden. Overgripende beskriver også landemerker hovedstrukturen på siden for en brukere som ikke ser. Derfor er det viktig at man bruker landemerker riktig. Per nå finnes det ikke noen hovednavigasjon programmatisk markert på siden. Dette er noe som oftest er forventet skal finnes. Det samme gjelder dersom man har et oppsett av lenker som enten leder til ulike deler på samme side eller til andre steder på nettstedet eller eksternt, slik som nede i bunnteksten (engelsk: footere) på siden.

Løsningsforslag

  • Nestle hovednavigasjonen på siden i et nav element. Bruk aria-label og gi tekstbeskrivelse som gjengir hovednavigasjon, se kodeeksempel nedenfor.

    <header class="bd-header bl-p-t-4 bl-p-b-4 bl-p-x-3 hidden-print bd-header--closed bd-header--search-closed
        " data-swiftype-index="false"><nav class="bd-header__topbar" aria-label="hovednavigasjon" style="max-width:auto;margin:auto">
<---Innhold--->
</nav>
</header>

  • Nestle lenkeliste i bunntekst i et nav element og også her bruk aria-label som beskriver lenkelisten, se kodeeksempel nedenfor.

    <nav aria-label="lenkeliste, bunnmeny"><div class="bl-footer__links">
<ul>
<li><a>...</a></li>
</ul>
</div>
</nav>

  • Marker alle søkeområder som et landemerke. Bruk aria-label for å skille de, se kodeeksempel nedenfor.

    <div class="bl-search bl-search--closed" role="search" aria-label="Søk">
<div class="bd-search-service" role="search" aria-label="Søk etter nærmeste fosterhjemtjeneste">
<div class="bd-search-service" role="search" aria-label="Søk etter nærmeste lokalkontor">

    Alternativ kan du bruke aria-labelledby og koble respektive div elementet med role=“search til overskriftens ID på hvert søkeområde, se kodeeksempel nedenfor.

    <h1 class="bd-service-search-office__search-office-box-header" id="heading-office">Finn ditt lokalkontor</h1>
<div class="bd-search-service" role="search" aria-labelledby="heading-office">

    Da vil overskriften bli opplest sammen med landemerket.

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Enkelte knapper gjengir ikke status

Problembeskrivelse

Det er enkelte knapper på siden som ikke gjengir når et nytt område blir utvidet eller lukket. På visse knapper er dette satt riktig med aria attributtet aria-expanded=“true” eller “false”, andre ikke.

Eksempel på knapper der aria-expanded mangler:

Kontaktskjema knapp

Knapp Kontaktskjema.

Meny knapp

Ikon med tre streker, tekst som sier Meny.

Punktet får medium prioritet siden vi kun oppdaget noen få tilfeller i analysen vår.

Løsningsforslag

Forsikre at alle knapper som utvider eller lukket et nytt område har aria-expanded, enten “true” ved ekspandert eller “false” ved minimert.

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Enkelte lister er ikke satt programmatisk riktig

Problembeskrivelse

På siden Prosessen for å bli fosterhjem presenteres en nummerert liste. I koden er dette ikke gjengitt som en liste uten presenteres som en artikkel, som i sin tur har en overskrift med en knapp som utvider et område med tekst. Som nevnt i, anbefaler vi å ikke bruke article elementet i slike tilfeller. Det er helt riktig at elementet skal være en knapp siden den utfør en handling. Knappen er kodet riktig med aria-expanded som gjengir til skjermleser når nytt område er ekspandert eller minimert. Hva det ikke gjengir er at det er en liste med 8 steg, noe som det bør gjøre for at brukere som ikke ser, skal få samme informasjon.

Noe vi også anbefaler er å programmatisk sette opp som lister for innhold eller informasjon som presenteres som en liste visuelt. For eksempel på siden Hvordan det er å være fosterhjem der man har mulighet til å lese om andre sine erfaringer. Hvor mange historier vi kan ta del av, kan vi se visuelt, emn for noen som ikke ser, er det beste praksis å også gjengi dette programmatisk slik at også skjermleser gjengir det totale antallet.

Les om andre sine erfaringer, overskrift. 9 stykker artikler vises med bilde og lenketekst.

Løsningsforslag

For førstnevnte eksempel anbefaler vi to ting. 

  • Å sette opp hele listen med ol elementet og at hver knapp blir nestet i et listelement. Ol elementet står for ordered list på engelsk og skal kun brukes dersom det foreligger en spesifikk rekkefølge i en liste, slik som i dette tilfelle.

  • Dersom brukeren navigerer med TAB-tast må vi også sikre at tallet blir opplest i tilknytning til teksten. Dette kan gjøres ved å bruke et span element som kun er synlig for skjermleser, se kodeeksempel nedenfor.

    <span class="sr-only"> 1.</span>

  • For det andre ovennevnte eksempel anbefaler vi å:

    • Makere hele området som en liste hvor hvert bilde og lenketekst blir satt i et listeelement.

    • Gjør en programmatisk koblig mellom hovedlistelementet (ul) og overskriften, se kodeksempel nedenfor.

      <h2 class="bl-size-2 bl-m-y-5" id="heading-others-experiences">Les om andre sine erfaringer</h2>
<ul aria-labelledby="heading-others-experiences">
<li>
<--Bilder og lenketekst-->
</li>
...
</ul>

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Innholdsstruktur bør programmatisk forbedres

Problembeskrivelse

På flertallet sider har det blitt brukt HTML elementet article, noe som ikke er nødvendig eller hensiktsmessig i forhold til det som blir vist visuelt. En generell tommelfingerregel er at elementet article kun skal brukes når det gjelder spesifikke artikler og som er uavhengig av det andre innholdet på siden eller som er et utdrag fra en del av hovedinnholdet på nettsiden. Elementet article gir en semantisk struktur og kan være forvirrende for brukere som ikke ser grensesnittet dersom dette brukes på “feil” måte. Det er også forventet at en article element skal inneholde en overskrift og en tekst, slik som dere har gjort det på enkelte deler i innholdet. 

Tar vi en titt på hovedsiden kan enkelte områder bli bedre markert programmatisk for å gjøre en tydeligere innholdsstruktur. Per nå er det kun satt fem landemerker på siden med en main og fire artikler områder. For opplesende hjelpemidler blir dette opplest ulikt. I VoiceOver sier det artikkel, I Windows innebygde skjermleser sier det dokument, i NVDA blir ikke landemerket opplest.

Rotor VoiceOver, 5 landemerker i listen.

Tar vi en titt på HTML elementene aside og section, som også er landemerker, blir de opplest av alle skjermleser og her anbefaler vi å bruke noen av de, sammen med article, for å gi en bedre struktur på siden.

Da kan det se slik ut, se illustrert eksempel nedenfor.

Rotor VoiceOver, 8 landemerker i listen fordelt på artikler, områder og komplementær.

Her har vi både spesifisert de ulike delene på siden og vi har også gitt en tekstlig beskrivelse som gjør det enklere for brukere som ikke ser, til å komme til eventuelt ønsket innhold på siden.
På den måten sikrer vi også at lenketekstene får en programmatisk kobling til hele området.

En programmatisk kobling bør også gjøres på enkelte av deres lister, som for eksempel på siden Fosterhjemstjenester. På den måten skaper vi også en programmatisk relasjon mellom region og fylker.

Løsningsforslag

  • Fjern HTML elementet article på områder hvor det ikke er hensiktmessig. For eksempel på utvidbare knapper, lenkelister og lignende.

  • Bruk section elementet for å markere opp ulike områder, som for eksempel hvor dere har en overskrift og lenkelister.

  • Bruk aside elementet på områder som er komplementær informasjon, som for eksempel på Kontakt oss, finn ditt lokalkontor og informasjonsmøter.

  • Fjern nav elementene over respektive liste i Fosterhjemstjenestene. Dette representerer ikke det som forventes å være en navigasjonsområde.

  • Koble respektive overskrift med listenes ID verdi, se kodeeksempel nedenfor.

    <h2 class="bd-office-link-list__region-header" id="header-east">Øst</h2>
<ul class="bl-link-list bl-link-list--pointer"><li><a href="/fosterhjem/kontorer/akershus/" aria-labelledby="header-east">

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Innstillinger for cookies dukker stadig opp

Problembeskrivelse

Innstillinger for cookies dukker opp når brukeren først kommer inn på siden, noe som er et forventet. Derimot dukker det fortsatt opp selv om man gjort et valg. Hva vi har sett, virker dette å skje hver gang man navigerer seg bakover fra bunnteksten og opp.

Løsningsforslag

  • Når man gjort et valg for innstillinger i cookies, forsikre at den ikke blir trigget eller aktivert igjen.

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Alle brukere
  • Brukere med nedsatt motorikk

WCAG 2.1 (AA)

Savn av ordentlig brødsmulesti

Problembeskrivelse

Slik det ser ut i dag vises kun en lenke i en slags brødsmulesti. For det meste leder denne kun til startsiden for Fosterhjem og ikke til den forrige siden man befant seg på. Dette er noe som raskt kan lede til feil klikk.

Hvis brukeren for eksempel har klikket seg videre til et område fra Fosterhjemstjenester og vil tilbake igjen til oversiktssiden , finnes bare en lenke til Fosterhjemssiden. Dersom man vil komme tilbake til forrige side må man per nå bruke tilbakeknappen i nettleseren, noe som også gjør navigeringen litt ekstra krevende for de som er avhengig av hjelpemidler for å navigere.

Løsningsforslag

  • Opprett en brødsmulesti som stemmer overens med sidehierarkin.

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Alle brukere

WCAG 2.1 (AA)

Tabeller er ikke kodet riktig med kolonne- og/eller radoverskrifter

Problembeskrivelse

Under siden Fosterhjem | Betaling og tjenester finnes en tabell som ikke er programmatisk riktig i forhold til kolonneoverskrifter.

Tabell med fire kolonner og fem rader som viser satser for fosterhjem per barn per måned fra 1. juli 2021.

Visuelt kan vi se hvilken tekst som fungerer som kolonneoverskrifter og hvilken tekst som er tabelldata. Hvis dette ikke settes programmatisk i koden, vil brukere som ikke ser, få vanskligheter med å forstå relasjonen mellom kolonnene i tabellen.

Løsningsforslag

Per nå er alle kolonner satt med elementet td, noe som betyr tabellcelle. For å markere kolonneoverskriftene riktig må de være plassert i th elementet. Th betyr table heading på engelsk og står for kolonne eller radoverskrift. Bruk også attributtet scope=“col” som spesifiserer at det er kolonneoverskifter. Dersom det i andre tilfeller ville vært radoverskrifter så må dere bruke col=“row”. 

En generell anbefaling er også å visuelt fremheve overskriftene tydeligere, enten ved å bruke fet skrift eller annen bakgrunnsfarge.

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser
  • Svaksynte brukere

WCAG 2.1 (AA)

Videoer mangler tittel

Problembeskrivelse

Alle videoer på siden Hør fosterforeldre fortelle mangler tittel. Det betyr at når en brukere som ikke ser navigerer med skjermleser så får den ikke gjengitt hva for slags innhold som finnes inne i rammen.

Løsningsforslag

  • Når du legger in videoer i så kalt iframes så er det viktig at du setter tittel på videoen. Dette gjøres i selve elementet med title attributtet, se kodeeksempel nedenfor.

    <iframe src="https://www.youtube.com/embed/5WS3vLNDhYc?list=PLjpNIfkX49jGhshGX0RwpjrC8zfqkYcQ5&amp;enablejsapi=1" width="100%" height="445" frameborder="0" data-gtm-yt-inspected-1120589_338="true" id="822460655" data-gtm-yt-inspected-1_19="true" title="Heidi og Ole.Hva gjør man når barna har flyttet ut?"></iframe>

Prioritet

Mellomstor prioritet (3)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Enkelte overskrifter ligger ikke i riktig nivå

Problembeskrivelse

Overgripende har dere gjort en veldig god job når det gjelder overskrifter og hierarkisk rekkefølge, bra jobbet! Vi fant kun et avvik på dette og det gjaldt for siden Kontorer | Oslo.

Overskriftsstruktur. Overskrift 1, fulgt av to overskrifter på nivå 3. Deretter fire overskrifter på nivå 2.

Løsningsforslag

  • Her må dere enten fjerne knappteksten som overskrift eller sette de i riktige nivåer, som i dette tilfellet ville vært på nivå 2.

Prioritet

Lav prioritet (4)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Presentasjonsvisning av dokument og lenkeliste kan bli utfordrende for svaksynte brukere

Problembeskrivelse

På siden “Veiledere, retningslinjer, faglige anbefalinger, rundskriv og forløp” blir dokument og lenker presentert i en alfabetisk rekkefølge. Dette er en god måte å gjøre dette på. Derimot vil det bli utfordringer i hvordan listene er visuelt presentert.

En nedsatt funksjonsnedsettelse er tunnelsyn, noe som fremfor alt kan påvirke mennesker i høyere alder. Tunnelsyn betyr at brukeren kun kan se sentrale elementer av gangen. Derfor er det anbefalt at man ettersteber så godt det lar seg gjøre å ha hovedinnholdet sentrert på siden. Det er greit i forhold til informasjon som ikke er en del av hovedinnholdet men som uansett er relatert, men når det gjelder den her typ av fremstilling, anbefaler vi å heller sentrere listene under hverandre. 

Nedenfor kan dere se et eksempel på en simulering av tunnelsyn. Verktøyet som er brukt heter Silktide.

Simulering av tunnelsyn. En sentral del av siden syns i midten av skjermen, resten av innholdet er mørkt. Skjermdump.

Nå vet jeg at siden ikke er en del av det nye innholdet, men vil allikevel nevne det, i tilfelle en slik presentasjonsmetode blir vurdert å brukes på andre steder. 

Dette er ikke et direkte brudd på noe WCAG krav uten noe vi anbefaler utfra et tilgjengelighetsperspektiv.

Løsningsforslag

Prioritet

Lav prioritet (4)

Brukere som påvirkes

  • Svaksynte brukere
  • Eldre

WCAG 2.1 (AA)

Tekst som visuelt ser ut som lenker, er ikke merket som lenker

Problembeskrivelse

På siden Spørsmål og svar er det tekst som visuelt oppfattes som lenker, ikke merket som lenker. Dette er noe som kan bli forvirrende for mange brukere siden teksten spesifisert sier “Les mer om opplæringen” eller “Se alle planlagte inforasjonsmøter og kurs”.

Tekstavsnitt med to fetmarkerte teksten nederst som sier Les mer om opplæringen og se alle planlagte informasjonsmøter og kurs.

Løsningsforslag

  • All tekst som visuellt kan oppfattes og som beskrives som en lenketekst, bør markeres som en lenke. Når de er programmatisk satt som en lenke er det også viktig å huske på at fetmarkert tekst ikke er tilstrekkelig for at alle brukerne skal kunne oppfatte de som en lenke. Bruk også understrek eller et ikon for å indikere at det er en lenke.

Prioritet

Lav prioritet (4)

Brukere som påvirkes

  • Alle brukere

WCAG 2.1 (AA)

Tekstbeskrivelser på bilder kan forbedres

Problembeskrivelse

Overgripende har det blitt gjort en god jobb når det gjelder tekstbeskrivelser på bilder. Det som kan forbedres er å tydeliggjøre beskrivelsen bedre på enkelte. Slik som når man kun sier illustrasjon, og ikke hva det er illustrasjon av.

Barn i ulike alder og kjønn, illustrasjon. Alt tekst som kun sier illustrasjon.

I andre bildetekster henviser man direkte til bilde, men som er skjult for de som ikke ser gjennom at man latt alt teksten være tom (alt=""). Her ville vi anbefalt at man gav bildene en beskrivelse, siden de også er meningsbærende i forhold til innholdet på siden. Dette omfatter sidene som handler om andre sine erfaringer.

Løsningsforslag

Forsikre at alle meningsbærende bilder har en tekstlig beskrivelse og at det gjengir det som synes i bildet. Tenk at det skal gi likeverdig informasjon til en brukere som ikke ser. Har bilde en betydning til innholdet på siden, bør det finnes en beskrivelse i alt attributtet. Hvis det kun er for visuelt formål, kan det markeres som dekorativt ved å enten la alt attributtet være tomt eller bruke role=“presentation”.

Prioritet

Lav prioritet (4)

Brukere som påvirkes

  • Blinde eller synshemmede brukere med skjermleser

WCAG 2.1 (AA)

Powered by Cupper