Skip to content

Screen Reader Output: What your website passes on to screen readers

A screen reader can only announce what is marked up in the code. In every view and every opened state we check whether names, roles, states and status messages are right, and we operate every flow without a mouse. Every finding comes with criterion, screenshot and solution path.

Request a Free Initial Consultation Full WCAG audit
Names, roles, states, messages Own accessibility statement published WCAG audit from €2,480 net

In short and in plain language

A screen reader reads web pages out loud. Blind people use one on the web. It can only announce what is marked up in the code.

We check what your website passes on to screen readers. Does every button have a clear name? Are errors and messages announced?

We use every flow with the keyboard only. We write down each problem, with a screenshot and a way to fix it.

This check is also part of our full accessibility audit. We do not test one specific screen reader on one specific device.

Write to us or give us a call.

Key figures

EN 301 549

European standard as audit basis

Keyboard

every flow checked without a mouse

Findings

with severity and proposed fix

WCAG

2.2 AA reference

Screen reader output in the WCAG 2.2 audit

from €2,480 net
  • Screen reader output: names, roles, states, messages
  • Keyboard operation of every flow without a mouse
  • Findings report with severity and WCAG reference
  • Prioritized action list with code examples
Request a Free Initial Consultation Go to WCAG audit

full audit up to 30 pages. Focused entry with the BFSG quick check for €490 net. The BFSG has applied since 28 June 2025 — violations can incur fines of up to €100,000 (BFSG §37).

Prices as of October 2026.

For blind people, a screen reader is the window to the digital world. NVDA and JAWS on Windows and VoiceOver on macOS and iOS read page content aloud, enable keyboard navigation and convey the structure and meaning of web pages. What feels intuitive to sighted users can be an insurmountable barrier for screen reader users — not because the design is poor, but because the underlying code does not communicate the semantics correctly. That is exactly where our check starts: we check what your website passes on to screen readers, as a stand-alone service and as part of the comprehensive WCAG 2.2 audit; our services give an overview. Every check follows a fixed method: defined flows, documented findings and an actionable solution path for every finding. We assess our own website against WCAG 2.2 AA ourselves; status and known limitations are set out in our accessibility statement.

WCAG 2.2 AA · Screen reader outputAudit reportPurchase funnel · desktop, smartphone and keyboard
84 %met
Action required
Checked per flowdesktop and smartphone
Names and roles met
States met
Status messages met
Keyboard-only · focus trap in menu open
Findings by severity9 total
Form field without label — only “edit”
Focus order jumps in checkout
Re-check after remediation scheduled
Markup passed on
“Proceed to checkout, button”
Headings H1 to H3
Landmarks detected
Image without alt text detected
Page18 links · 6 fields
WCAG audit incl. checkfrom €2,480
Checkednames · roles · states
Example view of a screen reader output check: findings list with severity, markup passed on and conformance status at a glance. Values are illustrative.

What a rule check alone misses

Automated tools such as axe-core check technical rules: is there an alt text? Does the form field have a label? Is the colour contrast sufficient? These checks are valuable but only capture part of the barriers: not all conformance failures can be detected automatically (WebAIM Million 2026). The rest stems from context-dependent problems that only become visible when you play through every flow and assess the markup in every state.

Typical examples: an image has an alt text, but the text is just the file name image_2024_final_v3.jpg instead of a description of its content. A form field has a label element, but the programmatic association is wrong, so the field gets no name. A table has column headings, but they are not marked up as th elements with a scope attribute, so cells and headings do not connect. A modal opens, but focus stays on the triggering button instead of moving into the dialog. Such problems usually only show up when you operate the flow with the keyboard and check what is passed on after each step.

Why we check the markup

NVDA, JAWS and VoiceOver interpret HTML and ARIA partly differently. What they share is the basis: they read what the browser exposes from HTML and ARIA as name, role and state. If this markup is right, the prerequisite for all screen readers is in place. How a specific screen reader in a specific version handles it is not something we test.

Common screen readers at a glance

NVDA (Windows)

NVDA (NonVisual Desktop Access) is a free open-source screen reader for Windows. How it outputs a page also depends on the browser used.

JAWS (Windows)

JAWS (Job Access With Speech) is a commercial screen reader for Windows. Differences from NVDA mainly concern the handling of ARIA live regions, tables and complex widgets.

VoiceOver (macOS and iOS)

VoiceOver is Apple's built-in screen reader and is available on every Mac and iPhone without installation. On a smartphone, navigation is by swipe gestures, which places its own demands on order, labels and target sizes.

Our testing method in detail

The check follows a fixed method so that the relevant areas of your website are covered systematically. The standard is the WCAG 2.2 AA success criteria and EN 301 549; every finding is documented with severity, WCAG reference and solution path.

