WCAG 2.2, for produktledere

Hva WCAG 2.2 legger til i 2.1, forklart enkelt, med W3C-kilden lenket for hvert faktum om retningslinjene. Ikke juridisk rådgivning, og ikke noe løfte om samsvar.

Av Zefana · · Essay

Fire grupper av suksesskriteriene som WCAG 2.2 legger til WCAG 2.1. Fokus forblir synlig: 2.4.11 Focus Not Obscured (Minimum), nivå AA, med 2.4.12 Focus Not Obscured (Enhanced) og 2.4.13 Focus Appearance på nivå AAA. Mål du kan treffe: 2.5.7 Dragging Movements og 2.5.8 Target Size (Minimum), begge nivå AA. Spurt om bare én gang: 3.2.6 Consistent Help og 3.3.7 Redundant Entry, begge nivå A. Innlogging uten gåte: 3.3.8 Accessible Authentication (Minimum), nivå AA, med 3.3.9 Accessible Authentication (Enhanced) på nivå AAA. Under gruppene: 4.1.1 Parsing er foreldet og fjernet.

  • WCAG 2.2 legger til ni suksesskriterier i WCAG 2.1 og fjerner ett, ifølge W3C.
  • Seks av de ni er på nivå A eller AA. Enkelt sagt krever de fokus som forblir synlig, mål du kan treffe, informasjon du bare gir én gang, og innlogging uten gåter.
  • De havner der folk får ting gjort: når de beveger seg gjennom en side, logger inn, fyller ut et skjema eller får hjelp.

Retningslinjene for tilgjengelig webinnhold (Web Content Accessibility Guidelines) er W3Cs standard for å gjøre webinnhold brukbart for personer med funksjonsnedsettelser. Versjon 2.2 ble en W3C-anbefaling 5. oktober 2023. Hvis teamet ditt allerede arbeider etter 2.1, gjelder det meste av det du vet, fortsatt. De nye delene er få i antall og treffer presist der de havner.

Ingenting nedenfor er juridisk rådgivning, og ingenting her sier om produktet ditt oppfyller noen versjon. Den vurderingen hører til deg og rådgiverne dine. Hvis en lov, en kontrakt eller et anbud nevner en versjon av WCAG, les selve teksten for å se hvilken. Det som følger, er hva W3Cs egne sider sier, forklart enkelt, med lenken ved siden av hvert faktum.

Hva som endret seg fra 2.1 til 2.2

Ni kriterier ble lagt til, og ett ble tatt bort.

W3C-siden What’s New in WCAG 2.2 lister opp tilleggene. To er på nivå A: 3.2.6 Consistent Help og 3.3.7 Redundant Entry. Fire er på nivå AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum) og 3.3.8 Accessible Authentication (Minimum). Tre er på nivå AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance og 3.3.9 Accessible Authentication (Enhanced).

Det som er fjernet, er 4.1.1 Parsing, som W3C merker som foreldet i 2.2. De andre suksesskriteriene i 2.1 føres videre i 2.2-anbefalingen.

Fokus som forblir synlig

En person som beveger seg gjennom produktet ditt med tastatur, må kunne se hvor de er.

Etter 2.4.11 Focus Not Obscured (Minimum) skal en komponent som får tastaturfokus, ikke være helt skjult av innhold som forfatteren har laget. Tenk på en fast topptekst, en chatknapp eller et banner om informasjonskapsler som ligger over feltet en person nettopp har tabbet seg til. På nivå AAA krever 2.4.12 at ingen del av komponenten med fokus er skjult, og 2.4.13 Focus Appearance setter en størrelse og en kontrast for selve fokusindikatoren.

For en produktleder er dette lett å ødelegge uten å merke det. Elementene som dekker fokus, legges ofte til av gode grunner, av folk som aldri tester med tastatur.

Mål du kan treffe

Knapper og lenker må være store nok, eller ligge langt nok fra hverandre, for folk som ikke kan peke presist.

2.5.8 Target Size (Minimum) krever at mål for pekerinndata er minst 24 ganger 24 CSS-piksler. Det lister opp unntak, blant dem et mindre mål med nok plass rundt seg, et mål inne i en tekstsetning, og tilfeller der størrelsen er nødvendig.

2.5.7 Dragging Movements krever at alt en person kan gjøre ved å dra, også kan gjøres med én enkelt peker uten å dra, med mindre det å dra er nødvendig. Et kort som flyttes på en tavle, en glidebryter eller en liste som sorteres om, trenger hver sin andre måte å nå det samme resultatet på.

