Vrijwel elk toegankelijkheidsprogramma dat men auditet, rapporteert hetzelfde getal: negentig-en-zoveel procent van de frontend-ontwikkelaars zegt “te testen met een schermlezer”. Vraag hen een demonstratie te geven, en de demo is doorgaans dezelfde drie toetsaanslagen — aanzetten, door de pagina tabben, uitzetten. Dat is geen testen. Dat is een vakje afvinken.

De reden dat dit zo gaat, is structureel en niet voortkomend uit luiheid. Een schermlezer is geen hulpmiddel dat men kan oppakken zoals een nieuwe linter. Het is een ander interactiemodel met een eigen modale toestand, een eigen snelkoppelingsgrammatica en een reeks conventies die pas logisch zijn nadat men hem enkele uren voor echt werk heeft gebruikt. Totdat men die drempel overschrijdt, vertelt het hulpmiddel vrijwel niets — en erger, het vertelt dingen die niet kloppen, omdat de aankondigingen afhangen van de modus van de lezer, de toegankelijkheidsboom van de browser en de IME-laag van het platform op manieren die van buiten niet zichtbaar zijn.

Vaardigheid betekent voor ons doeleinden het punt waarop men een collega een kapotte component kan overhandigen, het toetsenbord kan overnemen en de fout kan reproduceren met de schermlezer actief — zonder naar het scherm te kijken, zonder een spiekbriefje te raadplegen en zonder de aankondiging slechter te maken dan in werkelijk gebruik. Vertrouwdheid is het punt waarop men een schermlezer heeft gehoord. De kloof tussen beide bedraagt ruwweg dertig tot vijfendertig uur bewuste oefening.

De markt kent drie schermlezers die er toe doen voor desktop-webwerk: NVDA op Windows, VoiceOver op macOS en iOS, en JAWS op Windows. Elk heeft een gebruikersgroep die groot genoeg is om te negeren een reëel risico te zijn, en elk kondigt dezelfde markup iets anders aan. Een vaardige ontwikkelaar beheerst er minstens twee.

Onze aanbeveling, na het begeleiden van tientallen ontwikkelaars over de drempel, is ondubbelzinnig: begin met NVDA op Windows en VoiceOver op macOS. Beide zijn gratis. Beide zijn voorgeïnstalleerd (VoiceOver) of in minder dan vijf minuten te installeren (NVDA). Beide worden gebruikt door genoeg echte gebruikers — NVDA heeft ca. 65% marktaandeel bij Windows-schermlezers in de meest recente WebAIM-enquête, VoiceOver domineert mobiel en een substantieel deel van macOS — zodat wat men leert onmiddellijk kan worden vertaald naar fouten waarvoor een oplossing kan worden uitgebracht. JAWS is het derde hulpmiddel, niet het eerste, ook al heeft het nog steeds de grootste installatiebasis in de enterprise. Drie redenen.

De drie redenen om JAWS aan het begin over te slaan zijn pedagogisch, niet politiek. Ten eerste delen JAWS en NVDA een denkmodel — bladermodus versus focusmodus op Windows, hetzelfde Insert-gebaseerde opdrachtenprefix, dezelfde virtuele buffer — zodat, zodra men NVDA beheerst, negentig procent van de JAWS-opdrachten die feitelijk nodig zijn een glossarium-zoekopdracht verwijderd zijn. Ten tweede heeft JAWS decennia “slimme” inferentie opgebouwd: het probeert slechte markup te repareren voordat de gebruiker die hoort, wat betekent dat een fout die JAWS verbergt toch wordt uitgeleverd aan NVDA-gebruikers. Het bewust conservatieve gedrag van NVDA maakt het de betere referentielezer bij het leren wat er kapot is. Ten derde is de licentiedrempel van JAWS — activering, de veertig-minuten-proefmodus die bij elke herstart opkomt — een leertaks die men niet hoeft te betalen totdat men zeker genoeg is om die te spenderen.

VoiceOver is een aanvulling op NVDA in plaats van een concurrent, omdat de twee lezers de twee dominante interactiemodellen vertegenwoordigen. NVDA (en JAWS) gebruiken het “PC-cursor”-model: een virtuele buffer die de pagina als een lineair document uitlegt en een afzonderlijke focus die de tab-volgorde volgt. VoiceOver gebruikt één VoiceOver-cursor die boven de focus zweeft, bestuurd door de rotor en VO+pijltoetsen. Een ontwikkelaar die slechts één model beheerst, schrijft code die goed klinkt in de eigen lezer en slecht in de andere. Beide tegelijk leren is de enige betrouwbare manier om het verschil te voelen.

