Næsten alle tilgængelighedsprogrammer vi gennemgår, rapporterer det samme tal: halvfems og nogle procent af frontend-udviklere siger de »tester med en skærmlæser«. Bed dem demonstrere, og demonstrationen er normalt de samme tre tastetryk — tænd den, tab igennem siden, sluk den. Det er ikke test. Det er fluebenet sættes.

Grunden til at det sker er strukturel, ikke doven. En skærmlæser er ikke et redskab man kan tage fat på, som man tager fat på en ny linter. Det er en anderledes interaktionsmodel med sin egen modale tilstand, sin egen genvejsgrammatik og et sæt konventioner der kun giver mening, når man har brugt den i adskillige timers reelt arbejde. Indtil man krydser den tærskel, fortæller redskabet én næsten ingenting — og hvad værre er, det fortæller én ting der er forkerte, fordi de annonceringer man hører afhænger af læserens tilstand, browserens tilgængelighedstræ og platformens IME-lag på måder der ikke er indlysende udefra.

Flydende beherskelse er for vores formål det punkt, hvor man kan få en kollega til at overdrage en defekt komponent, tage deres tastatur og genskabe fejlen med skærmlæseren kørende — uden at kigge på skærmen, uden at slå op i et snydeark og uden at gøre annonceringen værre end den ville være i reel brug. Kendskab er det punkt, hvor man har hørt en skærmlæser. Kløften mellem de to er ca. tredive til femogtredive timers målrettet øvelse.

Markedet har tre skærmlæsere der betyder noget for desktop-webarbejde: NVDA på Windows, VoiceOver på macOS og iOS, og JAWS på Windows. Hver har en brugerskare der er stor nok til at ignorere den ville være et reelt væddemål, og hver annoncerer den samme markup en smule anderledes. En flydende udviklere kan styre mindst to af dem.

Vores anbefaling, efter at have set snesevis af udviklere krydse tærsklen, er utvetydig: start med NVDA på Windows og VoiceOver på macOS. Begge er gratis. Begge er forudinstallerede (VoiceOver) eller kan installeres på under fem minutter (NVDA). Begge bruges af nok rigtige brugere — NVDA har approx. 65% af Windows-skærmlæsermarkedsandel i den seneste WebAIM-undersøgelse, VoiceOver dominerer mobil og en meningsfuld andel af macOS — at det, man lærer, umiddelbart overføres til fejl man kan sende en rettelse til. JAWS er det tredje redskab, ikke det første, selvom det stadig er skærmlæseren med den største virksomhedsinstallationsbase. Tre årsager.

De tre årsager til at springe JAWS over i starten er pædagogiske, ikke politiske. For det første deler JAWS og NVDA en mental model — Windows browse-tilstand kontra fokus-tilstand, det samme Insert-baserede kommandepræfiks, den samme virtuelle buffer — så når man kan styre NVDA, er halvfems procent af de JAWS-kommandoer man faktisk har brug for, et opslagsværk væk. For det andet har JAWS akkumuleret årtiers »smart« inferens: den forsøger at rette dårlig markup inden brugeren hører den, hvilket betyder at en fejl JAWS skjuler stadig leveres til NVDA-brugere. NVDA’s bevidst konservative adfærd gør den til den bedre referencelæser, når man forsøger at lære hvad der er defekt. For det tredje er JAWS’s licensfriktion — aktivering, den fyrretyve-minutters prøvetilstand der nagger ved hver genstart — en læringsafgift man ikke behøver betale, før man er sikker nok til at bruge den.

VoiceOver parres med NVDA frem for at konkurrere med den, fordi de to læsere repræsenterer de to dominerende interaktionsmodeller. NVDA (og JAWS) bruger »PC-markør«-modellen: en virtuel buffer der lægger siden ud som et lineært dokument og et separat fokus der følger tabrækkefølgen. VoiceOver bruger en enkelt VoiceOver-markør der ligger oven på fokus, navigeret via rotoren og VO+piletasterne. En udvikler der kun er flydende i én model vil skrive kode der annoncerer godt i deres læser og dårligt i den anden. At lære begge på én gang er den eneste pålidelige måde at mærke forskellen på.

