Recommended
More Related Content
More from Vegard Haugstvedt
More from Vegard Haugstvedt (6)
Recently uploaded
Recently uploaded (20)
WCAG 2.1 for deg og meg – 17 nye krav til Universell Utforming
- 1. WCAG 2.1 for deg og meg – 21 nye krav til Universell Utforming
- 2. WCAG 2.1 for deg og meg – 17 nye krav til Universell Utforming
- 4. WCAG 2.0 Desember 2008 Første iPhone Januar 2007 WCAG 2.1 Juni 2018
- 5. Nytt i WCAG 2.1 1.3.4 Identify Common Purpose 1.3.5 Identify Purpose 1.4.10 Reflow 1.4.11 Non-Text Contrast 1.4.12 Text Spacing 1.4.13 Content on Hover or Focus 2.2.6 Timeouts 2.2.7 Animation from Interactions 2.4.11 Character Key Shortcuts 2.4.12 Label in Name 2.5.1 Pointer Gestures 2.5.2 Pointer Cancellation 2.5.3 Target Size 2.5.4 Concurrent Input Mechanisms 2.6.1 Motion Actuation 2.6.2 Orientation 3.2.6 Status Changes
- 6. 1.3.4 Identify Common Purpose
- 7. Felter ARIA (AUI Module) Autocomplete Description streetAddress street-address full street address condensed into one line city city locality or city area area administrative area, state, province, or region postalcode postal-code postal or ZIP code country country country name
- 8. Knapper ARIA (AUI Module) Schema.org Description signin http://schema.org/InteractAct ion/SignInAction sign in to current web site or application save http://schema.org/UpdateActi on/SaveAction save the current content next (aui-action) http://schema.org/MoveActio n?ToLocation=Next move to the next item in the series previous (aui-action) http://schema.org/MoveActio n?ToLocation=Previous move to the previous item in the series
- 9. 1.3.4 Identify Common Purpose Autocomplete for felter Schema.org for knapper
- 10. 1.3.4 Identify Common Purpose Fra dette: Telefon Lagre
- 11. 1.3.4 Identify Common Purpose Til dette: 22222222Telefon Lagre Ctrl + S
- 13. 1.3.5 Identify Purpose <span aria-numberfree="nesten alle">9 av 10 </span> <span aria-literal=”det regner mye”>det bøtter ned</span>
- 14. 1.4.10 Reflow
- 15. 400% zoom
- 23. 1.4.12 Text Spacing • Linjeavstand: 1,5 * fontstørrelsen • Avsnitt: 2 * fontstørrelsen • Tegnavstand: 0,12 * fontstørrelsen • Ordavstand: 0,16 * fontstørrelsen
- 26. 1.4.13 Content on Hover or Focus
- 30. 2.2.6 Timeouts
- 31. Tilby mer tid!
- 32. Autolagring
- 33. 2.2.7 Animation from Interactions
- 36. Slå av
- 37. 2.4.11 Character Key Shortcuts
- 39. Skru av
- 40. Endre
- 41. 2.4.12 Label in Name
- 42. Det du ser = Det du hører
- 47. Gi brukeren mulighet til å angre
- 49. 44 px
- 50. 2.5.4 Concurrent Input Mechanisms
- 54. Ja takk, begge deler!
- 59. Hva forsvant? ● Accessible Authentication ○ Passordfri innlogging. ● Interruptions (Minimum) ○ Mulighet for å pause eller skru av forstyrrelser som popups, varsler, o.l. ● Target Size - Enhanced (AAA) ○ Erstattet av Target Size (AAA) (med unntak) ● User Interface Component Contrast (Minimum) ○ Slått sammen med Non-Text Contrast
- 60. EN 301 549
- 61. Nytt i WCAG 2.1 1.3.4 Identify Common Purpose 1.3.5 Identify Purpose 1.4.10 Reflow 1.4.11 Non-Text Contrast 1.4.12 Text Spacing 1.4.13 Content on Hover or Focus 2.2.6 Timeouts 2.2.7 Animation from Interactions 2.4.11 Character Key Shortcuts 2.4.12 Label in Name 2.5.1 Pointer Gestures 2.5.2 Pointer Cancellation 2.5.3 Target Size 2.5.4 Concurrent Input Mechanisms 2.6.1 Motion Actuation 2.6.2 Orientation 3.2.6 Status Changes
Editor's Notes
- C: [00:00]Da vi sendte inn denne presntasjonen valgte vi tittelen WCAG2.1 - 21 nye krav til universell utforming.
- C: I tiden mellom vi sendte inn og nå er fire krav borte. Det oppdaterte navnet på presentasjonen er dermed WCAG 2.1 - 17 nye krav til universell utforming. Holder vi presentasjonen i høst er det en risiko for at tallet ville vært enda litt lavere.
- C: Så hva er WCAG 2.1? WCAG 2.0 er en standard med retningslinjer for tilgjengelig webinnhold. WCAG 2.1 er en oppdatert versjon av denne standarden som inneholder alle retningslinjene fra 2.0 pluss de nye vi skal gå gjennom i dag.
- V: [01:30] “Hva gjør det?” heller enn “Hva er det”? Gjelder for knapper, lenker og inputfelter - bruker standardiserte roller og funksjoner for å beskrive formålet med elementet. Hvilken informasjon skal fylles inn, hva gjør denne knappen, etc. Felles formål. Mer informasjon om knapper og felt gjør det mulig for brukere å tilpasse nettleseren. Personalisering. Autocomplete.
- V: Noen eksempler kan være i et registreringsskjema, så kan man bruke autocomplete eller AUI-standarden for å angi at et felt skal fylles ut med gateadressen, bynavn, postnummer eller land.
- V: Tilsvarende skal knapper markeres for å vise om de er en lagre-knapp, innloggingsknapp, eller en neste- eller forrige-knapp. Disse vil typisk markeres med referanser til schema.org-skjemaer.
- V: Kort oppsummert vil man altså bruke autocomplete-attributtet for inputfelter, og schema.org for knapper og lenker.
- V: Slik markering kan bidra til flere forbedringer for brukeren - og både for brukere med funksjonsnedsettelser og alle oss andre.
- V: For eksempel kan et inputfelt automatisk fylles ut, med større sikkerhet enn i dag. Eventuelt kan brukeren bruke en nettleserutvidelse for å markere inputfelter med et ikon de kjenner igjen, slik at det er lettere for de å finne igjen og å forstå skjemafelter. Markering av knapper og lenker vil også kunne la brukeren ha tilpassede hurtigtaster, enten gjennom skjermleser eller f.eks. nettleserutvidelser.
- V: [04:00] Identify purpose er et AAA-krav, som altså normalt ikke er inkludert i norsk lov.
- V: Kort fortalt bygger dette kravet på det forrige, og inkluderer i tillegg symboler, regioner med mer. Målet er ytterligere personalisering, ved for eksempel å kunne bytte ut ikonsett med sine egne, forenkle språket, osv. Som vi ser over kan man for eksempel bytte ut det matematiske uttrykket “9 av 10” med et litt mindre nøyaktig uttrykk som “nesten alle”. For en del brukere vil det gjøre innholdet lettere å forstå.
- C: [05:00] Punkt 1.4.10 er Reflow. Zoom, eller omorganisering på godt norsk.
- Mer nøyaktig: 400% zoom. Det er så mye du skal kunne forstørre en nettside uten at du ender opp med to rullefelt. Responsiv design er løsningen her.
- C: VG sin nettside er et eksempel på hvordan du ikke skal gjøre dette. Dette skjermbildet er fra laptopen min. Allerede uten å zoome må jeg bruke scrollbaren på bunnen av siden for å se alt innholdet
- C: Dagbladet har gjort en mye bedre jobb med responsiv design. Her kan du fint zoome inn både
- C: [07:00] 1.4.11 går på fargekontrast på ikke-tekstlige elementer. WCAG 2.0 dekker allerede fargekontrast på tekst.
- C: Fargekontrast er et av WCAG-kravene som burde være lette å dekke. Likevel syndes det stadig. Her er Google sitt hjelpeforum.
- C: All teksten som er markert bryter med kontrastkravene i WCAG 2.0
- C: I WCAG 2.1 kommer det også krav til brukergrensesnittkomponentene.
- V: [09:00] Avstanden mellom avsnitt, linjer, ord og tegn skal kunne økes uten at innhold skjules.
- V: Her har man basert seg på noen standarder
- V: Et typisk eksempel er er tekst som flyter bak bilder, kuttes i skjermkanten eller at høyden på containeren er fast, og innholdet dermed går over for mange linjer.
- V: I stedet er det bedre om teksten bryter over flere linjer og wrappes rundt bildet.
- V: [10:00] Dette kravet gjelder for nedtrekksmenyer, tooltips og lignende som vises ved hover eller fokus. Det gjelder da tre prinsipper:
- V: I tilfeller som her hos Ebay vil man ved å flytte musen nedover fra toppen trigge menyen, og den fjernes ikke før musen er flyttet helt ned til under menyen. Første krav her er da at innholdet skal kunne fjernes uten å flytte musen. En standard løsning for dette er å kunne trykke Escape.
- V: Brukeren skal kunne flytte musepekeren over til innholded som vises ved hover, uten at dette forsvinner. Det kan f.eks. være et problem for tooltips, da disse ofte er plassert litt unna knappen/lenken/inputfeltet, slik at du ikke lenger hovrer når du flytter musen mot tooltipen.
- V: Til slutt skal innholdet vises frem til brukeren fjerner fokus eller hover. Dette er ment å skulle forhindre at det f.eks. har en timer for hvor lenge det kan vises.
- V: [12:00] Suksesskriterie 2.2.6 går på at brukeren skal få nok tid til å utføre oppgaven sin.
- V: Kort fortalt sier dette kravet at brukeren skal få spørsmål om han eller hun trenger mer tid, slik at de ikke timer ut.
- V: Kravet om å tilby mer tid faller bort dersom innholdet brukeren har lagt inn automatisk mellomlagres i minst 20 timer. Her er det viktig å tenke på GDPR, da det i mange tilfeller ikke er lovlig å mellomlagre dataene, og i hvert fall ikke uten tillatelse. Å gi brukeren mulighet til å be om mer tid er derfor den beste løsningen. Til Yggdrasil? Dette kravet kan eksemplifiseres med et eksempel fra et forsikringsselskap jeg har jobbet hos: En dag fikk vi melding fra en sint kunde som hadde brukt over en time på å fylle ut en helseerklæring. Vi hadde 75 punkter som måtte fylles ut HVIS kunden hadde noe å fylle ut der. Normalt ville dette tilsi at kunden fylte ut 3-5 punkter, men denne kunden måtte fylle ut nesten alle, og måtte lete opp masse informasjon underveis. Vi hadde 45 minutter timeout, og når kunden skulle sende inn skjemaet var han logget ut. På grunn av personvernloven (og nå GDPR) kunne vi ikke mellomlagre informasjonen, og siden kunden ikke fikk spørsmål om mer tid hadde han mistet alle dataene, og måtte fylle ut skjemaet på nytt. Naturlig nok mistet vi den kunden...
- C: [14:00] 2.2.7 Animasjon fra interaksjoner. WCAG 2.0 har allerede et krav om at brukeren skal kunne stoppe, pause eller skjule innhold som automatisk endrer seg. Dette kravet går på animasjoner som starter fordi du beveger musen eller scroller.
- C: Parallakse scrolling er et eksempel på animasjoner som starter når brukeren interagerer med siden. På websiden det er bilde av her brukes dette til å guide nedover siden. Enkelte norske nettaviser bruker samme effekt for å vise fram bilder underveis i artikler. Utfordringen med å dette er at enkelte sliter med migrene og svimmelhet forårsaket av animasjonene. Hvordan kan vi hjelpe?
- C: En løsning er å bruke css media query prefers-reduced-motion og lage et alternativ uten animasjoner for brukere som har satt opp at de ønsker det
- C: En annen løsning er å legge til en kontroll på toppen av siden der brukeren kan skru av animasjoner før de begynner å scrolle. Det er selvfølgelig også mulig å kombinere disse teknikkene.
- C: [16:00]
- C: Kravet gjelder hurtigtaster med en bokstav, ikke standard hurtigtaster som er styrt av operativsystemet slik som ctrl + c, eller eple + p. Hurtigtaster med en bokstav er effektivt for mange ekspertbrukere, men skaper store problemer for personer som bruker talestyring eller kommer borti tastaturet ved et uhell.
- C: For å unngå problemet kan du gi brukeren muligheten til å skru av hurtigtastene.
- C: En annen måte å løse problemet på er å la brukeren endre hurtigtastene.
- V: [18:00] For det neste kravet må jeg først forklare en liten detalj for tilgjengelighetsverktøy. Kort fortalt har HTML-elementer en visuell tekst eller label, som er teksten vi ser på nettsiden, samt et “navn”, som er teksten som leses opp av skjermlesere og lignende verktøy. Det tilgjengelige navnet kan påvirkes med bruk av alt-tekst i bilder, aria-label, med mer.
- V: Det dette kravet sier, er at det tilgjengelige navnet skal inneholde den visuelle teksten, gjerne i starten av navnet og helst skal de være lik. Dette påvirker både folk som kan se, men bruker skjermleser for å hjelpe seg med å oppfatte innholdet, men også kul, ny teknologi som stemmestyring. Det er mulig å navigere nettsider med talekommandoer. For eksempel kan man klikke på en knapp ved å si navnet til knappen. Da er det viktig at den visuelle teksten også er inkludert i det tilgjengelige navnet, slik at stemmestyringsverktøyet forstår hva den skal klikke på. Metoder som kan bryte dette kravet er feil bruk av aria-label, da denne fullstendig overstyrer navnet. Aria-describedby, derimot, inkluderer ekstra tekst i slutten av navnet, og oppfyller derimot kravet.
- C: [20:00]
- C: Alle sider som bruker komplekse bevegelser for å navigere skal også kunne navigeres med et enkelt trykk. Google maps har gjort dette halvveis. Du kan zoome ved å spre fingrene, men også ved å trykke på pluss og minus. Skulle de møtt hele kravet måtte de også hatt piler for å navigere kartet. Slik det er nå er eneste muligheten å dra kartet rundt med mus eller fingeren. Fordelen med å støtte er flersidig: du hjelper brukere som er ute av stand til å gjennomføre komplekse bevegelser grunnet funksjonsnedsettelser, du hjelper nybegynnere som ikke kan de komplekse bevegelsene og du hjelper personer med kognitive funksjonsnedsettelser som sliter med å huske de komplekse bevegelsene.
- C: DNB har gjort en god jobb her med å ha pluss og minus på hver side av slideren. Det er fire måter å justere beløpene på: du kan bruke pluss og minus, du kan dra slideren, du kan trykke på ønsket posisjon og du kan skrive inn tallet direkte.
- C: [22:00]
- C: No Down-Event The down-event of the pointer is not used to execute any part of the function; Abort or Undo Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or undo the function after completion; Up Reversal The up-event reverses any outcome of the preceding down-event; Essential Completing the function on the down-event is essential.
- V: [24:00] Dette kravet er enkelt, og er noe jeg og flere har krevd i prosjekter i flere år:
- V: Klikkflater skal være minimum 44 * 44 pixler. Så enkelt. Dette kreves for å hjelpe brukere med motoriske vansker, slik at det er lettere å trykke på for eksempel en knapp med fingeren eller en mus. Nå er dette kravet definert som AAA-nivå, som ikke er påkrevd ved norsk lov. Det er gjort fordi man ikke klarte å bli enige om fornuftige nok krav og unntak til at det kunne legges på AA-nivået. Men selv som AAA-krav har vi flere unntak her, for eksempel lenker inn i tekst, der funksjonaliteten er tilgjengelig et annet sted på siden som oppfyller kravet eller om størrelsen bestemmes av brukerens enhet.
- V: [25:30] Det neste kravet skal sikre at brukeren kan bruke siden med flere inputmetoder.
- V: Dette vil si at brukeren skal kunne bruke tastatur, touch, mus, stylus, eller tale, forutsatt at enheten støtter denne input-måten. I praksis vil dette si at JavaScript-applikasjoner ikke bare skal fungere med touch-, mus- eller tastaturevents. Feature-lytting eller media-queries for å finne primær-input er være røde flagg i denne sammenhengen.
- C: [27:00]
- C:
- C: Tilting? Risting? Bra, men ha et alternativ
- C: [29:00]
- C: Med mindre det er en spesiell grunn til det bør en app støtte både horisontal og vertikal visning.
- V: [31:00] Det siste nye kravet i WCAG 2.1 sier at hjelpeteknologi skal få beskjed om innhold som oppdateres dynamisk uten at fokus flyttes. For eksempel ved bruk av skjermlesere leses innholdet opp basert på hvor det virtuelle fokuset er på siden. For å oppfylle dette kravet må essensielle oppdateringer vises i elementer som er markert at kan oppdateres, slik at skjermleseren avbryter for å lese opp varsler. I praksis betyr dette bruk av aria-live, role=alert og lignende metoder.
- V: Men det er viktig at bare viktige statusendringer annonseres, og ikke alle endringer på siden. Eksempelet her viser filopplasting i OneDrive. Brukeren bryr seg nok ikke om hver fil som blir ferdig lastet opp, men ønsker typisk å få beskjed når hele opplastingen er ferdig. Viktig å vurdere hvor ofte endringene annonseres, og gi brukeren mulighet til å skru av varslingen. Dette kan gjøres for eksempel med aria-live=”polite”, som samler opp varsler eller venter til en pause, heller enn å avbryte midt i teksten.
- V: [32:30] Fire suksesskriterier ble altså fjernet til den nest siste versjonen av WCAG 2.1. Disse ble alle fjernet fordi man ikke klarte å bli enig om en utvetydig formulering eller hvilke unntak som skulle gjelde. Spesielt vil jeg bemerke Accessible Authentication, som ville kreve passordfri pålogging. Eksempler på det er Slack sin “magic link”, men kravet ville også være oppfylt med å ha en “glemt passord”-funksjon, som er hvordan overraskende mange brukere logger inn. I tillegg var det synd at Target Size ikke ble tatt med som et AA-krav, da det gjør at det ikke blir påkrevd gjennom norsk lov. Derimot er det et bra UX-prinsipp, som uanett bør følges.
- Hva med Norge? Vi har hørt med Difi og det mest sannsynlige er at lovgivningen i Norge går bort fra å referere til WCAG og i stedet refererer til EN 301 549 som igjen referer til WCAG. EU stiller kun krav til offentlige nettsteder og applikasjoner. Norge står fritt til å implementere en strengere versjon og kommer til å fortsette å stille krav til virksomheter i både offentlig og privat sektor, samt lag og organisasjoner
- C: [34:00]
- C: [35:00] Har neppe tid til spørsmål nå, men spør gjerne etterpå.