Recommended
More Related Content
Similar to WCAG 2.1 for you and me
Similar to WCAG 2.1 for you and me (20)
More from Vegard Haugstvedt
More from Vegard Haugstvedt (6)
Recently uploaded
Recently uploaded (20)
WCAG 2.1 for you and me
- 1. WCAG 2.1 for you and me – 17 new requirements for inclusive design
- 3. WCAG 2.0 December 2008 First iPhone January 2007 WAD December 23rd 2016 Regulations for accessibility of ICT July 1st 2014 WCAG 2.1 June 2018 Existing ICT solutions January 1st 2020
- 4. New in WCAG 2.1 1.3.4 Orientation 1.3.5 Identify Input Purpose 1.3.6 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.3.3 Animation from Interactions 2.5.1 Pointer Gestures 2.5.2 Pointer Cancellation 2.5.3 Character Key Shortcuts 2.5.4 Label in Name 2.5.5 Target Size 2.5.6 Concurrent Input Mechanisms 2.5.7 Motion Actuation 2.6.2 Orientation 4.1.3 Status Messages
- 7. 1.3.5 Identify Input Purpose (AA)
- 9. 1.3.6 Identify Purpose (AAA)
- 10. <button type="button" itemprop="http://schema.org/SendAction" >Send</button> Buttons Purpose Schema.org Sign in http://schema.org/InteractAction/SignInAction Save http://schema.org/UpdateAction/SaveAction Next http://schema.org/MoveAction?ToLocation=Next Previous http://schema.org/MoveAction?ToLocation=Previous
- 12. 400% zoom
- 15. 1.4.11 Non-Text Contrast (AA)
- 19. 1.4.12 Text Spacing (AA)
- 20. • Line height: 1,5 * font size • Paragraphs: 2 * font size • Letters: 0,12 * font size • Words: 0,16 * font size Text spacing
- 22. 1.4.13 Content on Hover or Focus (AA)
- 27. Give the user more time!
- 28. Autosave
- 29. 2.3.3 Animation from Interactions (AAA)
- 32. Turn off
- 33. 2.5.1 Pointer Gestures (A)
- 36. 2.5.2 Pointer Cancellation (A)
- 37. Give the user the opportunity to cancel
- 38. 2.5.3 Character Key Shortcuts (A)
- 40. Turn off
- 41. Change
- 42. 2.5.4 Label in Name (A)
- 43. What you see = What you hear
- 44. Beware of icons in links and buttons!
- 45. 2.5.5 Target Size (AAA)
- 46. 44 px
- 47. 2.5.6 Concurrent Input Mechanisms (AAA)
- 49. 2.5.7 Motion Actuation (A)
- 51. Why choose? Support both modes!
- 52. 4.1.3 Status Messages (AA)
- 53. Status changes not in focus
- 54. What didn’t make it? ● Accessible Authentication ○ Password-free log in ● Interruptions (Minimum) ○ Turn off or pause popups, warnings, etc ● Target Size - (AA) ○ Integrated in Target Size (AAA) ● User Interface Component Contrast (Minimum) ○ Covered by Non-Text Contrast
- 56. What’s new in WAD? ● Accessibility declaration like for GDPR ● How to report accessibility errors ● Requesting an accessible version ● Intra- and extranet should be accessible ○ Internal workplace tools are still excluded ● NB! The exception (from WCAG 2.0) for audio description of pre-recorded media is removed
- 57. Current status The hearing-round for a proposal on how to include WAD in Norwegian law finished September 10th.
- 58. Current status The EU-directive only applies to public sector. Norway discusses three options: ● Model 1: Only apply to public sector ● Model 2a: Be expanded to apply for all ● Model 2b: Have an exception for companies with e.g. less than 50 employees
- 59. Current status WCAG 2.0/current law will remain as is Exceptions for visual interpretation will be removed
- 60. Current status New rules from July 1st 2020 Imposed from January 1st 2021 New rules from July 1st 2020 Imposed from January 1st 2021 Adoption of WAD in EEA (EØS) is postponed, pending discussion on longer transition period. Will be processed in Norwegian Parliament in fall 2020 at the earliest. There will at least be six months transition period, probably longer.
Editor's Notes
- C: [00:00]: 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.
- 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.
- C: Vi starter enkelt: Med mindre det er en spesiell grunn til det bør en app støtte både horisontal og vertikal visning.
- C:
- V: [01:30] Ligner på WCAG kravet om å spesifisere role, men fokuserer på “Hva brukes dette feltet til?” heller enn “Hva er det”? Kort og godt: fortell brukeren hvilken informasjon skal fylles inn Hvordan gjør vi dette på en god måte?
- Enkelt. Bruk autocomplete. I stedet for å huske og fylle ut samme informasjon mange ganger husker nettleseren hva som skal fylles inn og gjør det automatisk. Fordelene er mange: Mindre å huske, færre skrivefeil og mulighet for brukeren til å personalisere nettleseren med ikoner Brukeren kan bruke en nettleserutvidelse for å markere inputfelter med et ikon de kjenner igjen, slik at det er lettere for de å finne igjen og å forstå skjemafelter. Ved å markere passord og brukernavn felter riktig gjør du det mulig å bruke passordprogram som husker passordene for deg
- 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. 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.
- 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: The Norwegian news site VG is an example in how it’s not supposed to be. This is their site on my laptop with 100% zoom. As
- 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: Aids people with low vision and dyslexia Does not need to set these values as standard, just make sure the view doesn’t break Also increases likelihood that other styles may be overriden, like setting a wider font family.
- V: The two primary types of failures for this success criterion is text cut-off, ... And text overlap 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: [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 innholdet 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 kravet slår sammen de to første. Det er ment å skulle forhindre at innhold 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? Nyere eksempel: https://www.svt.se/special/sa-rostade-svenskarna/
- 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: [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.
- 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.
- 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
- 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? Difi annonserte on 18. september at EUs webdirektiv skal tas inn i norsk rett. Forslag til endriger i lov og forskrifter sendes ut på høring i høst, og det blir høringsmøte i november. Direktivet oppdateres i disse dager til å bruke WCAG 2.1, så dette blir en del av den norske lovgivningen.
- C: [35:00]