Het programma voor week één kent één regel: zet de monitor uit. Niet gedimd, niet geminimaliseerd, niet “ik sluit mijn ogen” — fysiek uit, of bedekt met een stuk karton als het scherm het enige in de kamer is. Het doel is de mogelijkheid tot valsspelen te verwijderen. Het instinct van een ziende ontwikkelaar, zodra een schermlezer iets verwarrends zegt, is op het scherm te kijken en de ambiguïteit visueel op te lossen. Dat instinct is de grootste reden dat “ik heb getest met een schermlezer” echte fouten niet opvangt.

Plan drie sessies van circa negentig minuten elk in week één, met minstens een dag ertussen zodat het spiergeheugen tijd heeft om te consolideren. Elke sessie heeft één taak. De eerste bouwt de basisopdrachtgrammatica op. De tweede dwingt een echte interactie af. De derde test de retentie onder een kleine hoeveelheid stress.

De tweede tot en met vierde week oefening moet optellen tot ruwweg twintig uur werk — twee sessies van negentig minuten per week, plus een kleine hoeveelheid bijkomend gebruik terwijl men het dagelijkse werk doet. Het doel in deze periode is de twee dingen te internaliseren die nieuwe schermlezer-gebruikers meer verwarren dan wat dan ook: het onderscheid tussen bladermodus en focusmodus, en het verschil tussen wat de rotor ziet en wat de tab-volgorde ziet.

De meest voorkomende verwarring in week twee is het moment dat een ontwikkelaar een pijltoets indrukt in NVDA, verwacht dat de virtuele buffer beweegt, en in plaats daarvan hoort dat de gefocuste keuzelijst zijn opties opent. Dat is bladermodus die automatisch omschakelt naar focusmodus omdat de focus op een element is geland dat NVDA als een “applicatie”-widget classificeert. Nieuwe ontwikkelaars ervaren dit als een storing van de lezer. Dat is het niet — het is de lezer die precies doet wat de specificatie vraagt. Zodra men dit tien of vijftien keer heeft gehoord, stopt men met verrast zijn; tot die tijd is het verstandig om bij elke andere sessie verrast te worden.

Het patroon van week drie zijn formulieren. Bouw een privé-testpagina met acht of tien bedieningselementen: een verplicht tekstveld met een inline-fout, een datumkiezer, een meervoudige selectie, een aangepast gestylde checkbox, een uitgeschakelde knop die ingeschakeld wordt, een “wachtwoord tonen”-schakelaar, een telefoonnummerveld met een landcode-selector en een verzendknop die een server-side validatiesamenvatting activeert. Monitor uit, navigeer er vijf keer doorheen — eerst met NVDA in bladermodus, dan NVDA in focusmodus, dan NVDA opnieuw met de uitgebreide aankondigingsinstelling aan (Insert+Z, meer daarover in sectie vijf), dan VoiceOver met de rotor, dan VoiceOver zonder de rotor. Hetzelfde formulier klinkt vijf keer anders. Zo voelt vaardigheid van binnenuit: bemerken dat dezelfde markup vijf verschillende verhalen vertelt, en in staat zijn van tevoren te voorspellen welke zal spelen.

Week vier is navigatie. Neem een echte, complexe site — een documentatieportaal, een werkdashboard, een e-commerce-categoriepagina — en probeer een specifiek stuk informatie te vinden met alleen schermlezer-snelkoppelingen. Gebruik H om door koppen te springen. Gebruik D (NVDA) of VO+U dan “Landmarken” (VoiceOver) om door landmarken te springen. Gebruik 1 tot en met 6 om naar een bepaald kopniveau te springen. Aan het einde van week vier moeten de navigatiesnelkoppelingen reflexen zijn in plaats van keuzes, net zoals tab en shift+tab dat al zijn.

Zodra de gebruikersmodus-opdrachten reflexen zijn, is de volgende stap naar de ontwikkelaargerichte vlakken van elke lezer. Dit zijn de modi en snelkoppelingen die de handleidingen begraven — deels omdat ze op ontwikkelaars zijn gericht, deels omdat ze luidruchtig genoeg zijn dat een dagelijkse gebruiker ze niet ingeschakeld wil hebben. Drie zijn het waard onmiddellijk te kennen.

Twee verdere gewoonten zullen meer tijd besparen dan elke afzonderlijke snelkoppeling. Ten eerste: laat de spraakweergave van NVDA vastgemaakt op een tweede monitor staan (of in een hoek van de ene monitor) terwijl men ontwikkelt. Het woordelijke logboek van elke aankondiging is voor schermlezer-werk wat de dev-tools-console is voor JavaScript: het verschil tussen raden en weten. Ten tweede: leer de toegankelijkheidsboom te lezen in de ontwikkeltools van de browser — het toegankelijkheidsvenster van Chrome, de toegankelijkheidsinspecteur van Firefox, het audittabblad van Safari. De lezer kondigt aan wat de toegankelijkheidsboom bevat, niet wat de DOM bevat, en de twee lopen vaak genoeg uiteen dat live-regio’s, ARIA of shadow DOM niet te debuggen zijn zonder de boom rechtstreeks te lezen.