Uge et-programmet har én regel: sluk skærmen. Ikke dæmpet, ikke minimeret, ikke »jeg lukker øjnene« — fysisk slukket, eller dækket med et stykke karton hvis din skærm er den eneste i rummet. Pointen er at fjerne muligheden for at snyde. En seende udviklers instinkt, i det øjeblik en skærmlæser siger noget forvirrende, er at kaste et blik på skærmen og løse flertydigheden visuelt. Det instinkt er den største enkeltårsag til at »jeg testede med en skærmlæser« ikke fanger rigtige fejl.

Planlæg tre sessioner på ca. halvanden time i uge et med mindst en dag imellem, så muskelhukommelsen har tid til at konsolidere. Hver session har ét job. Den første opbygger den grundlæggende kommandegrammatik. Den anden tvinger en reel interaktion. Den tredje tester fastholdelseunder en lille mængde pres.

Den anden til fjerde uge med øvelse bør tilsammen udgøre ca. tyve timers arbejde — to halvandentimers-sessioner om ugen plus en lille mængde tilfældig brug mens man laver sit daglige arbejde. Målet i dette forløb er at internalisere de to ting der forvirrer nye skærmlæserbrugere mere end alt andet: skelnet mellem browse-tilstand og fokus-tilstand, og forskellen på hvad rotoren ser og hvad tabrækkefølgen ser.

Den mest almindelige forvirring i uge to er det øjeblik, en udvikler trykker en piletast i NVDA, forventer at den virtuelle buffer bevæger sig, og i stedet hører den fokuserede combobox åbne sin optionsliste. Det er browse-tilstanden der automatisk skifter til fokus-tilstand, fordi fokus landede på et element som NVDA klassificerer som en »applikations«-widget. Nye udviklere oplever dette som om læseren opfører sig forkert. Det gør den ikke — den gør præcis det specifikationen beder om. Når man har hørt det ti eller femten gange, holder man op med at blive overrasket; indtil da bør man planlægge at blive overrasket ca. annenhver session.

Uge-tre-mønsteret er formularer. Byg en privat testside med otte til ti kontrolelementer: et påkrævet tekstfelt med en inline-fejl, en datovælger, en flervalgs-liste, et brugerdefinerets afkrydsningsfelt, en deaktiveret knap der aktiveres, et »vis adgangskode«-skift, et telefonnummerfelt med en landekode-vælger og en indsend-knap der udløser en serverside-valideringsopsummering. Skærm slukket, naviger gennem den fem gange — først med NVDA i browse-tilstand, derefter NVDA i fokus-tilstand, derefter NVDA igen med den udvidede annonceringindstilling slået til (Insert+Z, mere om det i afsnit fem), derefter VoiceOver med rotoren, derefter VoiceOver uden rotoren. Den samme formular vil lyde forskelligt fem gange. Det er hvad flydende beherskelse føles som indefra: at bemærke at den samme markup fortæller fem forskellige historier og at kunne forudsige på forhånd hvilken der vil spille.

Uge fire er navigation. Tag et rigtigt, komplekst site — en dokumentationsportal, et arbejdsplads-dashboard, en e-handelskategoriside — og forsøg at finde et bestemt stykke information udelukkende ved hjælp af skærmlæsergenveje. Brug H til at hoppe overskrifter. Brug D (NVDA) eller VO+U og derefter »Landmarks« (VoiceOver) til at hoppe landmarks. Brug 1 til 6 til at hoppe til et bestemt overskriftsniveau. Inden udgangen af uge fire bør navigationsgenvejene være reflekser snarere end valg, på den måde Tab og Shift+Tab allerede er.

Når brugertilstandskommandoerne er reflekser, er næste spring ind i de udviklerfokuserede overflader på hver læser. Det er de tilstande og genveje manualer begrave — dels fordi de er rettet mod udviklere, dels fordi de er støjende nok til at en dagligdagsbruger ikke ville have dem tændt. Tre er værd at kende med det samme.

To yderligere vaner vil spare mere tid end enhver enkelt genvej. For det første: hold NVDA’s talevisning fastgjort på en anden skærm (eller i et hjørne af din ene skærm) mens du udvikler. Den ordrette log over enhver annoncering er til skærmlæserarbejde, hvad dev-tools-konsollen er til JavaScript: forskellen mellem at gætte og vide. For det andet: lær at læse tilgængelighedstræet i din browsers dev-tools — Chromes Accessibility-rude, Firefoxs Accessibility Inspector, Safaris Audit-fane. Læseren annoncerer hvad tilgængelighedstræet indeholder, ikke hvad DOM’en indeholder, og de to afviger ofte nok til at man ikke kan fejlsøge live-regioner, ARIA eller shadow DOM uden at læse træet direkte.

En forvirring der er værd at markere nu, fordi den æder timer i uge to og tre: læsetilstand kontra fokus-tilstand er ikke den samme akse som »siden er interaktiv« kontra »siden er et dokument«. NVDA skifter automatisk til fokus-tilstand når fokus lander på et kontrolelement med role=“application”, eller på et contenteditable, eller på visse brugerdefinerede widgets som læseren heuristisk klassificerer som interaktive — uanset om siden er mest statisk. Omvendt vil en meget interaktiv enkeltsidet applikation hvis rodelement er et main-landmark og hvis widgets er velmarkeret native-knapper, forblive i browse-tilstand for næsten al en brugers session. Tilstanden er en egenskab ved det fokuserede element, ikke en egenskab ved siden.

Tallene nedenfor stammer fra uformel sporing af ca. firs udviklere — frontend-ingeniører, QA-leads, tilgængelighedsspecialister under oplæring — over tre år med virksomhedsworkshops og en-til-en-mentoring. De er ikke et forskningsstudie. De er gode nok til at planlægge efter. To antagelser: målrettet øvelse (skærm slukket, rigtige opgaver, ikke »jeg havde NVDA kørende i baggrunden mens jeg kodede«), og et fast læserpar (NVDA på Windows og VoiceOver på macOS).

»Semi-flydende« er det realistiske mål for de fleste seende udviklere og er i praktisk forstand alt hvad man har brug for at være en god bidragyder til et tilgængeligt produkt. Ægte flydende beherskelse — det niveau hvorfra man plausibelt kunne erstatte en daglig skærmlæserbruger under en brugbarhedsgennemgang — er mere som halvanden hundred timer og et år med tilfældig øvelse, og de fleste erhvervsaktive udviklere har ikke brug for det. Sigt efter semi-flydende, planlæg de fyrre timer og accepter at alt udover det kommer af at gøre dagligdagsarbejdet med en læser kørende og en vilje til at sætte farten ned.

Ét sidste benchmark til at sætte forventningerne ærligt: de udviklere der plateau’er, plateau’er efter vores erfaring mellem ti-times og tyve-times mærket. Årsagen er næsten altid den samme — de holder op med at slukke skærmen. De fortæller sig selv at de nu er »gode nok« til at teste med skærmen tændt, skærmlæseren kørende i baggrunden og visuel bekræftelse tilgængelig, når lyden er tvetydig. Det er de ikke. De seksten timer mellem »nyttig« og »tryg« kræver skærmen slukket, fordi det er det forløb, hvor læserens annonceringstagninger bliver information frem for støj. Uden det pres vender hjernen tilbage til synet og læserens stemme toner ud i baggrundsstøj. Hvis man langsomt ned, er det næsten altid skærmen.

Grunden til at »test med en skærmlæser« giver så svage resultater på tværs af branchen er ikke at redskabet er svært at lære — fyrre timer er genuint ikke lang tid — men at læringen er ubehagelig på en specifik måde. At slukke skærmen får en seende udvikler til at føle sig udygtig på en måde der er usædvanlig i vores profession. Vi er vant til at være dem der finder ud af tingene; skærmlæseren gør os i nogle timer ad gangen til begyndere igen. Det ubehag, og ikke tastetrykkene, er den reelle hindring.

Vejen igennem er den ovenfor: NVDA og VoiceOver, tre sessioner i den første uge med skærmen slukket, formularer og tilstande i uge to til fire, udviklertilstandsgenveje så snart brugertilstandsgenvejene er reflekser, fyrre timer i alt inden man kan betros en seriøs for-release-gennemgang. Intet af det er nyt. Det arbejde branchen ikke har gjort er at behandle det som arbejde — at planlægge timerne, forsvare dem mod andre forpligtelser og acceptere at de første ti af disse timer vil føles nytteløse, indtil de pludselig ikke gør det.

Hvis man leverer et frontend, er udgaven af en selv på den anden side af disse fyrre timer en markant bedre ingeniør end den udgave der startede, på måder der vil vise sig ikke kun i tilgængelighedsarbejdet men i forståelsen af fokusrækkefølge, af progressiv udvidelse, af hvad browseren faktisk gør under motorhjelmen. Skærmlæseren er den billigste distribuerede systemlektion tilgængelig for alle der skriver til nettet. Prisen er skærmen slukket og et par weekender.