Dersom dine tjenester er pålagt å overholde Universell Utforming (WCAG), er det en del kriterier man som tjeneste-bygger må forholde seg til. Hovedparten av WCAG-kriteriene oppfyller Compose-plattformen automatisk, og disse er ikke adressert i håndboken. De resterende kriteriene kan brytes da de relaterer seg til utformingsfriheten i Compose.

Denne veiledningen er en komprimert håndbok som gir deg informasjonen du trenger for å oppfylle universell utforming. Vi anbefaler at du leser gjennom dokumentasjonen før du bygger en tjeneste. Deretter kan dokumentasjonen brukes som et oppslagsverk. Siden inneholder informasjonspanel som oppsummerer viktige punkter å ha i bakhodet når du bygger:

Håndboken refererer kontinuerlig til løsningsforlaget for nettsider av Tilsynet for universell utforming av ikt (uutilsynet). Dersom du har ytterligere spørsmål om Universell Utforming i kontekst av Compose-plattformen, kan du sende oss henvendelser til support@usecompose.com.

Innholdsfortegnelse

1. Ikke-tekstlig innhold (Bilder, Kart, Video, Lyd)

Dersom du ønsker å bruke multimedia som tjenesteinnhold bør du sette deg inn i kriteriene som omfatter typen ikke-tekstlig innhold du ønsker å implementere. Uutilsynet har ytterligere dokumentasjon for reglene knyttet til bilder og grafikk og video og lydopptak.

1.1 Alternativ tekst for innhold som ikke er tekst

Kriteriene 1.1.1, 1.2.1 og 1.2.2 pålegger at brukeren gis tekstalternativer for følgende ikke-tekstlig innhold (lister kun innhold som tilbys i Compose):

• Bilder, kart og video

• Kun video (uten lyd som f.eks. GIF-er) eller kun lyd (uten video)

• Dekorasjonselementer utelukkende for dekorasjon

1.1.1 Bilder og kart i skjema

Bilder og kart er pålagt å ha et alt-attributt i HTML-koden. I Compose er det dermed vesentlig dersom du bruker Bilde- eller Kart-elementer i skjemabyggeren, at du ikke lar Alternativ tekst (alt)-feltet stå tomt. Det er nemlig dette feltet som fyller alt-attributtet.

Open

1.1.2 Lydmedia med og uten video

Fra løsningsforlaget til nettsteder (uutilsynet):

I Compose er det per januar 2023 kun video fra YouTube som kan bygges inn i skjema. Sjekk ut dokumentasjonen for hvordan du legger til videoer i skjemabyggeren. YouTube tilbyr tekste-funksjonalitet, men det er opp til tjeneste-bygger å passe på at tekstingen er av høy nok kvalitet til å overholde UU-standarden. Tekste-funksjonaliteten til YouTube overholder mange kriterier automatisk. De resterende kriteriene, som er tjeneste-byggers ansvar, oppfylles dersom tekstingen

• formidler innholdet i lyd og bilde.

• inneholder tale og dialog med markering av hvem som snakker. Hvem som snakker må komme frem hvis det ikke er mulig å forstå ut fra bildene alene, som for eksempel når den som snakker ikke er synlig i videoen. En eventuell fortellestemme må også markeres i teksten.

• inneholder lydinnhold som er viktig for å forstå videoen. All viktig lyd som ikke er tale må beskrives. Dette kan for eksempel være lydeffekter, musikk, latter og lignende.

Dersom man ønsker å bruke tekstingen på YouTube-videoen til å oppfylle kravet, anbefales det at man har anledning til å endre tekstingen. Dersom man selv har lastet opp videoene som linkes til i tjenesten, har du full administrativ tilgang til tekste-modulen til YouTube. Du kan ikke endre tekstingen som en person uten tilknytning til videoen.

Dersom du trenger å linke til en video i tjenesten som enten ikke er tekstet eller ikke har god nok teksting, kan du løse dette ved å legge til tekstingen som et tekst-element under video-elementet i skjemaet.

Open

