Accessibility

Performing Screen Reader Tests Yourself: A Guide for Teams

06 June 2026Zensations

You do not need a specialist laboratory to find obvious barriers. With an hour of time and standard tools, every team can identify the most important issues.

The Keyboard Test as an Introduction

Put your mouse aside and operate your main navigation path using only the tab key, arrow keys, and enter key. Pay attention to whether the focus is always visible, if the order remains logical, and if menus and dialogues can be closed again.

If this test fails, any screen reader usage will also fail. This is why every audit begins at this point.

Check with Existing Tools

These programmes are already installed or available for free:

VoiceOver on macOS and iOS
Narrator on Windows and NVDA as a free alternative
TalkBack on Android
The Accessibility Checker in your browser's developer tools

What Exactly to Listen For

Have the page read aloud to you and note every instance where you, as a sighted person, would have to guess. Typical findings include buttons without names, images with file names as descriptions, and error messages that are only highlighted by colour.

Document each finding with the page, element, and expected behaviour. This list forms the basis for implementation.

Make Testing a Routine

Include the keyboard test in your acceptance criteria. Every new page should be operated without a mouse before publication. This habit prevents old errors from returning.

Anyone who has operated their site once without a mouse immediately understands accessibility.

Why Accessibility is More Than Just a Compliance Tick Box

Common opinion often reduces accessibility to a legal obligation, a box that must be ticked. However, this perspective overlooks its immense potential. Accessibility is a quality feature that improves the user experience for everyone. A website optimised for screen readers is often better structured, faster, and easier for every visitor to understand. It is about designing digital products to be usable by the widest possible range of people. This includes individuals with different abilities, technical setups, and situational limitations.

In Austria and the entire DACH region, there is a continuously growing number of people who rely on assistive technologies. Around 1.8 million Austrians live with a disability, many of whom have visual impairments. For companies, this means that a significant portion of potential customers or users are excluded if digital offerings are not accessible. For example: An online bank in Vienna recorded a 15% decrease in support enquiries after the accessible redesign of its banking portal, while simultaneously increasing online transactions by 8%. This shows that investments in accessibility can have direct positive effects on business by increasing efficiency and opening up new target groups.

What Role do Semantic HTML and ARIA Play in Screen Reader Tests?

Semantic HTML and ARIA (Accessible Rich Internet Applications) are the cornerstones for effective screen reader usage. Semantic HTML means using the correct HTML elements for their intended meaning. An <h1> for the main heading, <p> for paragraphs, <button> for buttons, and <nav> for navigation. This automatically provides screen readers with the necessary information about the structure and function of the content. ARIA complements this semantic information, especially for complex UI components that cannot be adequately described with pure HTML. ARIA attributes such as role="alert", aria-label, or aria-expanded convey additional meanings and states to assistive technologies.

A concrete example illustrates this: A development team in Graz initially used Div elements with JavaScript for an accordion menu. Screen readers could read the content, but could not recognise that these were expandable sections or which section was currently active. By switching to <details> and <summary> for the basic functionality and adding aria-expanded and aria-controls for the dynamic states, the accordion suddenly became fully accessible. Users could now identify with the screen reader whether a section was expanded and control it specifically. This approach significantly improves usability, even for non-screen reader users who benefit from a clearer structure.

Checklist for Semantic HTML and ARIA in Your Screen Reader Test

Are headings structured hierarchically and logically (H1, H2, H3, etc.)?
Are lists (<ul>, <ol>) used correctly, not just simulated with line breaks?
Are form fields linked to appropriate <label> elements?
Do interactive elements such as buttons or links use the corresponding HTML tags?
Are icons or pure graphic links provided with an alt text or aria-label that describes their function?
Are ARIA roles and states used correctly, especially for dynamic content like tabs, modals, or accordions?
Avoid unnecessary or superfluous ARIA that can confuse semantics.

How Do I Effectively Test Forms and Interactions with Screen Readers?

Forms are critical elements of any website. For screen reader users, however, they often present barriers if not implemented correctly. An effective test focuses on simulating the entire completion process: from navigating to the form to submitting it. Each form field must have a clear, programmatically linked label. Screen readers should clearly announce the field type and any requirements, such as "required field". Error checks must be both visual and auditory, ideally with aria-live regions that announce error messages immediately.

Let us consider the registration form of an online shop in Salzburg. During an initial test round, a screen reader user found that error messages after submission were only coloured red but not read aloud. The focus also did not automatically jump back to the first erroneous field. By adding aria-describedby for the error message and setting the focus using JavaScript, this problem was resolved. Additionally, aria-required for mandatory fields and a visible legend for asterisks (*) were implemented. This allowed blind users to complete the form independently and without frustration. Such detailed interaction tests are crucial to identify and remedy real barriers.

