Redaktører rører til tilgjengeligheten
Og det er din feil når du setter opp forfatterverktøy. Her er konkrete grep for å bygge bedre, slik at du hjelper redaktører å gjøre det riktig fra start.
Ikke noe personlig mot verken deg eller folk som lager innhold. Når vi slipper redaktører løs i et grensesnitt som ikke hjelper dem å gjøre tilgjengelighet riktig, faller det hensynet ofte mellom to stoler. Redaktører har som alle andre dårlig tid, dårlige dager og mange oppgaver, og måles oftere på at de får noe ut enn at resultatet er godt tilgjengelig.
Heldigvis finnes det prinsipper og rammeverk som hjelper oss å hjelpe dem.
Redaktører ender alltid opp med å gjøre noe «kreativt».
Kjente problemer vi ser igjen og igjen
Kjenner du igjen noen av disse fra tjenester du har jobbet med?
Lenker som bare sier «les mer» eller «klikk her», uten å fortelle hvor du havner.
Fet skrift brukt som overskrift, fordi det ser likt ut visuelt.
Overskriftsnivåer som ikke følger et godt hierarki.
Bilder med innbakt tekst uten alternativer.
Videoer uten undertekster eller transkript.
Grafer og visualiseringer uten gode, tilgjengelige beskrivelser og alternativer.
Tekst med for dårlig kontrast mot bakgrunnen. For eksempel, men ikke alltid, over et bilde.
Dette kommer ikke av uvilje hos redaktører. Noen ganger kommer det av uvitenhet, og enda oftere kommer det av dårlig tid. Stort sett alltid er det fordi at verktøyet ikke lar dem gjøre det riktig på en enkel måte, eller ikke gir dem noe signal om at noe er galt eller utilstrekkelig.
Folkens, møt ATAG
ATAG står for Authoring Tool Accessibility Guidelines (w3.org). Det ligner litt på WCAG og er enda et sett med retningslinjer som W3C står bak, men er ikke lovfestet. ATAG gjelder forfatterverktøy, altså alle verktøy som brukes til å produsere innhold som noen andre skal bruke og forstå.
Det inkluderer CMS-er som Sanity, Craft og WordPress der redaktører publiserer til publikum, men også løsninger der brukere publiserer til andre brukere som sosiale medier, chat-funksjoner og kommentarfelt eller der brukere publiserer til saksbehandlere slik som søknadsskjemaer og systemer for innlevering av prøver.
ATAG har to hoveddeler:
- Forfatterverktøyet i seg selv skal være tilgjengelig.
Verktøyet følger tilgjengelighetskrav, tilsvarende WCAG (uutilsynet.no). - Støtte produksjon av tilgjengelig innhold.
Verktøyet hjelper redaktører aktivt med å gjøre det riktig.
Det er del to vi skal forholde oss til her.
Fire prinsipper for en god tilgjengelighetsfunksjon
ATAG gir oss fire gode prinsipper for funksjonene vi lager, for å støtte produksjon av tilgjengelig innhold:
- Funksjonen bør være en del av den naturlige flyten. Ikke noe redaktører må oppsøke aktivt.
- Den bør være fremtredende. Ikke gjemt bort i en «avansert» meny eller underpunkter.
- Den bør være skrudd på som standard. Ikke et tilvalg redaktører må aktivere.
- Det skal være varslet tydelig hvis den er deaktivert og den skal være lett å skru på igjen.
Så hva bør vi faktisk bygge?
Her er de mest konkrete tingene du kan gjøre, for de vanligste innholdstypene.
Rik tekst
Rik tekst-editoren må sørge for at innhold får riktige HTML-tagger i koden. For eksempel skal en overskrift bli en <h2>, ikke et avsnitt med fet skrift. Lister skal bli <ul> eller <ol>, ikke en linje som begynner med en bindestrek. Sitater skal bli <blockquote>, ikke en overskrift eller noe annet som ser pent og fremtredende ut som sitat.
Det høres åpenbart ut, men mange rik tekst-editorer gir redaktører visuelle kontroller som produserer feil HTML under panseret.
Bilder
Redaktører må kunne legge til alternativ tekst og det bør være et tydelig, obligatorisk felt (eller i det minste et felt med validering og tydelig forklaring på hva som bør stå der).
Et bilde kan ha en «generell» alt-tekst i mediebiblioteket, men konteksten avgjør. Gjør det mulig å overstyre eller bestemme alt-teksten der bildet brukes.
Og viktig: gjør det til et aktivt valg å markere et bilde som dekorativt (tomt alt-attributt). Ikke bare godkjenn innholdet hvis feltet står tomt.
Videoer
Videoer kan være komplekse, men de viktigste tilgjengelighetsfunksjonene er:
- Et felt for transkript. Feltet trenger ikke være programmatisk knyttet til selve videoen, men det må komme rett etter videoen. For eksempel en trekkspill-modul eller lignende. Transkript er det alternativet gir flest brukere tilgang til innholdet uavhengig av behovet de har, og kan erstatte flere av de andre alternativene, men det gir ofte en dårligere opplevelse.
- Undertekster til videoen.
- Alternative lydspor brukes blant annet til å tilby synstolkning.
- Alternative filmspor brukes blant annet til tegnspråk.
I eksempelet over er teksting påkrevd på videoen frem til redaktøren har huket av at videoen verken har tale eller tekst i bildet. Merk at vi også åpner for at redaktører kan lagre videoer med mangler, men da informerer vi om at dette gjør videoen utilgjengelig for noen brukere og gjør det lett å skru det på igjen.
Her åpner vi for unntak fordi redaktører kan ha behov for å publisere en sak så fort som mulig og det er bedre at unntakene gjøres under ordnede former enn at redaktører må omgå kravet med «hacks». Snarveier og hacks gjør det ofte vanskelig å finne tilbake til innholdet senere. Informasjonen fra disse sjekkboksene kan vi også bruke til å forbedre forfatterverktøyet med lister og visninger som gjør det lett å fikse senere. Det kommer jeg tilbake til.
Tabeller
Tabeller som er tilgjengelig for alle er ekte og tilbakevendende vanskelige å gjøre riktig og bra. Forfatterverktøyet må støtte:
- Et tabellnavn (<caption>). Hva handler tabellen om? Hva står i den?
- Tabellheadere med riktig scope. Er dette en kolonne-header eller rad-header?
- Responsiv visning på mobil. En bred tabell som scroller horisontalt er sjelden en god løsning.
Lenker
Lenketeksten skal gi mening selv uten konteksten rundt. «Klikk her» er aldri godt nok. Det er vanskelig å automatisere en kontroll for at en lenketekst er god nok, men det er mulig å legge til validering mot vanlige kombinasjoner som «Les mer», «Gå hit» og «Klikk her».
I tillegg bør det være tydelig for brukere om lenken:
- Åpner en ekstern side
- Åpner en ny fane
- Fører til nedlasting av en fil
Stort sett kan vil løse dette teknisk om lenken er «typet» som en intern-, ekstern- eller fil-lenke istedenfor at det kun et fritekst lenke-felt.
Designsystemet.no har gode anbefalinger for hvordan vi bør markere lenker.
Finn problemene som allerede er der
Selv med gode verktøy vil det finnes gammelt innhold med problemer. Her er to grep som hjelper.
Arbeidslister
Lag filtrerte utlistinger i CMS-et som viser redaktører hva som mangler:
- Bilder uten alt-tekst
- Videoer uten undertekster
- Sider med iFrames
- Datavisualisering uten vedlegg
Dette gir redaktører en konkret backlog, uten at de trenger å gå gjennom alt innholdet manuelt. Valgalternativer som jeg brukte i eksempelet med videoene, kommer veldig godt med når vi skal bestemme hva som skal vises i disse utlistingene.
Automatisk testing
Selv med gode verktøy og tydelige felt vil det alltid finnes innhold som er blitt publisert med feil. Da er det greit å ha noe som passer på automatisk.
Axe er motoren bak mange kjente verktøy for UU-testing, slik som Lighthouse, Accessibility Insights og Axe DevTools. Vi kan integrere axe-core (github.com) direkte i CMS-et uten å be redaktører installere nettleserutvidelser eller stoppe opp med det de holder på med for å teste.
Axe trenger bare et DOM å kjøre i. Mulige bruksområder:
- Sanity. Egne React-komponenter i Sanity-grensesnittet (sanity.io) eller Sanity Functions (sanity.io) + Puppeteer
- Craft CMS. Twig-templates i admin-grensesnittet (craftcms.com)
- Playwright-tester. @axe-core/playwright (npmjs.com)
Husk at automatiske tester kun tester 40% av kravene og fanger langt færre feil. De er et tillegg til, ikke en erstatning for, manuell testing.
Det beste er en løsning som faktisk finnes og faktisk brukes.
Glem å få til det perfekte resultat
Jeg skriver dette sist, men husk det aller først. Ikke bruk masse tid på å lage den perfekte løsningen. Gå for løsninger som faktisk funker og er realistiske å implementere i tjenesten du jobber med, og skipp ørkenvandringen mot noe som gjør alt perfekt for alle.
Noen ganger er det et enkelt påkrevd felt, som redaktørene ikke kan hoppe over. Det er ofte også helt greit å «hacke» til en løsning med de begrensningene du har, det beste er en løsning som faktisk finnes og faktisk brukes.
Lykke til. Du får det til!