Disse kriteriene gjelder uavhengig om videoen som tilbys kun består av et lydspor, eller både lyd og bilde. Tekstingen kan skrus av og på i video-vinduet, som overholder UU-standarden (krav 1.4.2).

1.1.3 GIF-er (video som ikke kan pauses eller stoppes)

1.1.4 Dekorasjonselementer utelukkende for dekorasjon

Rent dekorative bilder er blant annet bilder som er brukt for å bygge grafisk design for nettstedet. Disse skal ha alt-attributt, men det skal være tomt: alt="". Dette gjelder også for bilder som ikke presenteres for brukerne. Det beste er om disse bildene er lagt inn ved hjelp av CSS.

1.2 Bilder av tekst

Jfr. krav 1.4.5 skal bilder av tekst så langt det er mulig unngås og heller representeres av tekst. Følgende unntak gjelder:

• Bildet kan tilpasses: Bildet av teksten kan visuelt tilpasses til brukerens krav. Et eksempel på dette er at bildet forblir skarpt dersom brukeren har behov for å zoome inn på brukergrensesnittet. Bilde-elementer i Compose støtter implementering av vektorgrafikk som til fordel bør brukes istedenfor punktgrafikk.

• Nødvendig tekst i bilder: En bestemt presentasjon av tekst er nødvendig for informasjonen som formidles.

  • Logo/Varemerkenavn: Tekst som utgjør en del av en logo anses som nødvendige.

  • Diagrammer/organisasjonskart: Essensiell forklarende titler/tekst til illustrasjoner, se eksempel under. Her er det viktig at du legger ved en tilhørende tekstversjon (som et tekstelement) og en alt-tekst som beskriver formål og hovedinformasjon fra bildet.

Open

1.3 Kontrastforhold for ikke-tekstlig innhold

Se avsnitt 2.2 om fargekontrast mellom tekst, bakgrunn og ikke-tekstlig innhold i tjeneste-design.

1.4 Blinkende media (video)

Jfr. krav 2.3.1 skal ikke innhold blinke mer enn tre ganger per sekund. Dette kriteriet kan kun brytes av video-elementer. Tjeneste-byggeren må forsikre seg om at linkede YouTube-videoer ikke blinker mer enn tre ganger per sekund.

1.5 Særegen regel for kart

Jfr. krav 2.1.1 skal all funksjonalitet kunne brukes kun ved hjelp av tastatur. Kart-grensesnitt er generelt vriene å bruke kun ved hjelp av tastatur og uutilsynet har dermed unntatt kartgrensesnitt fra UU-kravene. Dette skyldes at kartteknologien ikke er moden nok til å støtte UU.

Compose har i dialog med uutilsynet etablert at tekstfelter med koordinater kan brukes som et alternativ for markeringsfunksjonaliteten i kart. Hvordan dette gjøres demonstreres i en egen brukerveiledning: Trigger-skript med kartkoordinater. Dette er et anbefalt oppsett for å tilby brukere kart-tjenester med tastaturnavigasjon.

2. Skins og tjeneste-design

Når du lager tjeneste-design med CSS har du meget stor frihet i innholdets utforming. Dersom designet avviker i stor grad fra standard-designene til Compose bør du passe på at du ikke bryter kriteriene som adresseres i delkapitlene under.

2.1 Responsivt design

For å lage et WCAG-samsvarende tjeneste-design i Compose anbefaler vi å bruke rammeverket bootstrap. Standard-grensesnittet til Compose i bootstrap er bygget spesielt for å overholde kravene som omfatter responsivitet – 1.3.4, 1.4.4, 1.4.10, 1.4.12 & 2.5.4. Kravene spesifiserer som følger:

• Innhold skal kunne endres til 400 prosent størrelse uten tap av informasjon eller funksjonalitet.

• Tekstavstand skal kunne overstyres for å gjøre teksten lettere å lese. *

• Brukeren må få velge om innholdet skal vises i liggende eller stående retning.

  • Dette er den eneste funksjonaliteten med brukerbevegelse i krav 2.5.4 som er aktuell for tjenester bygget i Compose.