Een verwarring om nu te benoemen, omdat die in weken twee en drie uren kost: leesmodus versus focusmodus is niet hetzelfde als “de pagina is interactief” versus “de pagina is een document”. NVDA schakelt automatisch over naar focusmodus wanneer de focus op een bediening met role=“application” landt, of op een contenteditable, of op bepaalde aangepaste widgets die de lezer heuristisch als interactief classificeert — ongeacht of de pagina grotendeels statisch is. Omgekeerd blijft een rijke interactieve single-page-app waarvan het rootelement een main-landmark is en waarvan de widgets goed opgemaakte native knoppen zijn, voor vrijwel de hele sessie van een gebruiker in bladermodus. De modus is een eigenschap van het gefocuste element, niet van de pagina.

De onderstaande cijfers zijn afkomstig van informele registratie van circa tachtig ontwikkelaars — frontend-engineers, QA-leads, toegankelijkheidsspecialisten in opleiding — over drie jaar bedrijfsworkshops en individuele begeleiding. Het is geen wetenschappelijk onderzoek. Het is goed genoeg om mee te plannen. Twee aannames: bewuste oefening (monitor uit, echte taken, niet “ik liet NVDA op de achtergrond draaien terwijl ik codeerde”), en een vaste lezer-combinatie (NVDA op Windows en VoiceOver op macOS).

”Half-vaardig” is het realistische doel voor de meeste ziende ontwikkelaars en is, praktisch gesproken, alles wat nodig is om een goede bijdrage te leveren aan een toegankelijk product. Echte vaardigheid — het niveau waarop men plausibel een dagelijkse schermlezer-gebruiker zou kunnen vervangen tijdens een gebruiksonderzoekreview — is meer dan honderdvijftig uur en een jaar bijkomende oefening, en de meeste werkende ontwikkelaars hebben die niet nodig. Streef naar half-vaardig, plan de veertig uur in, en accepteer dat alles daarna voortkomt uit het dagelijkse werk met een actieve lezer en de bereidheid om te vertragen.

Nog één schatting om de verwachtingen eerlijk te stellen: de ontwikkelaars die stagneren, doen dat in onze ervaring tussen de tien en twintig uur. De oorzaak is bijna altijd dezelfde — ze zetten de monitor niet meer uit. Ze vertellen zichzelf dat ze nu “goed genoeg” zijn om te testen met het scherm aan, de schermlezer op de achtergrond actief en visuele bevestiging beschikbaar wanneer het geluid ambigu is. Dat zijn ze niet. De zestien uur tussen “bruikbaar” en “comfortabel” vereisen de monitor uit omdat dat de periode is waarin de aankondigingen van de lezer informatie worden in plaats van ruis. Zonder die druk keert de hersenen terug naar het gezichtsvermogen en vervaagt de stem van de lezer tot achtergrondgeluid. Als de voortgang vertraagt, is het bijna altijd de monitor.

De reden dat “testen met een schermlezer” in de branche zulke zwakke resultaten oplevert, is niet dat het hulpmiddel moeilijk te leren is — veertig uur is werkelijk niet veel tijd — maar dat het leren op een specifieke manier oncomfortabel is. Het uitzetten van de monitor maakt een ziende ontwikkelaar onbeholpen op een manier die ongebruikelijk is in ons vak. Men is gewend de persoon te zijn die dingen uitzoekt; de schermlezer maakt ons, voor een paar uur achtereen, opnieuw beginners. Dat ongemak, en niet de toetsaanslagen, is het echte obstakel.

Het pad erdoorheen is het bovenstaande: NVDA en VoiceOver, drie sessies in de eerste week met de monitor uit, formulieren en modi in weken twee tot en met vier, ontwikkelmodus-snelkoppelingen zodra de gebruikersmodus-snelkoppelingen reflexen zijn, veertig uur totaal voordat men kan worden vertrouwd met een serieuze pre-releasesweep. Niets hiervan is nieuw. Het werk dat de branche niet heeft gedaan, is het als werk behandelen — de uren inplannen, ze verdedigen tegen andere verplichtingen, accepteren dat de eerste tien van die uren nutteloos aanvoelen totdat ze dat plotseling niet meer doen.

Als men een frontend uitbrengt, is de versie van u aan de andere kant van die veertig uur een wezenlijk betere ingenieur dan de versie die begon — op manieren die zichtbaar worden niet alleen in het toegankelijkheidswerk maar ook in het begrip van focusvolgorde, van progressive enhancement, van wat de browser werkelijk doet onder de motorkap. De schermlezer is de goedkoopste les in gedistribueerde systemen die beschikbaar is voor iedereen die voor het web schrijft. De prijs is de monitor uit en een paar weekenden.