Together we define which areas are checked and describe the flows. For an online shop these are typically: home page, product search and selection, shopping cart, checkout, creating an account and signing in. For a corporate website: home page, contact form, download area, job listings. At the start we record the date, addresses and screenshots of the version under test.

From finding to fixed barrier

Every finding comes with a solution path and code example. This is how what a screen reader can announce changes once a form field is properly marked up: a nameless input becomes a named, operable required field — a re-check then shows whether the fix holds.

  • Before: label not associated, no error text, the field has no name
  • After: associated label, aria-required and error message via aria-describedby
  • A re-check shows whether the fix holds
Beforesilent
Field without label
“edit”
No error text, no role
VS
Afterannounced
Email address, required
“Email address, required, edit field”
Label, aria-required, aria-describedby

Common screen reader barriers by page section

Screen reader barriers follow recurring patterns that vary by page section and component. Typical problem areas are:

Navigation and menus

Missing or incorrectly applied ARIA labels on navigation regions (role="navigation" without aria-label when multiple nav elements exist), dropdown menus not operable by keyboard, missing current page indication (aria-current="page") and invisible focus indicators in hamburger menus.

Forms

Labels not programmatically associated (label-for missing or id mismatch), missing required field indication (aria-required), error messages not linked to the erroneous field (aria-describedby missing), and form validation that does not move focus to the erroneous field after submission failure.

Modals and overlays

Focus not moved to modal on open, no focus trap (screen reader leaves modal via Tab), missing aria-modal attribute, no close via Escape key and no focus return to the triggering button on close.

Dynamic content

Status messages after form submission without an ARIA live region (screen reader user does not learn whether the submission succeeded), loading indicators without feedback, and content loaded in infinite scroll lists without announcement of new items.

Tables

Data tables without th elements with scope attribute (screen readers cannot relate cells to headings), layout tables without role="presentation", overly complex nested tables without aria-describedby and missing caption elements on informative tables.

Images and graphics

Alt texts showing filenames instead of meaningful descriptions, decorative images without alt="" (announced by screen readers), complex infographics without extended text descriptions (aria-describedby or longdesc) and icon buttons without a recognizable label (aria-label missing).

Keyboard navigation: a prerequisite for everyone

Keyboard navigation is not only relevant for screen reader users. People with motor disabilities who cannot operate a mouse depend on the keyboard. Power users and developers also frequently navigate by keyboard. WCAG 2.1.1 requires that all website functions be reachable and operable via keyboard. WCAG 2.1.2 requires that keyboard focus cannot become trapped in an area from which there is no escape.

  • All links, buttons and form fields reachable via Tab key
  • Visible focus indicator on every focused element (WCAG 2.4.7)
  • Focus not obscured by sticky headers or cookie banners (WCAG 2.4.11)
  • Dropdown menus navigable by arrow keys, closable by Escape
  • Modals correctly trap focus and return it when closed
  • Tabs and accordions operable per WAI-ARIA Authoring Practices
  • Custom widgets with correct ARIA roles and keyboard interactions
  • No content exclusively accessible via hover effect (WCAG 2.1.1)

The BFSG has applied since 28 June 2025 — check before someone else does

A screen reader announces what your website passes on to it. In the initial consultation we show you where your most important flows stand today.

Request a Free Initial Consultation Call now: +49 5123 9579000

Screen reader output by website type

Depending on the type of website, the critical areas and flows differ. We adapt the flows to your website and your requirements. The following overview shows typical focal points for common website types.

Online shops

Critical test paths for accessible e-commerce: product search and filtering, product detail page with variant selection, shopping cart, multi-step checkout with address entry and payment selection, order confirmation. Special attention to accessibility of quantity controls, price displays and form validation.

Corporate websites

Focus areas for corporate websites: navigation accessibility, accessibility of image galleries and video players, PDF downloads and their text alternatives, job listings and application forms, event calendars and interactive maps.

Public procurement

Requirements from public procurement: under Section 121(2) GWB, for procurement intended for use by natural persons, the technical specification must, except in duly justified cases, take into account accessibility criteria for people with disabilities or design for all users. Tender documents can refer to EN 301 549 for this. For bidders and contracting authorities, we check the required usage paths by keyboard and for screen reader output.

Screen reader output checks in the right scope

Checking screen reader output is part of our audit offering. From a focused entry through the full audit to ongoing monitoring — all prices net. Details on the Services page.

BFSG Quick Check

Focused short check of the home page and one business-critical process against the WCAG 2.2 AA success criteria. Testing keyboard and screen reader output is part of the full audit.

€490 one-off
  • Check against the WCAG 2.2 AA success criteria
  • Home page and one business-critical process in scope
  • Short report with the most critical findings
  • Adds test findings to the free initial BFSG assessment from the first consultation (not legal advice)
  • Fully credited against a later full audit
Request quick check
Recommended

WCAG 2.2 Audit

Full audit including checks of keyboard and screen reader output (SME website up to 30 pages).

