Screen Reader Optimization: Making Your Website Readable
Screen readers translate visual web content into spoken language or braille output and are the central tool for blind and visually impaired people to use the internet. In Germany, approximately 1.2 million (project experience) blind and visually impaired people live (DBSV, 2024), worldwide over 2.2 billion (WHO, 2024). Yet according to the WebAIM Million Report (2024), 96.3% (WebAIM, 2025) of all websites have problems that significantly hinder or prevent screen reader use. Screen reader optimization is a central component of BFSG compliance and simultaneously improves SEO and overall code quality.
How Screen Readers Interpret Websites
Screen readers analyze the browser's accessibility tree, a representation of page content independent of visual presentation. This tree is built from the DOM and ARIA attributes and contains a role, name and state for each element. A button labeled Submit is represented in the accessibility tree as Role: Button, Name: Submit, State: not pressed.
The quality of the accessibility tree depends directly on the quality of the HTML code. Semantic HTML elements like Screen reader users navigate fundamentally differently from sighted users: they jump between headings (H key), landmarks, links (K key), forms (F key) and lists via keyboard shortcuts. A website that has no semantic headings, no landmarks and no labeled form fields is unusable for these navigation patterns. ARIA landmarks define the main areas of a web page and enable screen reader users to navigate directly to a specific area. The most important landmarks are Semantic HTML5 elements create these landmarks automatically: A common error is the missing The heading hierarchy is the most important navigation tool for screen reader users. Screen reader users can jump between all headings on the page via keypress, gaining a quick overview of page structure. According to a WebAIM survey (2024), 67.5% (WebAIM, 2025) of all screen reader users use headings as their primary navigation method. The hierarchy must be logically structured: each page has exactly one In practice, this means: the visual styling of headings is controlled via CSS, not via the HTML level. If an WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) extends HTML with attributes that provide assistive technologies with additional information about the role, state and properties of elements. The most important rule when using ARIA is: native HTML first. A The most common ARIA attributes in practice are A common error is excessive ARIA: elements receive roles and attributes that native HTML already provides. This can lead to conflicts when the screen reader receives contradictory information. The second rule of ARIA is: do not change the semantics of an element unless necessary. An banner, navigation, main, complementary, contentinfo, search. Semantic HTML5 elements create these automatically. h1 through h6 in logical order. 67.5% (project experience) of all screen reader users primarily navigate via headings. aria-live=polite for updates, assertive for urgent messages. Announce dynamic content without reload. Informative images with descriptive alt text. Decorative images with alt="". 55% (project experience) of all websites fail here. Link text describes the destination. No generic Click here. For icons: aria-label or visually-hidden text. caption, th with scope, summary. Layout tables with role=presentation. Complex tables with headers/id. Modern web pages frequently update content without full page reload: a cart counter changes, an error message appears, a chat window shows a new message. Screen reader users do not notice these changes unless they are explicitly announced. ARIA live regions solve this problem by instructing the screen reader to automatically read changes in a specific DOM area. The attribute Implementation requires care: the live region must already exist in the DOM before the content changes. If a container is only created at the time of the change and given The The quality of alt text depends on context. A product image in an online shop needs descriptive alt text like Red running shoes, side view. A decorative background image needs an empty For complex images like infographics or charts, the Forms are particularly challenging for screen reader users. Screen readers switch to forms mode when entering a form field, disabling regular navigation shortcuts. In this mode, the user relies entirely on programmatic field labeling. Every field must have a linked Error messages must be linked to the affected field via Custom widgets like date pickers, autocomplete fields and multi-step selectors require complete ARIA implementation. A date picker needs Screen reader tests are an indispensable part of the WCAG audit. The relevant screen readers are those available in Windows, macOS, iOS and Android -- from the free Windows screen reader through the screen reader built into macOS and iOS to the commercial Windows market leader. According to the WebAIM Screen Reader User Survey (2024), around 40.5% (WebAIM, 2025) use the commercial Windows screen reader, 37.7% (WebAIM, 2025) the free Windows screen reader and 12.0% (WebAIM, 2025) the macOS/iOS screen reader as their primary tool. A systematic screen reader test includes complete page navigation via keyboard, checking all landmarks and headings via screen reader shortcuts, running through all forms in forms mode, testing dynamic content and live regions, verifying all images and media content for alt text and validating the reading order. Each screen reader behaves slightly differently: the Windows screen readers use a virtual cursor in browse mode, the macOS screen reader uses a rotor for structural navigation. What is correctly read on Windows may sound different or be missing on macOS. Therefore we recommend testing with at least two different screen readers. The combination of a Windows screen reader and the macOS screen reader covers the majority of users. According to the WebAIM Million study (2025), 96.3 percent of examined homepages have at least one automatically detectable WCAG error affecting screen reader users. The five most common problems are: missing alternative text on images, missing labels on form fields, empty links, missing document language and low color contrast. While contrast primarily affects visually impaired users, the other four errors directly and severely impact the screen reader experience. The most common problem is the missing connection between visual presentation and semantic structure. A visual card design with image, heading and link is often read as a series of unconnected elements rather than coherent content. The solution: implement the entire card element as an Another common problem is modal dialogs that do not trap focus. When a modal opens but the screen reader user can still reach the underlying page, confusion arises. Modal dialogs need Icon buttons without text labels are a third standard problem. A close button showing only an X symbol, a hamburger menu button without text and social media links with only a logo are unidentifiable for screen reader users. The solution: , , , , and automatically create the correct roles. A automatically has the role button and is keyboard-operable, while a ARIA Landmarks: Orientation on the Page
banner (header), navigation (navigation bars), main (main content), complementary (sidebar), contentinfo (footer) and search (search area). Each page should have exactly one main landmark, one banner landmark and one contentinfo landmark.banner, becomes navigation, becomes main, becomes complementary and becomes contentinfo. When a page contains multiple navigations, such as main navigation and footer navigation, each should be named via aria-label so screen reader users can distinguish them. element. Without this landmark, screen reader users cannot jump directly to the main content and must traverse the entire navigation on every page load. The element should wrap all page-specific content but not contain header, footer and navigation. Correct landmark structure is the foundation of all accessible web development.Heading Hierarchy: Page Structure
element as the main heading. Below follow elements for main sections, for subsections and so on. No level may be skipped. An must not follow an directly without an intervening . This rule is frequently violated when heading levels are chosen for visual reasons rather than structural ones. should visually appear smaller than an , this is solved with CSS classes. The HTML level remains strictly oriented to the logical document structure. Automated testing tools check heading hierarchy, but only manual testing reveals whether the hierarchy is also semantically meaningful.ARIA Roles, States and Properties
element is always better than a aria-label for non-visible labels, aria-describedby for additional descriptions, aria-expanded for collapsible elements, aria-hidden="true" for hiding decorative elements, aria-current for the current page in navigation and aria-live for dynamic content. Each of these attributes has a specific use case and should not be applied indiscriminately. does not need role="link" as it already has this role.Landmarks and Regions
Heading Hierarchy
Live Regions
Alt Text for Images
Meaningful Links
Accessible Tables
Live Regions: Announcing Dynamic Content
aria-live="polite" waits until the screen reader finishes its current output, then reads the change. This is the correct mode for most updates: status messages, form validation, search suggestions and cart updates. aria-live="assertive" immediately interrupts the current output and should only be used for critical messages such as error states or timeouts.aria-live, the change will not be announced. The container is inserted into the DOM once (can be empty), and content changes are then automatically read. In single-page applications, the page navigation update is a typical use case for a live region.Alt Text: Describing Images in Words
alt attribute for images is the best-known accessibility feature and simultaneously the most frequently missing. The WebAIM Million Report (2024) finds that 55.4% (WebAIM, 2025) of all tested websites have missing or inadequate alt text. For screen reader users, a missing alt attribute means the screen reader reads the filename, which is often cryptic and useless.alt="" so the screen reader skips it. An image in an article showing a graphic or chart needs detailed alt text that puts the presented information into words.alt attribute is often not sufficient. Here aria-describedby is useful, pointing to a text block containing the detailed description. Alternatively, a Making Forms Accessible for Screen Readers
element. Groupings like salutation (Mr./Ms.) need a with .aria-describedby, so the screen reader automatically reads the error message when the field receives focus. Required fields are marked with aria-required="true" or the native required attribute. Error status is communicated via aria-invalid="true". After form submission, focus must be set to the error summary or the first erroneous field.role="dialog", aria-label for the month view, keyboard navigation with arrow keys and Escape to close. The complexity of these implementations is a main reason why using native HTML elements wherever possible is the better choice.Testing with Different Screen Readers
Common Screen Reader Problems and Solutions
or , so the screen reader recognizes the connection.role="dialog", aria-modal="true", aria-label or aria-labelledby, a focus trap keeping focus within the modal and return to the triggering element on close.aria-label for the button or visually hidden text with the CSS class .sr-only (or .visually-hidden) that describes the element's purpose.Related Articles