Screen Reader Testing: How real users experience your website
Automated testing tools find technical deficiencies — but only testing with NVDA, JAWS and VoiceOver reveals whether blind and visually impaired users can really use your website. We check real-world usability manually and document every finding with a concrete solution.
3
Screen reader platforms
5 working days
to the audit report
50+
tests conducted
WCAG
2.2 AA reference
Screen reader tests in the WCAG 2.2 audit
- Manual tests with NVDA, JAWS and VoiceOver
- Full keyboard navigation check
- Findings report with severity and WCAG reference
- Prioritized action list with code examples
full audit up to 30 pages. Focused entry with the BFSG quick check from €490 net. The BFSG has applied since 28 June 2025 — violations can incur fines of up to €100,000 (BFSG §37).
A screen reader is the window to the digital world for blind users. NVDA on Windows, 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 fails to communicate semantics correctly. Our service offering includes manual screen reader tests as a standalone service and as part of the comprehensive WCAG 2.2 audit. In 50+ conducted tests we have developed a systematic methodology that delivers reproducible results and produces directly actionable solution proposals. We hold our own website to the same standard: it demonstrably meets WCAG 2.2 AA.
What screen reader tests deliver that automated tools cannot
Automated accessibility tools like axe-core and Lighthouse test technical rules: is there an alt text? Does the form field have a label? Is color contrast sufficient? These checks are valuable but capture only 30 to 50 percent of all actual accessibility problems (Source: WebAIM 2024). The remaining 50 to 70 percent (WebAIM 2024) arise from context-dependent issues that are only visible in real-world testing.
Typical examples: an image has alt text, but it reads "image_2024_final_v3.jpg" instead of a meaningful description. A form field has a label element, but the programmatic association is wrong so NVDA does not connect the label with the field. A table has column headings but they are not marked up as th elements with a scope attribute, so JAWS cannot relate cells and headers. A modal opens but focus remains on the triggering button instead of moving into the dialog. All these problems are only detectable in manual testing with real screen readers.
Why three screen readers?
The three screen reader platforms at a glance
NVDA (Windows)
NVDA (NonVisual Desktop Access) is the most widely used free screen reader for Windows, deployed by blind users worldwide, especially in Europe and Germany. We test with NVDA in combination with Firefox and Chrome, since browser differences can affect screen reader behavior. NVDA is particularly relevant for corporate websites and online shops.
JAWS (Windows)
JAWS (Job Access With Speech) is the most widely deployed commercial screen reader and is the standard in professional and government environments. Many users in enterprises and public institutions rely on JAWS. Differences from NVDA particularly affect the processing of ARIA live regions, tables and complex widgets. JAWS tests are especially relevant for authorities and financial institutions.
VoiceOver (macOS and iOS)
VoiceOver is Apple's built-in screen reader available on every Mac and iPhone without installation. On iOS, VoiceOver is especially important as a significant proportion of blind users rely on smartphones as their primary device. Touch-based navigation with swipe gestures places its own demands on accessibility, distinct from desktop keyboard navigation.
Our testing process in detail
A professional screen reader test follows a structured methodology that ensures all relevant areas of your website are systematically checked. We align with the requirements of EN 301 549 and WCAG 2.2 AA success criteria and document every finding with severity, WCAG reference and a concrete solution proposal.
Scope definition and scenario development
In a joint kick-off we define the areas to be tested and develop real user scenarios. For an online shop these typically include: navigating the homepage, searching for and selecting a product, filling the cart, completing checkout, creating an account and logging in. For a corporate website: homepage, contact form, download area, job listings, event calendar. The scenarios form the basis for the test and ensure we cover the critical usage paths.
Automated pre-analysis
Before the manual test we run an automated analysis with axe-core and Pa11y. This identifies technical barriers that serve as a baseline for the manual test. Automatically detected issues are merged into the report to avoid redundancies and provide a complete picture. The pre-analysis also covers page structure, heading hierarchy and ARIA landmark checks.
Manual testing with NVDA and Firefox
We run through the defined user scenarios completely with NVDA and Firefox. We check: correct announcement of page titles, language and encoding; complete and meaningful heading hierarchy; navigation via heading list, links list and landmarks; correct announcement of image descriptions; operable forms with understandable labels and error messages; correct output of table data; accessibility of modals, tabs and accordions; and feedback on dynamic content changes.
Manual testing with JAWS
The same scenarios are repeated with JAWS and Chrome. Special attention is paid to differences from NVDA attributable to differing ARIA interpretations. JAWS-specific test points include: behavior of ARIA live regions, output of form validation messages, navigation in complex data tables and accessibility of custom widgets.
Manual testing with VoiceOver on macOS and iOS
On macOS we test with VoiceOver and Safari, as Safari on macOS works best with VoiceOver. On iOS we test on a real iPhone device with VoiceOver enabled. Mobile test points include: swipe gesture navigation, activating buttons and links by tapping, completing forms via the on-screen keyboard and accessibility of slider elements and gesture-based interactions.
Keyboard navigation without screen reader
In addition to screen reader testing we conduct a full keyboard navigation check: tab order, focus visibility, operability of all interactive elements via Enter and Space, Escape functionality for modals and dropdowns, and correct focus return after closing overlays. This test uncovers barriers for users who rely on a keyboard but not a screen reader.
Documentation and report
Every identified barrier is documented with: affected WCAG success criterion, severity (critical, high, medium, low), affected URL and element, description of the problem and its impact on screen reader users, and a concrete solution proposal with code example. The report includes a prioritized action list and a summary of conformance status.
From finding to fixed barrier
Every screen reader finding comes with a concrete solution proposal and a code example. This is how the output changes for NVDA and VoiceOver once a form field is marked up cleanly: a silent input becomes a clearly announced, operable required field — and a critical finding becomes a passed re-test.
- Before: label not associated, no error text, the screen reader only says “input”
- After: associated label, aria-required and an error message via aria-describedby
- Re-test confirms the fix across all three screen readers
Common screen reader barriers by page section
Across our 50+ conducted screen reader tests (project experience) we have identified recurring barrier patterns that vary by page section and component. The following areas show particularly frequent issues:
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 (JAWS 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="" (read aloud by NVDA), 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 1.4.13)
The BFSG has applied since 28 June 2025 — test before someone else does
Whether your website is operable for blind users is decided not in the source code but in a real screen reader. In an initial call we show you where your critical usage paths stand today.
Screen reader testing for specific website types
The critical test areas and scenarios differ depending on the type of website. We have experience with all common website types and adapt our testing methodology to your specific requirements. The following overview shows typical focus areas for the most important website types in our portfolio.
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 sector
Strict requirements for public bodies under BFSG and EU Directive 2016/2102: full WCAG 2.2 AA conformance, accessibility statement per BFSG §14, feedback mechanism for users and contact details of the responsible person.
Screen reader testing in the right scope
The manual screen reader test is part of our audit offering. From a focused entry through the full audit to ongoing monitoring — all prices net, with no hidden items. Details on the Services page.
BFSG Quick Check
Focused expert short check of your most important page including a first screen reader pass.
- Short check of the homepage or a key page
- First NVDA pass of the main paths
- Prioritized immediate measures
- Clear recommendation for the next steps
WCAG 2.2 Audit
Full audit including manual screen reader tests with NVDA, JAWS and VoiceOver (SME website up to 30 pages).
- Manual tests on all three platforms
- Full keyboard navigation check
- Findings report with severity and WCAG reference
- Prioritized action list with code examples
- Basis for the accessibility statement
BFSG Monitoring
Ongoing oversight after the test — so new features do not introduce new barriers.
- Regular automated test runs
- Regression alerts for new barriers
- Targeted screen reader re-tests when needed
- Monthly conformance report
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 screen reader tests cover
Screen reader tests are an indispensable part of any comprehensive accessibility audit. They specifically check usability for blind and visually impaired users with assistive technologies. However, they do not cover all dimensions of accessibility. A comprehensive WCAG 2.2 audit additionally includes checking color contrast values, evaluating text alternatives for non-text content, checking captions and audio descriptions for video content and assessing cognitive accessibility for people with learning disabilities.
Furthermore, screen reader tests do not replace usability tests with real affected individuals. An experienced tester who uses screen readers professionally can reliably identify real usage barriers. However, actual users with disabilities bring experiences and usage strategies that go beyond what a technical audit can cover. We recommend conducting supplementary usability tests with affected individuals after the technical audit to validate findings and identify additional qualitative improvement potential.
Screen reader testing as part of the BFSG compliance package
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 detect only 30 to 50 percent (WebAIM 2024) of barriers — the rest is found only by manual screen reader testing
- We test with NVDA, JAWS and VoiceOver plus full keyboard navigation 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 from €490 net
- The BFSG has applied since 28 June 2025 — violations can incur fines of up to €100,000 (BFSG §37)
- Ongoing protection with BFSG monitoring from €49 per month so new features do not introduce new barriers
Frequently asked questions about screen reader testing
Screen reader tests as part of a sustainable accessibility strategy
A one-off screen reader test 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: automated accessibility monitoring for continuous oversight, targeted screen reader tests for new features or major changes, and annual full WCAG 2.2 audits for overall assessment.
This approach combines the efficiency of automated tools with the thoroughness of manual testing 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 achieve permanently accessible websites with significantly less remediation effort than teams that treat accessibility as an afterthought. Let us work together to develop the right strategy for your project. Contact us for a no-obligation initial consultation.