A screen reader is assistive software that converts digital content into synthesized speech or Braille output. It traverses the DOM (Document Object Model) and announces elements based on their semantic role, not their visual appearance. For example, an <h1> is announced as "Heading level 1," a <button> as "Button," and an <img> reads its alt attribute. Popular screen readers include JAWS, NVDA (Windows), VoiceOver (macOS/iOS), and TalkBack (Android). This simulator helps developers preview how their markup sounds.

The alt attribute provides a text alternative for images. When a screen reader encounters an image, it announces the alt text. If alt is missing, some screen readers fall back to reading the filename (e.g., "IMG_2024_photo.jpg"), which can be confusing. An empty alt="" tells the screen reader to skip the image entirely — ideal for purely decorative images. Best practice: always include meaningful alt text for informative images and use alt="" for decorative ones. This tool highlights images with missing alt attributes so you can fix them.

The aria-label attribute overrides the visible text content for assistive technologies. For instance, a link with visible text "Click here" but aria-label="Learn more about accessibility" will be announced as "Learn more about accessibility — Link." This is powerful for providing context that sighted users get visually. However, overusing aria-label can create confusion if it diverges too far from visible text. Our simulator respects aria-label and shows you exactly what gets announced.

aria-hidden="true" completely hides an element and all its children from screen readers — even if the element is visually displayed. This is useful for hiding decorative icons, redundant text, or off-screen content that should not be announced. However, never use aria-hidden on focusable elements (like links or buttons), as this creates a confusing experience where a user can tab to something the screen reader won't announce. Our simulator skips aria-hidden="true" elements entirely, just like real screen readers.

Screen readers allow users to jump between headings using shortcut keys (e.g., H key in JAWS/NVDA). Each heading is announced with its level: "Heading level 1," "Heading level 2," etc. A logical heading hierarchy (h1 → h2 → h3, without skipping levels) is essential for accessible navigation. Skipping from h1 to h4 can disorient users. Use this simulator to verify your heading structure is announced correctly and in proper order.

Screen readers announce links (<a>) with "Link" after the text, signaling navigation. Buttons (<button>) are announced with "Button," signaling an action. This distinction is crucial: use <a> for navigation (moving to another page/section) and <button> for interactions (submitting forms, toggling menus). Styling a <div> to look like a button without role="button" makes it invisible to screen readers as an interactive element — a common accessibility failure.

When a user focuses on a form input, the screen reader announces the associated label, the input type ("edit text," "checkbox," "combobox"), and its state (required, disabled, checked). Always pair <input> with a <label> using the for attribute or by nesting. Without a proper label, screen readers may only say "edit blank," leaving users guessing what to enter. Our simulator shows you how form elements are announced, including placeholder fallbacks when labels are missing.

This simulator is an educational and preview tool — it helps you understand how screen readers interpret HTML, but it does not replace formal accessibility testing with real assistive technology. For WCAG 2.1 / ADA compliance, you should test with actual screen readers (NVDA is free on Windows, VoiceOver is built into macOS/iOS), use automated checkers like axe-core or WAVE, and conduct manual keyboard-only navigation tests. Think of this tool as a fast "first pass" to catch obvious semantic issues before deeper testing.