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 actually use your website. We conduct manual screen reader tests that reflect the real user experience and document concrete improvement measures.
3
Screen reader platforms
50+
tests conducted
60%
barriers only detectable manually
WCAG
2.2 AA reference
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.
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 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.
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)
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.
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
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.