Steps for Form Testing with a Screen Reader

Navigate through the entire form with the tab key and arrow keys.
Check whether each field has a descriptive label and whether the screen reader reads it correctly.
Verify that mandatory fields are marked as such and read aloud.
Test input in different field types (text, radio buttons, checkboxes, dropdowns).
Provoke errors and check whether error messages are clearly and promptly announced by the screen reader and whether the focus is set correctly.
Test the submission of the form and the confirmation message.
Ensure that the focus jumps to a meaningful position after submission or after errors.

What Typical Problems Occur with Images, Graphics, and Multimedia?

Images, graphics, and multimedia content are common stumbling blocks for screen reader users. The most frequent problem is the absence of alternative texts (alt attributes) or their insufficient quality. An alt text should describe the image in its context, not just "Image" or the file name. Decorative images should have empty alt attributes (alt="") so that they are ignored by screen readers. For complex graphics, such as infographics or diagrams, an extensive description on the page itself or via a link is often required, as the alt text alone is not sufficient. For video and audio content, subtitles, transcripts, and audio descriptions are essential. Without these aids, essential information remains hidden for deaf, hard of hearing, or blind users.

A project for a tourism portal in Styria contained numerous images of landscapes and activities. Initially, the images had generic alt texts such as "Landscape_01.jpg". A test with VoiceOver showed that blind users had no idea what was in the pictures. After a revision, the alt texts were refined: "Picturesque alpine meadows with mountain views in the Salzkammergut" or "Family hiking by a mountain lake". For an image video, a transcript and subtitles were added. The result: Accessibility increased significantly, and user engagement measurably improved, as all visitors could fully grasp the content. The investment in high-quality alternative texts and multimedia accessibility paid off here and shows that accessibility is also a benefit for tourism offerings.

Checklist for Images, Graphics, and Multimedia

Do all informative images have meaningful alt texts?
Are decorative images provided with alt="" so that screen readers ignore them?
Is there a text alternative or detailed description for complex graphics or diagrams?
Are subtitles and transcripts available for video and audio content?
Is there an audio description for videos that contain important visual information?
Can media players be operated exclusively via the keyboard (play, pause, volume)?

Can Automatic Tools and AI-Based Checks Replace Manual Testing?

Automatic accessibility tools and AI-based checks are valuable aids, but they cannot fully replace manual screen reader testing. They are excellent at identifying technical errors such as missing alt attributes, insufficient colour contrast, or missing form labels. They can quickly scan large numbers of pages and provide an initial overview of obvious deficiencies. This speeds up the audit process and helps find the most common and easily rectifiable problems. They are also indispensable for recurring routine checks or as part of a CI/CD process.

However, they reach their limits when it comes to contextual meaning, logical reading order, or usability. A tool can detect that an alt attribute exists, but cannot judge whether the content "Image 123" is meaningful. It also cannot feel how frustrating it is when a complex menu is cumbersome to operate with a screen reader. A team in Zurich initially relied exclusively on automated tests and thereby missed serious navigation problems that were only uncovered through manual screen reader tests with real users. An experienced person interacting with a screen reader can assess the actual user experience and identify problems that no algorithm can find. Therefore, a combination of automated checks and thorough manual tests is the most effective approach to ensure a truly accessible website. For a more detailed insight into working with AI, we recommend our article on AI Strategy Without Hype.

What Role Do Colour Scheme and Contrast Play in Accessibility?

Colour scheme and contrast play a decisive role in accessibility, especially for people with visual impairments, colour blindness, or users in bright environments. Insufficient contrast between text and background makes content difficult or even impossible to read. This affects not only plain text but also icons, links, and buttons that represent important information or interactive elements. The Web Content Accessibility Guidelines (WCAG) define clear minimum contrast ratios (at least 4.5:1 for normal text and 3:1 for large text or UI components) that must be met to ensure adequate readability. Furthermore, colours should never be the sole means of conveying information. If an error message is only indicated by red colour, it is not recognisable for colour-blind individuals.

A digital town hall in Upper Austria had introduced a new design based on light grey text on a white background, which was intended to appear elegant. However, initial feedback from citizens showed that many had difficulty reading the content. A quick contrast check revealed that the contrast was far below the WCAG standard. By adjusting the font colour to a darker grey, the contrast could be brought to the required level without destroying the overall design. In addition, important status messages, which were previously only colour-marked, were supplemented with an icon and an explanatory text. Such adjustments are often easy to implement but have an immense impact on accessibility and the acceptance of the offering by users.

