Screen reader

Whatever does not arrive there does not exist for the user.

This makes the screen reader the most important testing instrument for digital accessibility and at the same time the reason why semantic HTML is not a matter of style. A button built as a <div> looks like a button in the browser. For the screen reader, it is a paragraph of text.

How a screen reader works

The widespread idea that a screen reader reads the page aloud "from top to bottom" only describes the special case. In practice, it is a navigation tool that accesses a data structure provided by the browser.

From the DOM to the accessibility tree

From the HTML, the browser first builds the DOM tree and from that a second, reduced tree: the accessibility tree. In this tree, each relevant element carries three pieces of information. First, a role (button, link, heading, text field, table). Second, an accessible name, which is determined according to a defined algorithm from the label, the alt attribute, aria-label or linked text. Third, states and properties, such as whether a checkbox is ticked, a field is invalid or a menu is expanded.

The screen reader reads this tree via a platform interface: on Windows via UI Automation or IAccessible2, on macOS via the NSAccessibility interface. This leads to a rule that explains a lot in everyday life: it is not the appearance that determines the output but the markup. CSS can visually turn an element into a button, but it changes nothing in the accessibility tree.

Browse mode and forms mode

Windows screen readers such as JAWS and NVDA store the page content in a virtual buffer and work in it in two modes. In browse mode (called "browse mode" in NVDA and "virtual cursor" in JAWS), the letter keys are navigation commands: H jumps to the next heading, F to the next form field, T to the next table, D to the next landmark region. As soon as focus moves into an input field, the screen reader switches to focus mode (forms mode) and passes keystrokes on to the application.

This mode switch is the reason why custom-built widgets fail so often. A home-made dropdown without the correct role does not trigger the switch. The user stays in browse mode, their arrow keys move through the text instead of through the options, and selection does not work.

Which screen readers are actually in use

The most reliable public data source on usage is the WebAIM Screen Reader User Survey #10. It was conducted in December 2023 and January 2024 and has 1,539 valid responses. The sample is not controlled and therefore not representative of all screen reader users, but it is the series that has been continued consistently since 2009.

Two conclusions are more important for testing practice than the percentages. First: JAWS and NVDA are almost neck and neck, together well over three quarters of desktop usage. Anyone who only tests with VoiceOver on a Mac is checking a minority situation. Second: the regional spread is considerable; in North America JAWS was clearly ahead of NVDA, and European participants made up the second-largest group at 30.7%. For the German-speaking market, NVDA is therefore the sensible minimum configuration: free, open source and usable on Windows with Chrome and Firefox.

On mobile, the picture shifts completely. There, the solutions included in the operating system dominate: VoiceOver on iOS and TalkBack on Android. A shop whose traffic is predominantly mobile needs at least one test run with VoiceOver on a real iPhone, because gesture navigation and focus behaviour differ from the desktop situation.

Why screen readers matter for online shops

Legally, the matter has been clear since 2025. The BFSG obliges B2C online shops in Germany to be accessible; the technical yardstick is the WCAG at conformance level AA, framed at European level by the harmonised standard EN 301 549. A considerable proportion of the success criteria can only be checked meaningfully with a screen reader, because they are about what is actually announced: the name of a button, the association of an error message, the change of a basket counter.

Economically, a second factor counts. A purchase process that cannot be completed with a screen reader does not produce a bounce but an abandoned checkout with a full basket. And the defects that get in the way are almost never exotic.

The places where shops regularly fail

The WebAIM survey has been asking about the biggest obstacles for years. The ranking has remained almost unchanged for fourteen years and reads like a list of defects of typical shop front ends:

• CAPTCHAs with image text are at the top by a clear margin. Relevant wherever registration, contact forms or newsletters are protected.
• Interactive elements that do not behave as expected: mega menus, tabs and modal dialogs. In a shop, this affects the main navigation, variant selection and address selection at checkout.
• Links and buttons without a meaningful name. Five elements all called "Learn more" are useless in a list of links. Icon buttons without a label, such as basket, wish list and search, belong in the same category.
• Areas that change unexpectedly. Product lists that load more items, filters with auto-submit, a basket that updates itself: without a live region, the change goes unannounced.
• Missing keyboard operability. Screen reader users operate the page via the keyboard; whatever cannot be focused cannot be reached.
• Images with missing or unsuitable alt text, in shops typically product images, size charts as graphics and badges such as "Sale".
• Complex forms and missing or incorrect headings, both core components of every checkout.

Particularly instructive is the question of how users look for information on a longer page. 71.6% of respondents navigate first via the headings, only 13.6% use the screen reader's search function and 3.7% the landmark regions. 88.8% consider heading levels very or somewhat useful. A clean h1 to h3 hierarchy on the product detail page is therefore not SEO cosmetics but the primary navigation framework.

