-
Notifications
You must be signed in to change notification settings - Fork 38
Accessibility (Draft)
This is a draft
What should this page contain?
- Our accessiblity statement
- Testing guidelines
- WCAG guidelines that are important in relation to a designsystem
The text below is from an analysis on what requirements we believe a design system will help the consumers uphold. Will be condenced and written in english
Many of the requirements that are repeated as violations in the accessibility statements are violations that a design system will minimize either directly through its components or through guidelines and tools.
Dette gjelder kun for komponentene våre. Når man tar i bruk designsystemet er det mye som må bli satt opp selv, og om man ikke har fokus på UU vil man fortsatt ikke gjøre produktet tilgjengelig selv om komponentene er det. Det er derfor viktig at vi skriver gode retningslinjer, har et samarbeid hvor man kan be om hjelp/sette fokus på tema og henvise til retningslinjene til UUTilsynet. Nedenfor vil jeg kun fokusere på komponentene og våre retningslinjer.
Vanlige feil i følge tilgjengelighetserklæringene 1.1.1 Tekstalternativ til Ikkje-tekstleg innhald 1.4.11 Kontrast for ikkje-tekstlig innhold 1.3.1 Informasjon og relasjonar 4.1.1 Parsing (oppdeling) 4.1.2 Namn, rolle, verdi 2.1.1 Alt innhald er tilgjengeleg med tastatur 2.4.7 Synleg fokus ved tastaturnavigasjon 1.4.3 Kontrast mellom tekst og bakgrunn
Dette er ikke en dyp analyse av hvilken krav et designsystem vil minimere antall feil på, det er mer et forsøk på belyse viktige krav vi vil ivareta i komponentene våre. Det er flere krav som ikke er nevnt her som vi også selvfølgelig vil teste å passe på at komponentene overholder.
1.1.1 Ikke-tekstlig innhold (Nivå A) Alle ikoner og bilder som er en del av våre komponenter vil inneholde alternative tekster.
Jeg tror ikke dette kravet vil bli løst med designsystemet. Bilder, ikoner og andre visuelle elementer vil bli brukt utenfor våre komponenter. Om disse problemene oppdages burde vi henvise til Tilsynets retningslinjer
1.3.1 Informasjon og relasjoner (Nivå A) Alle våre komponenter bruker semantisk HTML for å presentere informasjon. Dette er den beste måten for å gjøre innhold tilgjengelig for hjelpemidler. Om vi må bygge komponenter utenfor dette, vil vi bruke aria i henhold til dokumentasjonen. Få hjelp til å formulere denne
1.4.3 Kontrast (minimum, Nivå AA) og 1.4.11 Kontrast for ikke tekstlig innhold (Nivå AA) Vi har god nok kontrast mellom bakgrunn og tekst (og andre relevante elementer) i vår standard løsning. Vi vil legge opp til et system som skal ivareta dette når andre tar i bruk systemet og legger inn egne farger.
2.1.1 Tastatur (Nivå A) og 2.1.2 Ingen tastaturfelle (Nivå A) Vi tester at all funksjonalitet på komponenter er mulig ved hjelp av tastatur. På komponenter som ikke er basert på native HTML vil vi legge til rette for å følge spesifisering gjort av W3C for tastaturnavigasjon. W3C Patterns
2.4.1 Hoppe over blokker (Nivå A) Vi vil leverer en egen komponent som vil bruke fokusvisningen vår slik at knappen blir tydelig også visuelt.
2.4.3 Fokusrekkefølge (Nivå A) Rekkefølgen inne i våre komponenter vil bli testet slik at vi vet at rekkefølgen blir riktig.
2.4.7 Synlig fokus (Nivå AA) Vi har sammarbeidet med Brreg i å lage en fokusvisning som skal ha god synlighet uavhengig av bakgrunn. Denne skal også bestå 2.4.13:Focus Appearance (Level AAA) Som kan komme i WCAG 2.2
3.3.1 Identifikasjon av feil (Nivå A) Relevante komponenter har feilmelding som en del av komponenten. Hvordan det kan løses i en større skjemasammenheng burde være en del av dokumentasjonen/guidelines
3.3.2 Ledetekster eller instruksjoner (Nivå A) Ledetekster er en del av våre skjemakomponenter og blir vist direkte over feltet.
4.1.2 Navn, rolle, verdi (Nivå A) Alle våre komponenter har navn og rolle bestemt i koden. Der det er mulig vil vi bruke standard HTML, ellers vil vi bruke aria for å beskrive komponentene i henhold til dokumentasjonen.
Det vil være noen WCAG krav det vil være naturlig at vi skriver om i dokumentasjonen til komponentene. Vi må se på om det er nødvendig at vi skriver retningslinjer her eller om vi skal henvise til UUTilsynet.
1.3.5 Identifiser formål med inndata (Nivå AA) Ikke løst gjennom komponentene våre i seg selv, men vi vil opplyse om dette i retningslinjene for relevante komponenter.
2.4.4 Formål med lenke (i kontekst, Nivå A) Det vil være fornuftig for oss å legge inn info om dette i retningslinjene til lenke komponenten.
2.4.6 Overskrifter og ledetekster (Nivå AA) I sammenheng med at vi kommer til å tilby mye skjemakomponenter burde vi nok vurdere å lenke til retningslinjer for gode ledetekster. Enten om vi skriver en artikkel om dette eller lenker til UUTilsynets guider for dette
3.3.3 Forslag ved feil (Nivå AA) Naturlig del av mønster for feilmeldinger i skjema eller henvisning til UUTilsynets informasjon om dette.
Relevant: