Free Screen Reader Preview

Paste HTML to see how a screen reader would linearize and announce it. Check your alt text, headings, and ARIA attributes.

Screen Reader Output

Paste HTML and click Analyse.
📚 Research Basis & Sources

Who This Tool Is Designed For

Screen readers are essential assistive technology for people who are blind or have significant vision impairment. According to the WHO World Report on Vision (2019), at least 2.2 billion people worldwide have a near or distance vision impairment, of whom approximately 43 million are blind. The WebAIM Screen Reader Survey (2024) consistently finds that the vast majority of screen reader users are people with disabilities, with blindness being the most common reason for screen reader use. Developers, designers, and content creators use this tool to preview how their HTML will be interpreted by assistive technology � helping identify missing alt text, improper heading structure, unlabelled form controls, and ARIA misuse before they reach end users.

How This Tool Works

This tool parses your HTML using the browser�s native DOMParser (no data leaves your device), then walks the accessibility tree to build a linearized reading order. It checks for images missing alt text, headings that skip levels, links and buttons without accessible names, ARIA roles and labels, and form inputs without associated labels.

Research Citations

  • WebAIM (2024). "Screen Reader User Survey #10 Results." webaim.org � The largest ongoing survey of screen reader usage patterns, browser combinations, and accessibility barriers. Consistently finds that headings and landmarks are the primary navigation strategies used by screen reader users.
  • World Health Organization (2019). World Report on Vision. � Reports that at least 2.2 billion people globally have a near or distance vision impairment, of whom approximately 43 million are blind.
  • Power, C., Freire, A., Petrie, H. & Swallow, D. (2012). "Guidelines are only half of the story: Accessibility problems encountered by blind users on the web." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). � Found that a significant proportion of accessibility problems encountered by blind users were not covered by WCAG guidelines alone, emphasising the need for manual review and screen reader testing.
  • Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). "What frustrates screen reader users on the web: A study of 100 blind users." International Journal of Human-Computer Interaction, 22(3), 247�269. � Identified missing alt text, unlabelled form fields, and misleading link text among the top frustrations reported by blind web users.
  • W3C WAI (2023). "WAI-ARIA Authoring Practices 1.2." � Defines how roles, states, and properties should be used to make dynamic content accessible to assistive technology.

Disclaimer

This tool provides a simplified approximation of screen reader output based on the HTML accessibility tree. Real screen readers (NVDA, JAWS, VoiceOver, TalkBack) differ in how they announce content, handle ARIA attributes, and interact with dynamic widgets. This preview does not replace testing with actual screen readers and real users. It is intended as a development aid to catch common issues early in the authoring process.

A short history of web accessibility standards

Accessibility on the web is governed by a small stack of standards from the W3C Web Accessibility Initiative (WAI), plus national laws that reference them. WCAG 1.0 was published in May 1999, the first formal guidance on making web content accessible. It was largely HTML-centric and quickly became dated. WCAG 2.0 (December 2008) was a major rewrite organised around four principles (Perceivable, Operable, Understandable, Robust) and three conformance levels (A, AA, AAA). It became an ISO standard (ISO/IEC 40500) in 2012 and is the conformance target most laws still reference. WCAG 2.1 (June 2018) added 17 new success criteria covering mobile, low vision, and cognitive disabilities. WCAG 2.2 (October 2023) added 9 more, notably 2.4.11 Focus Not Obscured and 3.3.8 Accessible Authentication. WAI-ARIA 1.0 was finalised in March 2014; 1.2 in June 2023 is the current Recommendation. On the legal side, the US Section 508 Refresh (January 2018) incorporated WCAG 2.0 AA into US federal procurement. The European Accessibility Act (Directive 2019/882) came into force on 28 June 2025, requiring most consumer-facing digital products in the EU to meet accessibility standards. Most countries reference WCAG, so building to WCAG 2.2 AA is the practical target for any global product today.

The screen reader landscape today

The WebAIM Screen Reader User Survey #10 (2024) is the canonical source on which screen readers people actually use. Five products dominate desktop, mobile, and ChromeOS.

  • JAWS (Freedom Scientific, first released 1989) is the long-standing commercial leader on Windows. Costs ~$1000+. WebAIM 2024 finds it the primary screen reader for around 40% of survey respondents, slightly below NVDA.
  • NVDA (NV Access, first released 2006, written in Python) is the open-source Windows alternative. Free. WebAIM 2024 reports it as the most-used primary screen reader, around 47% of respondents. NVDA's growth from a niche tool to market leader in 15 years is one of the great open-source success stories in assistive tech.
  • VoiceOver (Apple, 2005 on macOS, 2009 on iOS) ships built-in on every Mac, iPhone, iPad, Apple Watch, Apple TV. It is the most-used mobile screen reader. Tightly integrated with Safari and the iOS rotor for navigation.
  • TalkBack (Google, 2009 on Android) is the Android counterpart. Open-source since Android 4. Uses gestures and the navigation menu.
  • ChromeVox (Google, 2012) and Narrator (Microsoft, 2000, modernised in Windows 10) round out the picture. Each has a small but loyal user base.

A single page can be announced differently by every product. Robust pages test cleanly in at least two: usually NVDA + Firefox or Chrome, and VoiceOver + Safari.

When to reach for this tool

  • Pre-launch audits. Paste a key page (homepage, signup form, checkout) and read the linearised output aloud. If it doesn't make sense to you, it won't make sense to a screen reader user.
  • Code reviews. Before merging a PR with significant markup changes, paste the rendered HTML and confirm headings, landmarks, and alt text survived intact.
  • Design handoff verification. Designers can paste their final HTML to confirm that visual hierarchy matches semantic hierarchy. A page that looks like a heading should also be one in the DOM.
  • Teaching accessibility. Show a class or a team what a screen reader actually receives. The gap between visual layout and linearised output is often the first time non-disabled developers understand why semantic HTML matters.
  • Compliance checks against WCAG. Quick spot checks for the four most-violated criteria: 1.1.1 Non-text content (alt text), 1.3.1 Info and Relationships (semantic structure), 2.4.4 Link purpose, 4.1.2 Name, Role, Value.
  • CMS / no-code site checks. Visual editors often produce divs-instead-of-headings or links-with-no-text. Paste the published HTML, see what slipped through.
  • Email template accessibility. HTML emails are notoriously hard to make accessible. Use the preview to verify alt text on every image, proper heading order, and readable reading flow.

Common mistakes screen readers expose

  • Missing or useless alt text. alt="image", alt="photo", alt="logo" are barely better than nothing. Lazar et al. (2007) identified missing alt text as the top frustration of blind web users. Write alt text that conveys the purpose of the image in the surrounding context, or use alt="" for purely decorative images so the screen reader skips them.
  • Heading levels that skip or restart. Going from h1 to h3 skipping h2 confuses navigation. Using multiple h1 elements on the same page (a fairly common pattern in component-driven design) breaks the document outline that screen reader users navigate by. WebAIM 2024 finds that headings are the most common navigation strategy for screen reader users.
  • Divitis. Wrapping clickable text in <div> with a click handler instead of using <button> or <a> means no keyboard support, no focus ring, no role announcement. Always start from semantic HTML and add ARIA only when no native element fits.
  • ARIA used where HTML would do. First rule of ARIA (per W3C WAI-ARIA Authoring Practices): «if you can use a native HTML element... do so». <button role="button"> is redundant; <div role="button"> is a sign you should use a real button instead.
  • ARIA used incorrectly. aria-hidden="true" on a focusable element makes it invisible to screen readers but still keyboard-focusable, a recipe for a disorienting tab order. role="button" without tabindex="0" and keyboard handlers does nothing useful.
  • Form inputs without labels. An <input> without an associated <label>, aria-label, or aria-labelledby is announced as «edit, blank» with no context. Placeholder text is not a substitute, it disappears on focus and often fails contrast.
  • «Click here» and «read more» links. Screen reader users often navigate by pulling up the list of all links on the page. «Click here» alone tells them nothing. Make link text describe the destination: «Read the 2024 WebAIM survey» beats «Read more here».
  • Removing focus styles. outline: none without a replacement focus indicator is one of the most-violated WCAG criteria (2.4.7 Focus Visible). Keyboard users, including many screen reader users, need to see where focus is.

