Nästan varje tillgänglighetsprogram vi granskar rapporterar samma siffra: nittio-och-något procent av frontend-utvecklarna säger att de “testar med en skärmläsare.” Be dem visa, och demonstrationen är vanligtvis samma tre knapptryckningar — slå på, tabba igenom sidan, stäng av. Det är inte testning. Det är att bocka av en ruta.

Anledningen till att detta händer är strukturell, inte lat. En skärmläsare är inte ett verktyg man plockar upp som man plockar upp en ny linter. Det är en annan interaktionsmodell med sitt eget modaltillstånd, sin egna genväggrammatik och en uppsättning konventioner som bara ger mening efter att man har använt det i flera timmar av riktigt arbete. Tills man korsar det tröskeln berättar verktyget nästan ingenting — och värre, det berättar saker som är fel, eftersom meddelanden beror på läsarens läge, webbläsarens tillgänglighetsträd och plattformens IME-lager på sätt som inte är uppenbara utifrån.

Flyt, i vår mening, är den punkt då man kan ta emot ett trasigt komponent från en kollega, ta deras tangentbord och reproducera felet med skärmläsaren igång — utan att titta på skärmen, utan att konsultera ett fuskblad och utan att göra meddelandet sämre än det skulle vara i verklig användning. Bekantskap är den punkt då man har hört en skärmläsare. Gapet mellan de två är ungefär trettio till trettiofem timmar av avsiktlig träning.

Marknaden har tre skärmläsare som spelar roll för skrivbordswebb: NVDA på Windows, VoiceOver på macOS och iOS, och JAWS på Windows. Var och en har en tillräckligt stor användarbas för att ignorera den vore ett verkligt risktagande, och var och en meddelar samma uppmärkning något annorlunda. En flytande utvecklare kan driva minst två av dem.

Vår rekommendation, efter att ha sett dussintals utvecklare korsa tröskeln, är otvetydig: börja med NVDA på Windows och VoiceOver på macOS. Båda är gratis. Båda är förinstallerade (VoiceOver) eller installerbara på under fem minuter (NVDA). Båda används av tillräckligt många verkliga användare — NVDA innehar approx. 65% av Windows skärmläsarmarknadsandel i den senaste WebAIM-undersökningen, VoiceOver dominerar mobil och en meningsfull andel av macOS — att det du lär dig omedelbart överförs till fel du kan leverera en fix för. JAWS är det tredje verktyget, inte det första, även om det fortfarande är skärmläsaren med den största entreprisinstallationsbasen. Tre skäl.

De tre skälen att hoppa över JAWS i början är pedagogiska, inte politiska. Först och främst delar JAWS och NVDA en mental modell — Windows bläddrarläge kontra fokusläge, samma Insert-baserade kommandoprefix, samma virtuella buffert — så när man väl kan driva NVDA är nittiio procent av de JAWS-kommandon man faktiskt behöver en ordlistuppslagning bort. Dessutom har JAWS samlat på sig decennier av “smart” inferens: det försöker rätta dålig uppmärkning innan användaren hör den, vilket innebär att ett fel som JAWS tapetserar över ändå levereras till NVDA-användare. NVDAs medvetet konservativa beteende gör det till den bättre referensläsaren när man försöker lära sig vad som är trasigt. Slutligen är JAWS licensieringsfriktionen — aktivering, fyrtio minuters provläge som tjatar vid varje omstart — en inlärningsskatt man inte behöver betala förrän man är tillräckligt säker för att spendera den.

VoiceOver paras med NVDA snarare än konkurrerar med det eftersom de två läsarna representerar de två dominerande interaktionsmodellerna. NVDA (och JAWS) använder “PC-markör”-modellen: en virtuell buffert som lägger ut sidan som ett linjärt dokument och ett separat fokus som följer tab-ordningen. VoiceOver använder en enda VoiceOver-markör som lever ovanpå fokuset, navigerad av rotorn och av VO+piltangenterna. En utvecklare som bara behärskar en modell skriver kod som låter bra i deras läsare och dåligt i den andra. Att lära sig båda samtidigt är det enda tillförlitliga sättet att känna skillnaden.