from €2,480 one-off
  • Screen reader output in every flow
  • Full keyboard navigation check
  • Findings report with severity and WCAG reference
  • Prioritized action list with code examples
  • Basis for the accessibility statement
Request audit

BFSG Monitoring

Ongoing oversight after the test — so that new barriers introduced by changes are spotted early.

from €49 per month
  • Regular check runs
  • Regression alerts for new barriers
  • Targeted re-checks when needed
  • Regular conformance report
Request monitoring

All prices net plus VAT. We calculate larger websites and shops by page type — you receive a fixed-price quote after the free initial consultation.

Scope and limits: what the check covers

Checking screen reader output is an essential part of a complete accessibility audit. It does not, however, cover every dimension of accessibility. A full WCAG 2.2 audit additionally covers colour contrast, the assessment of text alternatives for non-text content, captions and audio descriptions for video content, and the assessment of understandability and predictability.

Not included are tests on specific devices and with specific screen readers: we assess what your website passes on to screen readers. How a specific screen reader in a specific version handles this markup may differ in individual cases. Tests with people with disabilities are not included either. They bring experience and usage strategies that go beyond a technical check; if you want to include them, complement the audit with user tests involving affected people.

Screen reader output and the BFSG

The Accessibility Strengthening Act (BFSG), which has applied to certain products and services since 28 June 2025, does not explicitly require screen reader tests. In practice, the technical reference is the EN 301 549 standard: for the time being in version V3.2.1, which is based on WCAG 2.1 AA; version V4.1.1, published in September 2026, adopts WCAG 2.2. Our test standard WCAG 2.2 AA includes the requirements of WCAG 2.1 AA. Several of these criteria, for example on names, roles and states or on status messages, directly concern what screen readers can announce. Our WCAG 2.2 audit therefore combines measurement, assessment of every criterion, and keyboard and screen reader output; what the law requires in detail is summarised on the BFSG requirements page.

How screen readers read your page

What a screen reader makes of your markup and which patterns have proven themselves is described in the article on screen reader optimisation. For dynamic areas — filters, carts, status displays — the article on ARIA roles, states and live regions is the technical complement. And because every screen reader test starts with the keyboard, the article on keyboard navigation belongs to it.

Key takeaways

  • Automated tools do not detect all conformance failures (WebAIM Million 2026) — context-dependent problems usually only show up when you play through every flow and assess the markup
  • We check whether names, roles, states and status messages are marked up for screen readers, operate every flow without a mouse and document every finding with severity and WCAG reference
  • Part of the WCAG 2.2 audit from €2,480 net; focused entry with the BFSG quick check for €490 net
  • The BFSG has applied since 28 June 2025 — violations can incur fines of up to €100,000 (BFSG §37)
  • Ongoing oversight with BFSG monitoring from €49 per month so that new barriers introduced by changes are spotted early

Frequently asked questions about screen reader output

Screen reader output as part of a sustainable accessibility strategy

A one-off check provides a snapshot. Websites change continuously: new features are developed, content is updated, CMS updates are applied. Each change can introduce new barriers. For sustainable accessibility we therefore recommend a multi-layer model: accessibility monitoring for continuous oversight, targeted re-checks of keyboard and screen reader output for new features or major changes, and annual full WCAG 2.2 audits for overall assessment.

This approach combines the breadth of measurement with the thoroughness of assessing every criterion and keeps audit effort manageable without compromising quality. Development teams that build accessibly from the start and establish regular screen reader tests as part of their quality assurance process usually avoid costly rework that arises when accessibility is treated as an afterthought. Let us work together to develop the right strategy for your project. Contact us for a no-obligation initial consultation.

How the website of a rehabilitation clinic could look

The draft shows structure and handling: departments to switch through, the path from medical report to arrival, a weekly plan and stated details on step-free access. The clinic in it is invented.

Draft
Rehabilitation clinic

Rehab clinic with application path and verifiable details

A draft for a rehabilitation clinic: three departments can be switched through, and the path from the medical report through the application to the funding body up to the arrival day is set out in four steps. A week in the house is shown as a daily plan, alongside rooms, visiting hours and support for relatives. The accessibility section states door widths, lift dimensions and call systems instead of a blanket assurance.

DepartmentsApplication pathWeekly planVerifiable measurements

Illustrative layout drafts. The businesses shown are fictitious; these are not client projects.

What can we help you with?

One click is enough — everything after that is optional.

Tell us briefly about the project

Everything on this step is optional.

As shown in your browser, with or without https://.

When would you like to start? (optional)
Rough budget range (optional)

Optional — you are not committing to anything.

A few keywords are enough. If you write something, please use at least 5 characters.

How can we reach you?

We usually get back to you within one business day.

Your name or surname, at least 2 characters.

Only needed if you would like a call back.

The address our reply should go to, with @ and domain.

By submitting you consent to the processing of your details to handle this request. Details in our privacy policy.