Checklist for Colour Scheme and Contrast

Does the contrast of text to background meet WCAG guidelines (min. 4.5:1)?
Does this also apply to text in graphics or logos, if they are informative?
Are important information or states not conveyed exclusively by colour (e.g., links, error messages, active menu items)?
Is the contrast of icons and UI elements (e.g., checkboxes, radio buttons) sufficient (min. 3:1)?
Can users customise colour schemes if this is relevant for the target group?

Integrating Accessibility into the Development Process: Here's How

Accessibility should not be an afterthought, but integrated into the development process from the outset. This begins as early as the conception phase and design, where wireframes and mock-ups are checked for their accessibility. When accessibility "shifts left" in the process, errors are easier and more cost-effective to fix. It requires a rethink across the entire team: designers consider contrast and logical order, developers use semantic HTML and ARIA, and editors write meaningful alternative texts. Regular training and the involvement of accessibility experts are essential here. A discovery workshop at the beginning of a project can help define these requirements early on, see also our article on the Discovery Workshop.

A software company from Vienna implemented an "Accessibility Champion" programme. In each team, a developer or designer was trained as an accessibility officer. These champions served as contact persons and promoted awareness within the team. They conducted regular mini-audits and organised knowledge transfer sessions. Within six months, the number of accessibility bugs decreased by 40%, and the time to fix the remaining errors was reduced by 25%. This example shows that integrating accessibility as an integral part of the project culture and through dedicated roles increases efficiency and significantly improves the quality of the end product. The initial investment in training and internal processes pays off through more sustainable and more accessible products.

Checklist for Integrating Accessibility into the Process

Are accessibility guidelines part of the design system and style guides?
Are accessibility aspects already considered in user stories or requirements?
Do developers conduct code reviews with a focus on accessibility?
Are automated accessibility tests integrated into the CI/CD pipeline?
Are manual screen reader tests regularly performed by trained individuals?
Is there a process for managing and fixing accessibility bugs?
Are teams regularly trained in accessibility?

Additional Tools and Resources for In-Depth Screen Reader Tests

Beyond the standard tools mentioned, there are a number of advanced tools and resources that can help with in-depth screen reader tests. For Windows, the NVDA Screen Reader is a free and very popular alternative to Narrator, used by many professional testers. For checking contrast ratios, there are tools like the WebAIM Contrast Checker or Lighthouse in the Chrome browser. Browser extensions like "axe DevTools" or "WAVE Evaluation Tool" can also perform initial automated analyses directly in the browser. For mobile tests, the respective built-in tools (TalkBack on Android, VoiceOver on iOS) are the first choice. Furthermore, numerous online resources, such as those from W3C WAI, offer detailed instructions and best practices.

A development team in Linz, working on a complex web application, used the "Accessibility Inspector" function in the Chrome and Firefox developer tools in addition to manual testing. This function visualises the Accessibility Tree, which screen readers use, making it quickly apparent what information a screen reader receives about an element. This helped the team find hidden semantic errors and ARIA misconfigurations that might have been easily overlooked in purely manual testing. By using these specialised tools, the accuracy of the tests was increased, and the quality of the application was significantly improved. This shows that a combination of manual testing, basic built-in tools, and specialised analysis tools brings the greatest success.

We at Zensations would be happy to advise you comprehensively on this topic. Whether it is about technical implementation (Website Implementation with AI) or if you would like strategic advice on integrating accessibility into your company (Digital Consulting). Contact us, and we will find the right steps together.

Further Useful Tools and Resources

WebAIM: Extensive resources and a Contrast Checker
Axe DevTools (Browser Extension): Automated accessibility checks
WAVE Evaluation Tool (Browser Extension): Visual representation of accessibility problems
Lighthouse (in Chrome DevTools): Audit function including accessibility
Accessibility Tree (in Browser DevTools): Visualises how the screen reader understands the page
W3C WAI Tutorials: Detailed instructions and examples

Frequently Asked Questions

Does this replace a professional audit?

No, but it significantly reduces the number of obvious deficiencies.

How much time does the test take?

30 to 60 minutes are sufficient for a typical user journey.

Who in the team should test?

Editorial, design, and development teams together, because the causes lie in all three areas.

Your Next Step

Would you like to implement this topic for your company? We will examine your initial situation, name the three most effective measures, and tell you the effort and timeframe. Write to us at office@zensations.at or start with the free GEO Check.