Vecka-ett-programmet har en regel: stäng av skärmen. Inte dimmad, inte minimerad, inte “jag blundar” — fysiskt av, eller täckt med ett papper om din skärm är den enda i rummet. Poängen är att ta bort möjligheten att fuska. En seende utvecklares instinkt, i det ögonblick skärmläsaren säger något förvirrande, är att kasta en blick på skärmen och lösa tvetydigheten visuellt. Den instinkten är den enskilt största anledningen till att “jag testade med en skärmläsare” inte fångar verkliga fel.

Planera för tre pass om ungefär nittio minuter vardera under vecka ett, med minst en dag mellan passen så att muskelminnet hinner konsolideras. Varje pass har ett jobb. Det första bygger den grundläggande kommandogrammatiken. Det andra tvingar fram en verklig interaktion. Det tredje testar retention under en liten mängd stress.

Den andra till fjärde träningsveckan bör summeras till ungefär tjugo timmar — två nittio-minuterspass per vecka, plus en liten mängd tillfällig användning under ditt vanliga arbete. Målet under det här strecket är att internalisera de två saker som förvirrar nya skärmläsaranvändare mer än något annat: skillnaden mellan bläddrarläge och fokusläge, och skillnaden mellan vad rotorn ser och vad tab-ordningen ser.

Den vanligaste förvirringen i vecka två är det ögonblick en utvecklare trycker på en piltangent i NVDA, förväntar sig att den virtuella bufferten ska röra sig, och istället hör den fokuserade kombinationsrutan öppna sin alternativlista. Det är bläddrarläge som automatiskt växlar till fokusläge eftersom fokuset hamnat på ett element som NVDA klassificerar som en “application”-widget. Nya utvecklare upplever detta som att läsaren beter sig fel. Det gör den inte — den gör exakt vad specifikationen kräver. När man hört det tio eller femton gånger slutar man bli förvånad; tills dess, räkna med att bli förvånad ungefär varannat pass.

Vecka-tre-mönstret är formulär. Bygg en privat testningssida med åtta eller tio kontroller: ett obligatoriskt textfält med ett infogat felmeddelande, en datumväljare, ett flerval, en anpassad styled checkbox, en inaktiverad knapp som aktiveras, en “visa lösenord”-växling, ett telefonnummerfält med en landskodsväljare och en skicka-knapp som utlöser en serversidesvalideringssammanfattning. Skärm av, navigera igenom det fem gånger — först med NVDA i bläddrarläge, sedan NVDA i fokusläge, sedan NVDA igen med verbositetsinställningen uppdriven (Insert+Z, mer om det i avsnitt fem), sedan VoiceOver med rotorn, sedan VoiceOver utan rotorn. Samma formulär låter annorlunda fem gånger. Det är vad flyt känns som inifrån: att märka att samma uppmärkning berättar fem olika historier, och att kunna förutsäga i förväg vilken som kommer att spelas.

Vecka fyra är navigering. Ta en riktig, komplex sajt — en dokumentationsportal, en arbetsplatsdashboard, en e-handelskategorisida — och försök hitta en specifik information med enbart skärmläsargenvägar. Använd H för att hoppa rubriker. Använd D (NVDA) eller VO+U sedan “Landmarks” (VoiceOver) för att hoppa landmärken. Använd 1 till 6 för att hoppa till en viss rubriknivå. Vid slutet av vecka fyra bör navigeringsgenvägarna vara reflexer snarare än val, på samma sätt som tab och shift-tab redan är det.

När användarlägeskomandon är reflexer är nästa hopp in i varje läsares utvecklarorienterade ytor. Det är de lägen och genvägar som manualerna gömmer undan — dels för att de riktar sig till utvecklare, dels för att de är störiga nog att en daglig användare inte vill ha dem på. Tre är värda att känna till omedelbart.

Ytterligare två vanor sparar mer tid än vilken enskild genväg som helst. För det första, låt NVDAs speech viewer vara fäst på en andra skärm (eller i ett hörn av din enda skärm) medan du utvecklar. Den verbatimlogen över varje meddelande är för skärmläsararbete vad devtools-konsolen är för JavaScript: skillnaden mellan att gissa och att veta. För det andra, lär dig att läsa tillgänglighetsträdet i din webbläsares devtools — Chromes Accessibility-panel, Firefoxs Accessibility Inspector, Safaris Audit-flik. Läsaren meddelar vad tillgänglighetsträdet innehåller, inte vad DOM:en innehåller, och de två avviker tillräckligt ofta att man inte kan felsöka live-regioner, ARIA eller shadow DOM utan att läsa trädet direkt.