Informasjon du bare gir én gang

Folk skal ikke måtte skrive det samme to ganger i samme prosess, eller lete etter hjelp.

3.3.7 Redundant Entry krever at informasjon en person allerede har lagt inn eller fått oppgitt, og som trengs igjen i samme prosess, enten fylles ut for dem eller er tilgjengelig å velge. Unntakene er ny inntasting som er nødvendig, ny inntasting som trengs av sikkerhetshensyn, og informasjon som ikke lenger er gyldig. En leveringsadresse som må skrives inn på nytt som fakturaadresse, er det kjente eksempelet.

3.2.6 Consistent Help krever at der et sett med sider gjentar en måte å få hjelp på, som kontaktopplysninger, et kontaktskjema, en selvhjelpsside eller et helautomatisk kontaktvalg, står den i samme rekkefølge i forhold til resten av siden hver gang, med mindre personen selv endrer det.

Innlogging uten gåter

Å komme inn på en konto skal ikke avhenge av hukommelse eller av å løse noe.

3.3.8 Accessible Authentication (Minimum) krever at ingen trinn i innloggingen forutsetter en kognitiv funksjonstest, som å huske et passord eller løse en gåte, med mindre trinnet tilbyr et alternativ, en mekanisme som hjelper personen å fullføre det, eller testen handler om å kjenne igjen objekter eller ikke-tekstlig innhold personen selv har lagt inn. Å la en passordbehandler fylle ut feltet, eller å la folk lime inn, er den typen hjelp W3Cs Understanding-side for 3.3.8 beskriver. På nivå AAA fjerner 3.3.9 unntakene for gjenkjenning av objekter og personlig innhold.

Hvorfor dette hører hjemme på produktlederens bord

Disse kriteriene ligger der produktet ditt gjør seg fortjent til plassen sin. Innlogging, skjemaer, betaling og kundestøtte er reisene som avgjør om noen blir kunde og forblir det. Når en av dem svikter en person, er tapet reelt, enten noen skriver en rapport om det eller ikke.

Gå gjennom de fire reisene selv. Logg inn, fyll ut et langt skjema, let etter hjelp og fullfør et kjøp, først bare med tastatur og deretter med en telefon. Du lærer mer om hvor du står, enn noe sammendrag kan fortelle deg.

Bestem hvilken versjon og hvilket nivå dere arbeider etter, og skriv det ned. Uansett hva du velger, lar et uttalt mål teamet ditt si ja eller nei til et design før det bygges. Hvis en forpliktelse utenfor selskapet nevner en versjon, ta det spørsmålet med rådgiverne dine.

Legg de nye kriteriene til i det som betyr ferdig. En fokusindikator som forblir synlig og mål i brukbar størrelse er billige å få riktig i en ny funksjon og tungvinte å rette opp i et helt produkt senere.

Følg med på det som legges oppå. Bannere, chatknapper og faste linjer kommer fra mange team. Gi noen jobben med å sjekke dem mot fokus og målstørrelse.

Avgjør dette én gang, og du kan løfte blikket tilbake til menneskene produktet ditt er til for.

For hva det europeiske tilgjengelighetsdirektivet krever av digitale tjenester, les Det europeiske tilgjengelighetsdirektivet, for produktledere. Dette essayet holder seg til retningslinjene.

Der vi kommer inn

Vi gir ikke juridisk rådgivning, vi lover ikke at produktet ditt vil oppfylle noen versjon eller noe nivå, og vi sier ikke når det vil være klart. Vårt eget nettsted holdes til en tidligere versjon, og vi sier nøyaktig hvilken: Dette nettstedet holdes til WCAG 2.1 nivå AA på hver side.

På produktet ditt kan vi ta på oss tilgjengelighetsarbeidet du velger. Arbeidet havner i ditt eget kodelager. Koden vi bygger for deg, er din. Du bestemmer hva som leveres. Ingenting når brukerne dine uten din godkjenning.

Det starter med en samtale, helt uforpliktende. Hvordan det arbeidet ser ut, står beskrevet i Make your product accessible (på engelsk).

Kryss av det ditt eget produkt allerede gjør: egensjekken av tilgjengelighet

Les videre

Mer om dette temaet: Tilgjengelighet

Alle skriverier

Løft blikket og la oss bære resten.

Snakk med oss og se hvordan det er å få produktet sitt båret framover.

Book en samtale

Foretrekker du å skrive direkte? contact@zefana.com