Screen Reader

A screen reader is an assistive technology that reads digital content aloud or converts it into braille output.

It helps users, especially visually impaired users, navigate websites, understand content, interact with forms, and operate UI without relying on visual display alone.

Screen Reader = Converts screen content into spoken or braille feedback

One-line idea: Screen Reader = Assistive technology that depends on semantic HTML and careful ARIA to explain web content clearly.

Core Concepts

Why It Matters

Screen readers work only when the website is built with proper accessibility practices.

If HTML structure, labels, headings, images, forms, and ARIA are incorrect, the screen reader experience becomes confusing or broken.

Good screen reader support helps users:

• understand page structure
• move between headings and landmarks
• identify links, buttons, and form fields
• understand images through alt text
• receive updates from dynamic content

Practical Examples

VoiceOver Example

VoiceOver is a screen reader used to navigate and interact with web content.

It helps users move through the page, listen to content, understand controls, and interact with elements using keyboard shortcuts.

Accessible UI -> VoiceOver can explain the page clearly
Inaccessible UI -> VoiceOver may miss or announce wrong information

The main idea is simple:

Screen readers depend on meaningful HTML.

Important Shortcuts

Screen readers provide shortcuts to move quickly through page content.

Command	NVDA Key	VoiceOver Key
Stop audio	Control	Control
Read next / previous	↓ or ↑	VO + → or ←
Start reading	NVDA + ↓	VO + A
Element list / Rotor	NVDA + F7	VO + U
Landmarks	D	VO + ⌘
Headings	H	VO + Command + H
Links	K	VO + Command + L
Form controls	F	VO + Command + J
Tables	T	VO + Command + T
Within tables	NVDA + Alt + ↓ ↑ ← →	VO + ↓ ↑ ← →

These shortcuts work better when the page has correct semantic structure.

Accessible HTML

Accessible HTML means using the correct HTML element for the correct purpose.

This helps screen readers understand what each part of the page means.

Correct HTML = Better screen reader output

Document Structure

Use semantic layout elements instead of using generic div everywhere.

Important semantic elements:

• header
• nav
• main
• section
• article
• footer

These elements define clear regions and help assistive technologies navigate the page.

<header>Website Header</header>

<nav>Navigation Links</nav>

<main>
  <section>
    <article>Content</article>
  </section>
</main>

<footer>Footer</footer>

Headings

Headings provide structure to the page.

Screen reader users often navigate using headings, so heading order should be logical.

Important rules:

• use one h1 for the main title
• follow proper hierarchy
• do not use headings only for styling

<h1>Main Title</h1>
<h2>Section</h2>
<h3>Subsection</h3>

Lists

Use lists when showing grouped items.

This allows screen readers to announce list structure and number of items.

Important rules:

• use ul for unordered lists
• use ol for ordered steps
• use li for each item

<ul>
  <li>HTML</li>
  <li>CSS</li>
</ul>

Links and Buttons

Links and buttons should not be used interchangeably.

Use links for navigation.

Use buttons for actions.

<a href="/about">Go to About</a>

<button>Submit</button>

Avoid using clickable div elements for actions.

Navigation -> anchor tag
Action -> button tag

Form Elements

Forms must have proper labels so screen readers can explain what input is required.

Important rules:

• use label
• connect label with input using for and id
• make the input purpose clear

<label for="email">Email</label> <input id="email" type="email" required />

Without a label, a screen reader user may not know what the field is for.

Tables

Tables should be used for structured data, not layout.

Important rules:

• use caption to describe the table
• use th for headers
• use thead and tbody for structure

<table>
  <caption>
    Student Data
  </caption>

  <thead>
    <tr>
      <th>Name</th>
      <th>Marks</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>Aman</td>
      <td>90</td>
    </tr>
  </tbody>
</table>

This helps screen readers understand rows, columns, and table meaning.

Images

Images should include alternative text.

Important rules:

• use meaningful alt text for important images
• use empty alt="" for decorative images
• do not leave out the alt attribute

<img src="dog.jpg" alt="Dog playing in park" />

Alt text helps users understand image meaning when they cannot see it.

Audio and Video

Multimedia content should be accessible to users who cannot hear or see it.

Important practices:

• provide captions for videos
• provide transcripts for audio
• include subtitle tracks where needed

<video controls>
  <source src="video.mp4" />
  <track kind="subtitles" src="sub.vtt" />
</video>

ARIA

ARIA stands for Accessible Rich Internet Applications.

ARIA improves accessibility for custom UI components and dynamic content when semantic HTML is not enough.

It helps screen readers understand:

• what an element is
• what it does
• what state it is currently in

Simple Rule

Use semantic HTML first. Use ARIA only when native HTML cannot express the meaning properly.

ARIA Labels

ARIA labeling helps screen readers understand form controls or buttons when native labels are not enough.

aria-label

Provides a direct text label.

Useful when no visible label exists.

<button aria-label="Close menu">X</button>

aria-labelledby

Refers to another element's ID for labeling.

Preferred when visible text is already present.

<h2 id="dialog-title">Delete item</h2>

<div role="dialog" aria-labelledby="dialog-title">Are you sure?</div>

aria-describedby

Adds extra description, hint, instruction, or error message.

<input id="email" aria-describedby="email-error" />

<p id="email-error">Please enter a valid email address.</p>

Roles, Properties, and States

ARIA has three important parts.

Type	Meaning	Example
Role	What the element is	role="button"
Property	Extra information about the element	aria-describedby="id-ref"
State	Current condition of the element	aria-pressed="true"

Role example

<div role="button">Open menu</div>

This tells the screen reader that the element should be treated like a button.

But using a real button is better when possible.

State example

<button aria-pressed="true">Bold</button>

This tells assistive technology that the button is currently pressed.

Live Regions

Live regions announce dynamic content updates without a page reload.

Common values:

Value	Meaning
polite	Announces after current speech finishes
assertive	Interrupts and announces immediately
off	No announcement

Useful cases:

• notifications
• chat messages
• form validation updates

<div aria-live="polite">Item added to cart</div>

Use assertive carefully because it interrupts the user.

Important ARIA Rules

• Always prefer semantic HTML first.
• Use button instead of role="button" when possible.
• Use label instead of aria-label when a visible label can be used.
• Use ARIA only when necessary.
• ARIA adds meaning, not functionality.
• Incorrect ARIA can break accessibility.

ARIA does not make a div behave like a button.
It only tells assistive technology what the element means.

Summary

Screen Reader = Assistive technology that depends on semantic HTML and careful ARIA to explain web content clearly.

Good screen reader support =
semantic HTML
+ meaningful labels
+ logical headings
+ alt text
+ correct controls
+ careful ARIA
+ dynamic update announcements