Accessibility ≠ Overlay: when an overlay interferes with a screen reader

Screen readers are programs that present, through speech or braille, information that an interface exposes programmatically. People who use them learn their commands, configure preferences, and develop strategies for moving through headings, links, regions, forms, and controls. W3C lists screen readers among the assistive technologies people use to interact with the web. The starting point should therefore be a correctly built website, not an attempt by the page to replace the user’s technology.

Interoperability depends on information provided by the code: semantic HTML, real headings, recognizable links and buttons, labels associated with fields, correct accessible names, roles, states and values, plus coherent focus order and management. W3C explains that screen readers can use heading structure for navigation and that standard HTML controls support interoperability with assistive technologies. If this foundation fails, the problem is in the website implementation.

Some overlays inject third-party JavaScript that analyzes the page and attempts to repair front-end problems. Assistive technology may therefore receive a modified version of the interface. The Overlay Fact Sheet warns that such repairs can slow page loading or cause unexpected page changes for assistive-technology users. This does not mean every overlay always causes the same failure, but it adds another variable between the website and the screen reader.

For someone navigating without sight, focus is not a visual detail: it determines where they are and which element they will operate. Unexpected focus changes, intercepted keys, or altered semantics can cause complete disorientation. The same applies to artificial headings, unreliable names or states that are not announced correctly. Experiences collected by the Overlay Fact Sheet include screen-reader users describing focus jumps, altered navigation and sites becoming harder to use with an overlay enabled.

The question should not be whether the user activated a special profile, but whether the website works with their usual assistive technology from the start. W3C notes that people with disabilities use different configurations and tools according to their needs and preferences. Requiring someone to discover a widget, open it and select an additional mode adds steps without necessarily fixing the original barriers.

NVDA, JAWS, VoiceOver, TalkBack and other solutions have different commands, modes and combinations. People also configure speech, speed, punctuation, braille and navigation preferences. It is risky to design a supposedly universal ‘screen-reader user’ experience. Robust accessibility exposes standard, predictable information so browsers and assistive technologies can interoperate.

A good heading is not merely large text. A field is not accessible merely because a word appears visually nearby. A button should not be a generic element whose behavior is patched later. With appropriate HTML and, where needed, correct ARIA, a screen reader can communicate structure and users can navigate headings, links, regions and forms with their own commands. W3C recommends native elements whenever possible and defines ARIA as a way to communicate roles, states and properties to assistive technologies.

Hearing text does not prove that a page is usable. Complete tasks should be tested: reaching main content, understanding hierarchy, opening and closing menus, completing forms, identifying errors, using dialogs, reviewing results, controlling dynamic components and recovering orientation after interactions. Keyboard testing and, whenever possible, involvement of people who routinely use these technologies are also important.

First identify the actual barriers, then fix them in the component, template, theme or application that creates them. Use semantic HTML, accessible patterns, correct focus management and testing with representative browser and assistive-technology combinations. Automation can help detect some problems, but screen-reader experience requires functional and human testing.

Delivery 06 focuses on a simple idea: the screen reader belongs to the user, not to the website. The site should provide a solid, predictable interface with which that technology can interoperate. If a layer alters structure, focus or semantics, it can turn a known barrier into a different one that is harder to diagnose. The sustainable solution remains fixing accessibility at the source and testing with real assistive technologies.

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

This article is part of the “Accessibility ≠ Overlay” series. Delivery 06 — Overlays and screen readers.