ARIA at a glance: what each kind of role does

  • Landmark roles (banner, navigation, main, complementary, contentinfo, search) divide the page into regions a screen reader user can jump between. Most have native HTML equivalents (<header>, <nav>, <main>, <aside>, <footer>). Use the native element first.
  • Widget roles (button, checkbox, combobox, menu, tabpanel, etc.) describe interactive controls. Widget roles imply keyboard interaction patterns that the W3C ARIA Authoring Practices Guide (APG) documents in detail. If you cannot match the APG spec exactly, prefer native HTML.
  • Document structure roles (article, list, listitem, row, cell, etc.) describe non-interactive content. Most also have native HTML equivalents. Use them only when the native element is unavailable (e.g. building a custom data grid where <table> doesn't fit).
  • Live regions (aria-live="polite", aria-live="assertive", role="status", role="alert") tell screen readers to announce dynamic updates without moving focus. Used for chat messages, form errors, loading states. Overuse causes notification fatigue; reserve assertive for genuine emergencies like error states.

More frequently asked questions

Does this preview match what NVDA / JAWS / VoiceOver will actually say?

It approximates. This tool reads the browser's accessibility tree (the same structure screen readers use) and produces a linearised version of what would be announced. Real screen readers add product-specific behaviours: announcements of focus changes, table navigation, table headers, list item counts, ARIA-live politeness handling, custom verbosity settings. Treat the preview as a first-pass sanity check; for production launches, test with at least one real screen reader on the operating systems your audience uses.

What's the difference between WCAG and ARIA?

WCAG (Web Content Accessibility Guidelines) is a list of requirements: «every non-text content must have a text alternative». It tells you what to achieve but not always how. ARIA (Accessible Rich Internet Applications) is one of the tools for meeting WCAG: a set of HTML attributes (roles, states, properties) that expose semantics to assistive technology when native HTML is insufficient. You can meet WCAG with no ARIA at all if your HTML is semantic enough. ARIA is for the cases where it isn't.

How do I write good alt text?

Three rules from W3C's An alt Decision Tree: (1) If the image is purely decorative, use alt="" so the screen reader skips it entirely. (2) If the image conveys information not already in surrounding text, describe that information concisely (typically under 125 characters). (3) If the image is functional (e.g. a logo that links to home, or an icon button), describe the action rather than the appearance. «Search» beats «magnifying glass icon». Avoid «image of...», «photo of...», screen readers already announce that the element is an image.

My site uses divs everywhere. Where do I start?

Start by adding the five landmark elements: <header>, <nav>, <main>, <aside>, <footer>. Then replace clickable divs with <button> (for actions) or <a> (for navigation). Then audit headings: every page should have one <h1> and the rest in nested order. These three steps fix maybe 70% of accessibility problems on a typical div-heavy site. ARIA and JavaScript focus management come after, once the semantic foundation is in place.

Is the HTML I paste here sent anywhere?

No. Parsing uses the browser's built-in DOMParser and the analysis runs entirely client-side. Open the Network tab in DevTools and click Analyse, you will see zero outbound requests during the linearisation. Safe for internal templates, unreleased pages, or HTML containing customer data.

Related Tools

WCAG Heading Checker Accessibility Resources Accessible Palette Color Contrast Checker