En förvirring att flagga nu, eftersom den äter timmar under vecka två och tre: läsläge kontra fokusläge är inte samma axel som “sidan är interaktiv” kontra “sidan är ett dokument.” NVDA växlar automatiskt till fokusläge när fokuset hamnar på en kontroll med role=“application”, eller på ett contenteditable, eller på vissa anpassade widgets som läsaren heuristiskt klassificerar som interaktiva — oavsett om sidan är mestadels statisk. Omvänt kommer en rikt interaktiv single-page-app vars rotelement är ett main-landmärke och vars widgets är välmärkta native-knappar att stanna i bläddrarläge under nästan hela en användares session. Läget är en egenskap hos det fokuserade elementet, inte en egenskap hos sidan.

Siffrorna nedan kommer från informell uppföljning av ungefär åttio utvecklare — frontend-ingenjörer, QA-leads, tillgänglighetsspecialister under utbildning — under tre år av företagsworkshoppar och en-till-en-mentorskap. Det är inte en forskningsstudie. De är tillräckligt bra för att planera mot. Två antaganden: avsiktlig träning (skärm av, verkliga uppgifter, inte “jag lät NVDA köra i bakgrunden medan jag kodade”), och ett fast läsarpar (NVDA på Windows och VoiceOver på macOS).

”Halvflytande” är det realistiska målet för de flesta seende utvecklare och är, i praktiken, allt du behöver för att vara en bra bidragare till en tillgänglig produkt. Verkligt flyt — den nivå vid vilken man troligen skulle kunna ersätta en daglig skärmläsaranvändare under en användbarhetsgenomgång — är mer som ett hundra och femtio timmar och ett år av tillfällig träning, och de flesta verksamma utvecklare behöver det inte. Sikta på halvflytande, schemalägg fyrtio timmarna och acceptera att allt därutöver kommer av att göra dagsjobbet med en läsare igång och en vilja att sakta ner.

Ett sista benchmark för att sätta förväntningar ärligt: de utvecklare som platåar, i vår erfarenhet, platåar mellan tio-timmarsmärket och tjugo-timmarsmärket. Orsaken är nästan alltid densamma — de slutar stänga av skärmen. De berättar för sig själva att de nu är “bra nog” för att testa med skärmen på, skärmläsaren i bakgrunden och visuell bekräftelse tillgänglig när ljudet är tvetydigt. Det är de inte. De sexton timmarna mellan “användbar” och “bekväm” kräver skärmen av eftersom det är den sträckan där läsarens meddelanden blir information snarare än brus. Utan det trycket återgår hjärnan till syn och läsarens röst tonar bort till bakgrundsljud. Om du märker att du saktar ner är det nästan alltid skärmen.

Anledningen till att “testa med en skärmläsare” ger så svaga resultat i branschen är inte att verktyget är svårt att lära sig — fyrtio timmar är genuint inte mycket tid — utan att inlärningen är obehaglig på ett specifikt sätt. Att stänga av skärmen får en seende utvecklare att känna sig inkompetent på ett sätt som är ovanligt i vår profession. Vi är vana vid att vara de som löser saker; skärmläsaren gör oss, för några timmar i sträck, till nybörjare igen. Det obehaget, inte tangenttryckningarna, är det verkliga hindret.

Vägen igenom är den ovan: NVDA och VoiceOver, tre pass under den första veckan med skärmen av, formulär och lägen i vecka två till fyra, genvägar i utvecklarläge så snart användarlägenas genvägar är reflexer, fyrtio timmar totalt innan man kan litas på vid en seriös förhandsvisningsgenomgång. Inget av detta är nytt. Det arbete branschen inte har gjort är att behandla det som arbete — schemalägga timmarna, försvara dem mot andra åtaganden, acceptera att de första tio av de timmarna känns meningslösa tills de plötsligt inte gör det.

Om du levererar en frontend är den version av dig på andra sidan de fyrtio timmarna en väsentligt bättre ingenjör än versionen som startade, på sätt som visar sig inte bara i ditt tillgänglighetsarbete utan i din förståelse av fokusordning, av progressiv förbättring, av vad webbläsaren faktiskt gör under huven. Skärmläsaren är den billigaste distribuerade systemlektionen tillgänglig för alla som skriver för webben. Priset är skärmen av och några helger.