Toegankelijkheid ≠ Overlay: wanneer een overlay de schermlezer verstoort
Schermlezers presenteren via spraak of braille de informatie die een interface programmatisch beschikbaar stelt. Gebruikers leren de commando’s, stellen voorkeuren in en ontwikkelen strategieën voor koppen, links, regio’s, formulieren en bedieningselementen. W3C noemt schermlezers als ondersteunende technologie voor interactie met het web. Het uitgangspunt moet daarom een correct gebouwde website zijn, niet een poging van de pagina om de technologie van de gebruiker te vervangen.
De schermlezer is al de ondersteunende technologie van de gebruiker
Schermlezers presenteren via spraak of braille de informatie die een interface programmatisch beschikbaar stelt. Gebruikers leren de commando’s, stellen voorkeuren in en ontwikkelen strategieën voor koppen, links, regio’s, formulieren en bedieningselementen. W3C noemt schermlezers als ondersteunende technologie voor interactie met het web. Het uitgangspunt moet daarom een correct gebouwde website zijn, niet een poging van de pagina om de technologie van de gebruiker te vervangen.
Wat een schermlezer werkelijk nodig heeft van een website
Interoperabiliteit hangt af van de code: semantische HTML, echte koppen, herkenbare links en knoppen, labels die aan velden zijn gekoppeld, correcte toegankelijke namen, rollen, toestanden en waarden en coherent focusbeheer. W3C legt uit dat schermlezers de koppenstructuur voor navigatie kunnen gebruiken en dat standaard HTML-bedieningselementen de samenwerking met ondersteunende technologie bevorderen. Als deze basis faalt, zit het probleem in de implementatie.
Wat er verandert wanneer een overlay wordt toegevoegd
Sommige overlays injecteren JavaScript van derden dat de pagina analyseert en front-endproblemen probeert te repareren. Ondersteunende technologie kan daardoor een gewijzigde versie van de interface ontvangen. De Overlay Fact Sheet waarschuwt dat zulke reparaties de laadtijd kunnen vertragen of onverwachte veranderingen kunnen veroorzaken. Niet elke overlay veroorzaakt altijd dezelfde fout, maar er komt wel een extra variabele tussen website en schermlezer.
Focus, toetsenbord en structuur: kleine veranderingen kunnen grote barrières worden
Voor iemand die zonder zicht navigeert, bepaalt de focus waar die persoon zich bevindt en welk element wordt bediend. Onverwachte focuswisselingen, onderschepte toetsen of veranderde semantiek kunnen volledig desoriënteren. Dat geldt ook voor kunstmatige koppen, onbetrouwbare namen of toestanden die niet correct worden aangekondigd. De Overlay Fact Sheet bevat ervaringen van schermlezergebruikers die focussprongen en moeilijkere navigatie beschrijven.
Een knop voor een ‘schermlezerprofiel’ stelt de verkeerde vraag
De vraag is niet of de gebruiker een speciaal profiel heeft geactiveerd, maar of de website vanaf het begin werkt met diens gebruikelijke ondersteunende technologie. W3C wijst erop dat mensen verschillende instellingen en hulpmiddelen gebruiken op basis van hun behoeften en voorkeuren. Een widget moeten vinden, openen en een extra modus kiezen voegt stappen toe zonder te garanderen dat de oorspronkelijke barrières worden opgelost.
Niet alle schermlezergebruikers navigeren op dezelfde manier
NVDA, JAWS, VoiceOver, TalkBack en andere oplossingen hebben verschillende commando’s en modi. Gebruikers stellen ook stem, snelheid, interpunctie, braille en navigatievoorkeuren zelf in. Het is riskant om één universele ‘schermlezerervaring’ te ontwerpen. Robuuste toegankelijkheid stelt standaard en voorspelbare informatie beschikbaar.
Correcte semantiek laat de gebruiker bepalen hoe te navigeren
Een goede kop is niet alleen grote tekst. Een veld wordt niet toegankelijk doordat er visueel een woord naast staat. Met passende HTML en waar nodig correcte ARIA kan de schermlezer de structuur overbrengen en kan de gebruiker met eigen commando’s navigeren. W3C adviseert waar mogelijk native elementen en gebruikt ARIA om rollen, toestanden en eigenschappen te communiceren.
Testen met een schermlezer is niet alleen controleren of de pagina spreekt
Dat tekst wordt uitgesproken bewijst niet dat een pagina bruikbaar is. Volledige taken moeten worden getest: hoofdinhoud bereiken, hiërarchie begrijpen, menu’s en formulieren gebruiken, fouten herkennen, dialogen en dynamische componenten bedienen en na interactie de oriëntatie hervinden. Toetsenbordtests en tests met ervaren gebruikers zijn eveneens belangrijk.
Wat een bedrijf moet doen in plaats van op een extra laag te vertrouwen
Identificeer eerst de echte barrières en herstel ze vervolgens in het component, sjabloon, thema of de toepassing die ze veroorzaakt. Gebruik semantische HTML, toegankelijke patronen, correct focusbeheer en tests met representatieve browser- en hulpmiddelcombinaties. Automatisering kan sommige problemen vinden, maar de schermlezerervaring vereist functionele en menselijke tests.
Toegankelijkheid ≠ Overlay
Levering 06 draait om een eenvoudig idee: de schermlezer behoort tot de gebruiker, niet tot de website. De site moet een solide, voorspelbare interface bieden waarmee die technologie kan samenwerken. Als een laag structuur, focus of semantiek wijzigt, kan een bekende barrière veranderen in een andere die moeilijker te diagnosticeren is. De duurzame oplossing blijft toegankelijkheid bij de bron herstellen en testen met echte ondersteunende technologie.
Officiële en technische bronnen
W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview
Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations
Entrega 06 — Overlays y lectores de pantalla.