Disse kravene er overholdt i standard-grensesnittet med bootstrap. Når skinet utvikles må tjeneste-designer sørge for at kravene fortsetter å være overholdt. Se også avsnitt 3.7 for hva tjeneste-bygger kan gjøre for å fasilitere responsivitet i designet.

*Av krav 1.4.12 er det en rekke konkrete krav når det gjelder avstand mellom tekst. Kravene overstyres i CSS-filen til tjeneste-skinet. Følgende må gjelde for tjenesten uten at innhold eller funksjonalitet går tapt:

• Linjeavstand er minst 1,5 ganger skriftstørrelsen.

• Avstand etter avsnitt er minst 2 ganger skriftstørrelsen.

• Avstanden mellom bokstaver i blokker av tekst er minst 0,12 ganger skriftstørrelsen.

• Avstanden mellom ord er minst 0,16 ganger skriftstørrelsen.

Ved å overholde responsivitet vil du unngå at innhold og funksjonalitet dekkes når brukere zoomer inn i tjenesten. Dersom avstandene resulterer i et design som ikke er tilfredsstillende, anbefaler vi å opprette et ekstra startpunkt i prosessen til tjenesten som kan ha et spesifikt WCAG-design. Lenken til WCAG-versjonen av tjenesten kan linkes til i den originale tjenesten (se veiledningen https://composetogo.atlassian.net/wiki/spaces/DNO/pages/1278640180).

2.2 Fargekontrast mellom tekst, bakgrunn og ikke-tekstlig innhold

Kriteriene 1.4.3 og 1.4.11 dikterer at følgende fargekontraster må gjelde på enhver side i prosessen:

• Den visuelle presentasjonen av tekst og bilder av tekst har et kontrastforhold med bakgrunnen på minst 4,5:1, unntatt i følgende tilfeller:

  • Stor tekst: Stor skriftstørrelse og bilder av stor skriftstørrelse har et kontrastforhold på minst 3:1.

  • Uvesentlig: Tekst eller bilder av tekst som utgjør en del av en inaktiv brukergrensesnittkomponent, som er ren dekorasjon, som ikke er synlig(e) for noen, eller som utgjør en del av et bilde som inneholder annet vesentlig visuelt innhold, er ikke underlagt kontrastkrav.

  • Logoer: Tekst som utgjør en del av en logo eller et varemerkenavn, er ikke underlagt kontrastkrav.

• Ikke-tekstlig innhold skal ha et kontrastforhold på minst 3:1 mot farge(r) som ligger siden av.

  • Brukergrensesnittkomponenter: Visuell informasjon som kreves for å identifisere brukergrensesnittkomponenter og tilstander, unntatt inaktive komponenter eller der utseendet på komponenten er bestemt av brukeragenten og ikke endret av produsenter av webinnhold.

  • Grafiske objekter: Deler av grafikk som kreves for å forstå innholdet, unntatt tilfeller der en bestemt presentasjon av grafikk er nødvendig for informasjonen som blir formidlet.

Fargekontraster utover standard-layoutene som finnes innebygget i Compose, defineres i CSS-stilarket for tjeneste-skin. Når du tester et skin med en tjeneste, kan du bruke nettleserens utvikler-verktøy for å sjekke kontrastforholdet. I Google Chrome aktiverer du DevTools ved å høyreklikke på tjeneste-siden og velge Inspiser-valget (tastatursnarvei: Ctrl/Cmd + Shift + I). Bruk Select-verktøyet øverst til venstre i DevTools-menyen, og beveg musen over teksten/innholdet du ønsker å sjekke kontrastforholdet til.

Open

I eksempelet over hovret musen over teksten www.usecompose.com som hadde et kontrastforhold på 3.06. Kontrasten er for liten, og det er indikert med varsellampe-ikonet til høyre for kontrastforholdet.

2.3 Dekorasjonselementer utelukkende for dekorasjon

Se avsnitt 1.1.4 om ikke-tekstlig innhold.

2.4 Elementer med fokus

Når elementer får fokus eller markeres er det spesifikt to krav man må passe på å overholde i skin-et. Krav 2.4.7 og 3.2.1 krever følgende:

• Sørg for at alt innhold får synlig fokus når du navigerer med tastatur.

• Når et element kommer i fokus medfører dette ikke automatisk kontekstendringer i siden.

Standard-grensesnittet i Compose bootstrap oppfyller disse kravene. På uutilsynets side om tastaturnavigasjon under fokusmarkering finnes flere eksempler på hvordan du kan overholde synlig fokus.

3. Tekstlig innhold (skjema og prosesstekster)

Ved utforming av tekstlig innhold er det flere kriterier som oppfylles automatisk dersom du går inn for å lage en brukervennlig tjeneste. Det er likevel noen fallgruver, samt at noe innhold må ta høyde for hvordan strukturen gjenspeiles i koden. Alle disse fallgruvene dekkes i de kommende avsnittene.

3.1 “Skikk og bruk”

Flere kriterier koker ned til en form for skikk og bruk mtp. utforming av tekstlig innhold. I dette avsnittet gjøres tjeneste-byggeren obs på hva som må tilrettelegges for å samstyre det programmeringstekniske til å følge kriteriene.

Du oppfyller flere kriterier automatisk når du går inn for å lage en informativ og brukervennlig tjeneste. For eksempel er kriteriene 1.3.2, 2.4.2, 2.4.6, 3.2.2 og 3.3.2 uproblematiske å oppfylle dersom:

• Sidetitler beskriver den aktuelle sidens emne eller formål.

• Overskrifter og ledetekster beskriver emne eller formål.

• Det vises ledetekster eller instruksjoner når du har skjemaelementer som må fylles ut.

• Endring av verdien til et skjemafelt medfører ikke automatisk kontekstendringer i siden.*

• Innholdet presenteres i en meningsfylt rekkefølge.*

Dette er grunnleggende funksjonalitet i skjemabyggeren der tjeneste-bygger har full frihet i utformingen. Se avsnitt 3.2 for ytterligere informasjon om ledetekster.

* Krav 1.3.2 og 3.2.2 trenger man kun å forholde seg til dersom man lar innhold komme til syne ved hjelp av visningsbetingelser.

3.1.1 Spørsmål uten ledetekster

Dersom du ønsker å oppgi spørsmål uten ledetekster i et skjema er det viktig at spørsmålsteksten fortsatt er god og beskrivende! Input-baserte felter som tekstfelt, tekstbokser, dato- og passord-felter får spørsmålsteksten knyttet til input-feltene i koden (aria-labels). Dette kommer av krav 1.1.1 og forsikrer at brukere som benytter seg av verktøy for å lese opp spørsmålsteksten i koden, fortsatt vil kunne besvare spørsmål uten ledetekster. Derfor hvis du velger Ingen tekst som posisjon på et spørsmål, så husk å gi spørsmålet en god ledetekst selv om det ikke synes.

Open

3.1.2 Visningsbetingelser

Dersom man bruker visningsbetingelser for å la skjemainnhold komme til syne, må dette forekomme uten kontekstendringer og slik at innholdet beholder en meningsfylt rekkefølge.

Kontekstendringer (jfr. krav 3.2.2) kan være vesentlige endringer av meningsinnholdet til nettsiden, at tastaturfokus blir endret til en annen komponent (fordi elementet med fokus plutselig blir skjult), åpning av filer/nettsteder fra nettlenker etc. Dersom denne typen kontekstendring er vesentlig for tjenesten er det tjeneste-byggers ansvar å sørge for at sluttbrukeren får et tydelig og synlig varsel før endringen inntreffer.

En meningsfylt rekkefølge av krav 1.3.2 er definert slik:

• Når rekkefølgen som innholdet presenteres i, påvirker meningsinnholdet, kan en korrekt leserekkefølge bestemmes programmeringsmessig.

En korrekt leserekkefølge programmeringsmessig tilsvarer leserekkefølgen på skjemainnholdet i skjemabyggeren. Alt innhold i skjemabyggeren uavhengig av hvorvidt det er synlig i slutt-tjenesten, vil være leselig for verktøy som leser koden. Det betyr at skjemainnhold skjult av visningsbetingelser kan bryte WCAG-kravet dersom de ikke eksisterer i en meningsfylt rekkefølge med resten av det synlige innholdet.

Eksempel WCAG-brudd

Under vises en skjemaside med et radioknapp-spørsmål og to tekstelementer med visningsbetingelser. Avhengig av hvorvidt sluttbrukeren svarer Ja eller Nei vil én av tekstelementene vises for å informere om sluttbrukeren kan fortsette søknaden.

Open

Dette oppsettet er problematisk, for begge elementer vil leses i koden selv om kun én av dem vises. Dermed vil informasjonen ikke være funksjonell og rekkefølgen blir ukorrekt. Et forslag til en WCAG-gyldig løsning er å erstatte begge tekster med en hint-tekst på spørsmålet.

Open

Uavhengig av svaret på spørsmålet vil du unngå at leserekkefølgen programmeringsmessig blir ukorrekt.

3.2 Ledetekster

Krav 1.3.3 og 1.4.1 krever at instruksjoner ikke utelukkende skal være avhengige av farge eller andre sensoriske egenskaper for å kunne bli forstått. Altså skal ikke instruksjoner utelukkende være avhengig av farge, form, størrelse, visuell plassering, orientering, eller lyd. Den enkleste måten å overholde kravet på er med instruksjoner i Compose-skjema som har tekstalternativ i tillegg til sensorisk signalement. Slike instruksjoner er overholdt i standardkomponentene i Compose. Her er de mest aktuelle eksemplene på overholdelse av kravet dersom man ikke bruker standardkomponentene:

• Sørg for å ha tekstlige feilmeldinger i valideringsfeilmeldinger (og ikke bare ikon/farge)

  • Kravet kan bli brutt dersom nye valideringer bygget i valideringsbyggeren mangler tekstlige feilmeldinger.

• Unngå tjeneste-design hvor instruksjoner utelukkende består av bilder/ikoner.

Under vises eksempelet med tekstlige feilmeldinger. Begge e-postfeltene har e-postvalideringer, men kun én av dem har en tekstlig feilmelding:

Open

3.2.1 Nettlenker - Utforming, mål og funksjon

Ved inkorporering av nettlenker gjelder følgende retningslinjer fra krav 1.4.1 og 2.4.4:

• Nettlenker må i tillegg til å være fargelagte, ha en ytterligere markering (som understrek eller fet tekst).

• Lenkers mål og funksjon fremgår tydelig av lenketeksten

Ledetekster i Compose kan formateres med inkorporerte nettlenker, samt rik tekstformatering (som fet-, kursiv og understreket tekst). Ta en titt på denne brukerveiledningen for å lære hvordan du formaterer tekst – https://composetogo.atlassian.net/wiki/spaces/DNO/pages/1494974517.

Under vises et eksempel på brudd og samsvar når det gjelder fargelagte nettlenker:

Open

3.2.2 Valideringsfeilmeldinger

Når du bruker valideringer på spørsmål er det et par krav (3.3.1 og 3.3.3) til utformingen av valideringsfeilmeldingene:

• Du må vise hvor feilen har oppstått og gi en tekstlig beskrivelse av feilen.

• Brukeren må få et forslag til hvordan feilen kan rettes.

Valideringsfeilmeldinger spesifiseres i Valideringsbyggeren for hjemmelagde valideringer, samt i datamodellen dersom du bruker valideringsskript. Valideringsfeilmeldinger er hardkodet sammen med spørsmålet feilmeldingen er knyttet til, så du trenger ikke spesifisere hvor feilen er oppstått. Feilmeldingen bør bestå av en tekstlig beskrivelse av feilen, samt et forslag til hvordan feilen kan rettes, slik som illustrert under:

Open

3.3 Veiledende tekster

Veiledende tekster i Compose brukes her som et fellesbegrep for hjelpetekster, tooltip og hinttekster. Disse er forklarende tekster som kan settes på skjemaelementer og svaralternativene til spørsmål med enkelt- eller flervalg (radioknapp- og avkrysningsspørsmål). Tooltip og hinttekster oppfyller alle WCAG-kriterier, men det er noen spesielle tilfeller som tjenesteutvikler bør være oppmerksom på i Compose.

Krav 2.1.1 tilsier at all funksjonalitet som tilbys til sluttbrukeren skal kunne brukes kun ved hjelp av tastatur. Hjelpetekster på spørsmålselementer oppfyller dette kravet, men hjelpetekster på svaralternativer er ikke tilgjengelige med tastaturnavigasjon.

Hjelpetekster på svaralternativer for radioknapp- og avkrysningsspørsmål

For å ha tjenester som samsvarer med krav 2.1.1 om tastaturnavigasjon kan ikke spørsmål med radioknapper og avkrysning ha hjelpetekster på svaralternativer. Viktig: Tooltip og hinttekst (obs se kap. 3.3.1) overholder WCAG og kan puttes på svaralternativer.

Open

Hjelpetekster i form av pop-ups og modalvinduer har en egen lukk-knapp (per kriterie 1.4.13).

Open

Open

For at denne knappen skal kunne tolkes av verktøy som leser HTML-kode (se avsnitt 3.4 for kontekst til slike verktøy), så er det viktig at tekst-alternativet til knappen er oversatt til riktig språk. I Språk-menyen i skjemabyggeren, under Generelle egenskaper er en tekst som heter ARIA Lukk hjelpevindu.

Open

Denne teksten (en ARIA-label) vil representere lukk-knappen i koden. Dersom prosessen din har flere språk, er det derfor viktig at du sjekker at denne teksten har en god oversettelse.

3.3.1 Hyperlenker i hinttekster på radioknappalternativer

På svaralternativer for radioknapper er det mulig å legge inn hyperlenker i hinttekster.

Open

Dette er i overhold med kravene om Universell Utforming, men tastaturnavigasjonen (per krav 2.1.1) er ikke intuitiv. Når ingen alternativer er valgt, så vil bruker kunne navigere mellom alternativene og hyperlenkene med Tab. Utfordringen kommer når du har valgt et alternativ, for da vil du ikke lenger få tilgang til resten av radioknappene med Tab-tasten. Da må bruker navigere til den valgte radioknappen for så å navigere mellom radioknappene med piltastene.

Open

3.4 Obligatoriske prosesstekster

Brukere med nedsatt synsevne trenger at ulike prosesstekster reflekteres riktig i HTML-koden til tjenesten. Hvis “tekst-til-tale”-verktøy brukes, vil det hovedsakelig være HTML-koden som leses, og da er det tjeneste-utviklers ansvar å passe på at de har oppgitt tilstrekkelig gode tekster. Ved å følge “Skikk og bruk”-anvisningene i avsnitt 3.1, vil hovedparten av skjematekstene reflekteres riktig. I delavsnittene under høylyses prosesstekstene man også bør ta stilling til.

3.4.1 Prosesstekster som brukes i <title>-elementer

Krav 2.4.2 pålegger nyttige og tydelige sidetitler i brukergrensesnittet ssom reflekteres i HTML-koden. Titlene tilgjengeliggjøres i koden som <title>-elementer og defineres av prosesstekster som tjeneste-utvikler definerer i skjema- og prosessbyggeren. Spesifikt for skjematjenester som har mer enn én side er det viktig at <title>-elementet gjenspeiler tittelen til tjenestesiden, men også hvilken tjeneste siden er en del av. Derfor er den generelle strukturen til <title>-elementet, f.eks. for startsiden til en tipsveiviser:

• <title>Sidenavn - Prosessnavn</title>

• F.eks: <title>Startside - Tips Fiskeridirektoratet</title>

Open

Derfor er det viktig at prosessen får et navn i innstillingene i prosessbyggeren. Prosessnavnet vil være en del av <title>-elementene i tjenesten uavhengig av om prosessnavnet er skrudd på som et layout-element.

Open

Det er 8 prosessaktiviteter som produserer synlige sider som trenger <title>-elementer:

• Startpunkt

• Skjema

• Validering (2 sider)

• Bekreftelse

• Kvittering

• Signering med BankID

• Pausepunkt (2 sider)

• Endepunkt

Open

I tillegg kan valg av BankID-autentisering og Fortsett senere-funksjonalitet (både i startpunkt og pausepunkt) lede til 3 ekstra synlige sider. (Valg av Azure, ID-porten og Vipps-autentisering sender deg til sider med eksisterende <title>-elementer, så disse trenger ikke tjeneste-utvikler å ta hensyn til.)

Open

Sidetitlene for alle disse (utenom skjemasider som tar titlene fra sidetitlene) kan endres i Språk-menyen i prosessbyggeren. I skjermbildet under vises titlene som brukes i <title>-elementet for sidene i validering-aktiviteten:

Open

Tekstene som brukes til å generere sidetitler er listet i tabellen under. Med kolonnen Plassering menes hvor du må trykke i panelet Velg nivå for oversettelse for å finne frem til teksten som definerer sidetittelen:

3.4.2 Tilgjengelighetserklæring

En tilgjengelighetserklæring er en oversikt over hvordan en virksomhet i offentlig sektor oppfyller kravene til Universell Utforming. Denne skal lenkes til i Compose-tjenesten, og anbefales å legges i bunnteksten med som en hyperlenke:

Open

 

Open

Uutilsynet har en oppskrift for hvordan en slik erklæring utformes: https://www.uutilsynet.no/tilgjengelighetserklaering/korleis-lage-tilgjengelegheitserklaering/1131. Dersom du er usikker på om du er pålagt å ha en tilgjengelighetserklæring, anbefaler vi deg å sjekke uutilsynets sider: https://www.uutilsynet.no/webdirektivet-wad/krav-om-tilgjengelegheitserklaering/267. Her er et utdrag fra siden om hvem som kravet treffer:

3.5 Navigasjonsmenyer

Per krav 2.4.5 skal sluttbrukere tilbys flere måter å navigere på i Compose-tjenester. De eneste relevante metodene for Compose-prosesser er dermed navigasjonsknapper og navigasjonsmenyer. Det er med andre ord pålagt å tilby enten en vertikal navigasjonsmeny eller en horisontal navigasjonsmeny i tillegg til navigasjonsknappene på bunnen av siden.

Open

Navigeringsmenyer som må tilbys i tjenester som har mer enn én skjemaside.

Open

Pass på å ikke skjule navigasjonsknappene i tjenester som består av mer enn én skjemaside.

Som en følge av bruken av navigasjonsmenyer gjelder et ytterligere krav som beskrevet i del-avsnittet under (3.5.1).

3.5.1 Knapp for å “hoppe til hovedinnholdet”

Krav 2.4.1 pålegger muligheten for tastaturbrukere til å “hoppe over” bolker med gjentagende innhold over flere sider. Den typen gjentagende innhold som er mest relevant for tjenester i Compose er navigasjonsmenyer. Compose-tjenester er som standard utstyrt med en såkalt “skip”-knapp. Den synliggjøres når du bruker tab til å navigere på en tjeneste-side med navigasjonsmenyer. Trykker man deretter Enter hopper fokuset forbi navigasjonsmenyene.

Open

Det er to ting du bør passe på mtp. denne knappen:

• Pass på at du ikke skjuler knappen med f.eks. banner i tjeneste-designet (skin-filen).

• Husk å oversette tittelen på knappen (Hopp til hovedinnholdet) i tjenester med flere språk. Tittelen finnes i Språk-menyen i prosessbyggeren under Generelle egenskaper.

Open

3.6 Språk

Når det gjelder språk er det kun to rutiner man må overholde når man bygger tjenester. Jfr. krav 3.1.1 og 3.1.2 må språket til sideinnholdet være angitt i koden. Ved å opprette språk i oversettelsesverktøyet i Compose, blir språkkoden automatisk angitt i koden (se veiledningene Språk i prosesser og Språk i skjema for fremgangsmåte). For å støtte kravet må tjenesteutvikler forholde seg til denne klassifiseringen av språk, og ikke blande flere språk i samme visning, da dette ikke vil bli plukket opp av koden.

3.7 Responsivt skjemainnhold

I skjemabyggeren har flere elementer funksjonalitet for å ha en statisk størrelse. Dette gjelder hovedsakelig størrelse på spørsmålstekster og svarfelt som kan overskrives gjennom egenskapene Velg bredde, Velg høyde etc. Disse egenskapene overskriver responsiviteten i disse feltene. Dersom lengdene som velges er for store, vil ikke tjenesten kunne overholde visse krav (blant annet 1.4.4 og 1.4.10) da feltene vil bevare sine størrelser når brukeren zoomer i tjenesten opp til 200% og 400%. Lengre statiske felter anbefales spesielt sterkt at unngås på tjenester som skal brukes på mobile flater. Statiske størrelser bør dermed være forbeholdt feltene som har korte svar, som f.eks. tallsvar/datoer. Dersom egenskapene skal brukes bør tjenesten testes på samtlige flater opp til 400% zoom for å sørge for at responsiviteten ikke opphører.

Ved å bruke egenskapene Velg bredde/Velg høyde får elementer statiske størrelser som kan bryte responsiviteten til tjenesten!

Open

4 Tjenester med juridiske forpliktelser

Dersom tjenesten som utvikles 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, så må tjenesten ha minst én av følgende prosessaktiviteter (jfr. 3.3.4):

• Validering

• Bekreftelse

Open

Dette kravet forebygger innsending av juridiske feil, men også datafeil dersom tjenesten inneholder valideringsaktiviteten sammen med god bruk av valideringer på svarfelt. Du kan også bruke begge aktiviteter i samme tjeneste.

Den samme regelen gjelder for tjenester som bistår brukere i å slette persondata. Før slettingen får brukeren krav om å bekrefte at de har som hensikt å slette informasjonen. I dette tilfellet anbefales det å ikke utelate Bekreftelse-aktiviteten som et steg i prosessen.

I flere juridiske tjenester eller prosesser som omhandler persondata kan det være pålagt å tilby en Avbryt-knapp i tjenesten. Denne brukerveiledningen illustrerer hvordan en slik knapp kan legges til en prosess: Avbryte prosess.

Ytterligere merknader

Inndataformål – Formålsindeksering av inndatafelter (jfr. 2.1-krav 1.3.5) har vært under utvikling, men er ikke aktivert i dagens Compose-generasjon (Compose 8). Neste generasjon av Compose er i utvikling (Compose 9). Der vil tjeneste-utvikler kunne tagge inndatafelter manuelt med en formåls-tagg, jfr. formåls-kravene i WCAG2.1 som tillater autofyll av nettleser. I tillegg vil et sofistikert utvalg av inndatafelter være tilgjengelige i Compose 9 med pre-definerte valideringer og formål. Dermed vil tjeneste-utvikler ha full frihet til å tillegge formål for inndatafelter.

Skjemaer med påberegnet inaktivitet i mer enn 30 minutter – I en aktiv skjemasesjon er det ingen tidsbegrensninger på utfylling. Av sikkerhetshensyn, og etter retningslinjer fra ID-porten, avbrytes skjemasesjonen automatisk dersom den er inaktiv i 30 minutter. Dermed får sluttbruker anledning til å forlenge tidsbegrensningen ved enhver aktiv handling i skjemasesjonen (jfr. krav 2.2.1). Tjeneste-bygger kan tilgjengeliggjøre muligheten til å mellomlagre skjemaet for å fortsette utfyllingsprosessen senere (se veiledningen Fortsett senere).

Open

Dette gjøres via en navigasjonsknapp i skjemaet i navigasjonsmenyen, som tjeneste-byggeren aktiverer i prosessbyggeren. Dersom tjeneste-bygger påberegner inaktivitet i skjemaet i mer enn 30 minutter, er det opp til tjeneste-bygger å enten tilby mellomlagrings-funksjonen og/eller bistå med oppklarende informasjon om tidsbegrensningene i tjenesten. Da vil kravet være oppfylt.