A real-world example: the product card in the listing

A recurring pattern in shop templates is the product card, consisting of an image, title, price and a button. Visually, it works. With a screen reader, it often produces the following output if the card is built as a pure div structure and the button only carries an icon: "Graphic. Link. 89.90 euros. Button." Brand, product name and the meaning of the button are missing, and in a list of 24 products the pattern repeats identically 24 times.

The fix does not consist of additional ARIA but of three simple steps. The product image is given an alt text with brand and product name; for a linked image, the alt text describes the destination and not the motif. The product title becomes a heading at the appropriate level so that it appears in the list of headings. The button gets a name that stands on its own: "Add to basket, product name" instead of a bare basket icon. After that, the same card reads as a self-contained, distinguishable unit.

In Shopware 6, this point has now been partly solved out of the box. With version 6.7, the accessibility improvements to the default theme that were still behind a feature flag in 6.6 are permanently active, including correct list markup in the listing and basket and alt texts for icon buttons. Practical experience remains, however: as soon as a custom theme overrides the card, responsibility for this markup lies with the developer again.

Screen reader testing in practice

A screen reader test does not replace an automated check and is not replaced by one. Tools such as axe or WAVE find missing names, wrong roles and contrast errors reliably and quickly. Whether an error message is announced at the right moment and whether the order is understandable can only be decided by listening.

A short script is enough for a reliable run. The basic commands in NVDA on Windows:

• Ctrl + Alt + N starts NVDA, Insert + Q quits it.
• H and Shift + H jump forwards and backwards through headings, 1 to 6 to a specific level.
• D moves to the next landmark region, F to the next form field, T to the next table, B to the next button.
• Insert + F7 opens the elements list with all links, headings and landmarks of the page. This is the quickest way to see whether a page is structured navigably.
• Insert + Down Arrow reads continuously from the current position.

A proven test path in a shop is the chain: home page, category listing with a filter set, product detail page with a variant change, basket, checkout with a deliberately triggered form error, order completion. The built-in error is the most important step, because it shows whether the message is announced or sits silently in the DOM. Whatever the test finds ends up in the code: in a custom-built web application, roles, names and focus management can be anchored directly in the components.

Common misconceptions

"An overlay tool makes the shop screen-reader friendly." A toolbar with a read-aloud function overlaid on the page does not change the underlying markup. An image without alt text remains without alt text, a dialog without focus management remains a dead end. For some user groups, such a toolbar is a gain in convenience, but it is no use as proof of conformance.

"More ARIA helps." Additional attributes override native semantics and more often do harm than good. The first rule of the ARIA specification is not to use ARIA if a native HTML element has the same role. A <button> is preferable to a <div role="button"> in every respect.

"Screen readers are only relevant for blind users." They are also used by people with residual vision in combination with magnification software, by users with reading and concentration impairments, and situationally. The measures that improve a screen reader run also benefit keyboard operation, voice control and machine understanding of the page.

"The browser's read-aloud function is the same thing." Read-aloud functions output text as audio. A screen reader additionally conveys roles, states and structure and allows navigation within them. That is the decisive difference.

Classification and development

The operating logic of screen readers has remained stable for years; the environment has not. With the spread of single-page applications and content loaded on the client side, the number of situations in which the page changes without a new page being loaded has increased. It is precisely there that the unannounced changes arise that rank high on the list of problems. Live regions and deliberate focus management have therefore moved from fringe topics to core requirements.

At the same time, capabilities on the output side are growing. Current screen readers integrate image recognition and can describe an image without alt text approximately. This relieves users in everyday life but does not shift any obligation: an automatically generated description knows neither the variant nor the context nor the function of an image in the purchase process, and the standards require a provided text alternative. Anyone who relies on it hands their conformance to a third party.

FAQ

Which screen reader is suitable for testing? NVDA on Windows, in combination with Chrome or Firefox. It is free, open source and, together with JAWS, covers the vast majority of desktop usage. In addition, VoiceOver on an iPhone for the mobile path.

Does a screen reader test replace the automated tools? No, and the reverse is equally untrue. Automated checks only cover part of the WCAG success criteria by machine. The two methods check different classes of error and belong in the same test routine.

How long does a first run through a shop take? For the core path from the home page to the order confirmation, a few hours are realistic if someone knows the keyboard commands. The effort then lies in fixing, not in testing.

Does every image need alt text? Every informative image needs it. Purely decorative images get an empty alt="" so that the screen reader skips them. A missing attribute is not the same as an empty one, because without the attribute the software may read out the file name.

Is it enough if the page can be operated by keyboard? Keyboard operability is the prerequisite, not the goal. An element can be focusable and still have no name and no role. Then it is reachable but not understandable.