Demystifying screen reader use for manual testing

Who are we?

Session Objectives

Why This Topic Matters

Screen reader testing is essential for accessibility, but requires specialized skills most professionals lack

After this session, you will:

1. Gain Basic Screen Reader Skills
2. Understand Different Navigation Approaches
3. Communicate Accessibility Issues Effectively

Session Overview

• 01 Screen Reader Usage Statistics
• 2-3 Native Visual vs Native Screen Reader Users' Experiences
• 04 Screen Reader Basics: NVDA, VoiceOver, mobile
• Screen Reader Practice 1: Screen Reader Ropes Course
• 05 The Visual/Screen-reader Disconnect
• 06 Screen Reader Testing Tips
• 07 Documentation and Remediation Strategies
• Screen Reader Practice 2: The World is Your Oyster
• 08 Additional Resources

Visual Surfer Experience - 2

Informative vs Interactive elements

Informative = get info as quickly as possible

• Headings
• Images
• Pull quotes

Interactive = the mind groups according to past interactions

• Forms
• Sliders (ignore)
• Videos (consider whether to play)
• Accordions, tabs, etc, sort of like headings

First Impressions – My Initial Arrival

• Hearing the Title: The very first thing my screen reader tells me is the page title. This gives me my initial clue about what the page is about.
• Dealing with Immediate Announcements: Sometimes, I immediately hear alerts like cookie notices or modal windows asking me to sign up for something. I have to address these first.
• Confirmation of Loading: My screen reader then usually says "Document" or "Page loaded," letting me know the content is there.
• Starting at the Top: My screen reader's focus is automatically at the very beginning of the page.

Getting My Bearings – Exploring Structure

• Jumping Through Headings: I immediately start using my heading navigation commands (like pressing "H"). This gives me a quick outline of the page's main sections and how the information is organized.
• Finding the Landmarks: I also navigate by landmarks (using "R" or my screen reader's landmark navigation). This helps me quickly locate the main navigation, the main content area, and the footer.

Taking Stock – What's on the Page?

• Listing the Links: One of the first things I often do is bring up a list of all the links. This tells me where I can go on this page and what other sections exist. Clear link text is vital here.
• Checking the Buttons: I also look at the list of buttons to see what actions I can perform. Well-labeled buttons are essential.
• Identifying Form Fields: If I suspect there's a form, I'll check for a list of text fields, checkboxes, and dropdowns.
• Reviewing Headings Again: Sometimes, a list of headings provides a clearer overview than just jumping through them.

Moving Through the Content

• Tabbing Through: I use the Tab key to go through all the interactive elements in order. This helps me understand the flow and make sure everything is reachable with the keyboard.
• Reading Line by Line: If the structure is confusing or I need to understand the details, I'll use the arrow keys to read the content word by word or line by line.
• Listening to Element Types: My screen reader tells me what kind of element I'm on – a link, a button, an image, etc.
• Paying Attention to Labels and Alt Text: I really rely on the labels for form fields and the alternative text for images to understand what they are.

Getting Things Done – Interaction

• Using the Keyboard: I use Enter to click links and buttons, Spacebar for checkboxes, and type into text fields.
• Looking for Feedback: After I do something, I listen carefully for any messages that tell me if it worked, if there were errors, or if something changed on the page.
• Navigating Complex Parts: For things like tabs or expanding sections, I try to figure out the keyboard commands, hoping the website uses accessibility standards.

Questions I'm Always Asking Myself

1. What's this page about?
2. What are the main parts of this page?
3. Where can I go from here?
4. What can I do on this page?
5. How is the information organized?
6. How do I move through the interactive parts?
7. What information do I need to put in this form?
8. What's this image showing me?
9. Did that button click work?
10. Is this website making sense to me?

What I'm Trying to Achieve

1. To understand the purpose and content.
2. To find my way around and know what I can do.
3. To get a mental picture of how things are laid out.
4. To be able to interact with elements and complete tasks.
5. Ultimately, to have a usable and efficient experience.

Common Themes in My Web Surfing

• Structure is Key: If a website is well-structured with headings and landmarks, it's much easier for me.
• Words Matter: Clear labels and good alt text make a huge difference.
• Keyboard is Everything: I can't see the mouse, so keyboard navigation has to work.
• I Need to Know What Happened: Feedback after I interact with something is vital.
• Accessibility Makes or Breaks It: How easy a website is for me depends directly on how accessible it's been designed.
• I'm Always Problem-Solving: I often have to figure out unconventional layouts or poorly implemented features.

Screen Reader Basics: NVDA, VoiceOver, Mobile

• Please install NVDA if you have a Windows machine (VoiceOver is preinstalled on Macs)
• www.nvaccess.org/download/
• We'll go over some history while you're doing that

Screen Reader History - 1

• 1984 - Personal Computer Synthetic Audio Interface Driver (PC-SAID) was renamed IBM Screen Reader and was the first PC screen reader, from which the term "screen reader" is derived
• 1989 - Job Access With Speech (JAWS) was developed for Windows
• 2000 - Narrator for Windows 2000+
• 2005 - VoiceOver for MacOS (since 2009)
• 2006 - Nonvisual Desktop Access (NVDA) open-source for Windows

Screen Reader History - 2

• Present - Narrator keeps getting better, but JAWS is still the most popular ($$$*) with NVDA a runner up; VoiceOver is still Mac's only option.
• Mobile devices since 2009 have VoiceOver (iOS), and Talkback (Android)

*Personal license = $104.50/year, Professional license = $2267.50 one-time

Screen Reader Basics for NVDA

Turn on (open application from Start menu, or Ctrl + Alt + N)*

Navigation

• Sequentially (up and down arrow keys)
• Continuously (NVDA {caps or insert} + down arrow, escape to stop)

Navigate by element type (single key, or shift + single key)

• Heading (H, 1-6)
• Landmark (D)
• Link (K)
• Button (B)
• Form Field (F)†
• Checkbox (X) - space to select
• Table (T) - then ctrl+alt+arrows
• List (L)
• List Item (I)
• Image/Graphic (G)

*I think, if your laptop has an Insert key, choose Desktop layout to be able to use Insert as NVDA key, NVDA + Q to quit

†F will also go to other fields: inputs, check boxes…

Screen Reader Basics for VoiceOver (with QuickNav)

Turn on (command + triple-click fingerprint sensor)

Navigate Safari for best results (activate QuickNav - left-right at once)

• Sequentially (left and right arrow keys)
• Continuously (VO* + A) *VO = control+option, or caps lock

Navigate by element type (single-key, or select type with up-left or up-right at once, then up and down, up-down to interact)

• Heading (H, 1-6)
• Link (L)
• Button (B)
• Checkbox (C)
• Form Field (F)*
• Table (T) - then VO + arrows
• Controls (J)*
• List (X)
• Image/Graphic (G)
• Interact (up-down)
• *Forms: up-down to interact, left-right to disable QuickNav to type
• Tables: in order to move around the table you need to press VO + arrow key, or lock VO by control-option-semicolon
• Controls: Input, buttons

Screen Reader Basics for VoiceOver (standard)

Turn on (through A11y settings, or command + triple-click finger)

• Navigate Safari for best results
• Continuously (VO* + A) *VO = control+option, or caps lock
• Lock VO for one-handed use = VO + ;
• Sequentially (VO + left and right arrow keys)
• By element type (VO + U and arrows for different elements in the rotor, enter to jump to the selected element)
• In the rotor, on new element type, press up to find out how many of those are on the page
• Use many of the single keys with VO + Command + key
• VO + shift + down/up to enter or leave an element,
• VO + space to activate an element (like a link)

Screen Reader Basics for VoiceOver for iOS

Turn on (triple-press side or home if you set it up thus)

Navigation

• Continuously (two-finger: swipe down=read, tap=pause)
• Sequentially (swipe right or left)
• By element type (swipe down or up)
• Interact by single-finger tap (activate link/button, interact with edit box, etc)

Navigate by element type

Choose options in Settings > Accessibility > VoiceOver > Rotor > Rotor Items

To select element type to navigate by: rotate 2 fingers like turning dial

• Headings
• Paragraphs
• Controls
• Links
• Landmarks
• Tables
• Controls: Input, buttons

Screen Reader Basics for TalkBack for Android

Navigation

• Continuously (triple-tap with two fingers)
• Sequentially (swipe right and left)
• By element type (swipe down or up)
• Interact by single-finger tap (activate link/button, interact with edit box, etc)

Navigate by element type

Choose options in TalkBack settings > Customize reading

Select element type to navigate by: swipe up-then-down

• Headings
• Paragraphs
• Controls
• Links
• Landmarks
• Tables
• Controls: Input, buttons

Common Screen Reader Blockers

• Visual content that has no text alternative
• Functional elements that cannot be controlled with a keyboard
• Overly complex or excessive amounts of content
• Inability to navigate within a page of content
• Content that is not structured
• Inconsistent navigation
• Time limits (insufficient time to complete tasks)
• Unexpected actions (e.g., redirect when an element receives focus)
• Multimedia without audio description

Screen Reader Practice 1: Screen Reader Ropes Course

seamonsterstudios.com/screen-reader-ropes-course

1. Turn your screen reader on
2. • NVDA: open in Start menu (or control+alt+n)
   • VoiceOver: command+f5 (or command + triple click fingerprint)
3. Try each keystroke on your cheat sheet a couple times
4. Activate the screen curtain and try each again
5. • VO: three-finger triple-tap, NVDA: through settings
   • Screen curtain for VO: enable trackpad commander by VO + rotate two fingers clockwise on trackpad, then three-finger triple tap
6. Plan a time when you'll come back and go through the entire Ropes Course with all the tasks

The Visual/Screen-reader Disconnect - 1

• Goals are the same
• Informative - get the info
• Interactive - perform the interactions
• The experience is on a different plane
• varied fluency = vastly different experience
• Paired testing is essential
• Variety of pairings is optimal
• Every user is different

Embracing the Disconnect

• Embrace the disconnect
  • Chance to tease out the differences
  • Chance to see the site experience as a whole (different perspective)
  • Chance to hammer out what would be the optimal experience for both
• But what if you don't have a native screen reader user to test the site?
• That's why you're here!

Screen Reader Tips

Kosi's Contextualizing Tips

• Turn Off the Screen & Rely on Audio
• Embrace Keyboard-Only Navigation
• Build a Mental Map Using Headings and Landmarks
• Browse Mode vs Forms Mode
• Develop Patience and Practice Mental Rehearsal
• Pay Attention to Dynamic Content and Focus Management
• Pay Attention (generally)

Without a native tester

In the absence of a native screen reader paired tester

• Realize you're not getting the full picture
• Put yourself in the place of a native screen reader user as best you can
• It's better than not trying
• Every site you test for accessibility you should test with at least one screen reader
• Preferably test it with two or more
• Know that it's still not the full picture

Know What "Correct" Should Sound Like

When navigating with a screen reader, you should hear:

• Role — What is the element? (e.g., button, heading, link)
• Name/Label — What is its purpose? (e.g., "Search", "Continue")
• State — What condition is it in? (e.g., "selected", "disabled", "checked")

If you're hearing all three (when appropriate), the element is likely coded accessibly.

What Appropriate Screen Reader Output Sounds Like (By Element)

Screen Reader Announcements

Element Type	Expected Announcement
Heading	"Heading level 1, Welcome"
Link	"Link, Contact Us"
Button	"Button, Add to Cart"
Image (with alt text)	"Graphic, Woman walking with cane"
Checkbox	"Checkbox, Subscribe to newsletter, not checked"
Tab	"Tab, Details, selected"
Dropdown	"Combo box, Choose a country, United States"
Dialog	"Dialog, Are you sure you want to delete this item?"
Table cell	"Row 2, Column 1, Monday"

Warning Signs That Something Is Wrong

If you hear the following, the element may be inaccessible:

Problems indicated by screen reader announcements

What you hear	What's Likely Wrong
"Link" (with no label)	Empty or missing link text
Heading level 2, blank	No heading content or improperly styled heading
"Graphic" with no alt text	Image missing alt attribute
Button with no name	Missing label or aria-label
Form field with no context	No label element or aria-labelledby used
No feedback on toggle state	Missing aria-pressed, aria-expanded, etc.
Silent interactions	No screen reader feedback means missing roles/states

Remember: Wording May Vary Slightly

Screen readers may phrase things differently, but as long as the essential information is there (role, name, state), you're likely hearing it correctly.

When in Doubt: Ask These Questions

• Did the screen reader announce what the item is? (e.g., link, heading, button)
• Did it tell you what the item is called?
• Did it describe what state the item is in (e.g., selected, required, expanded)?
• Did anything feel confusing, repetitive, or silent when it shouldn't have?

If you answer "no" to any of those, the page likely has accessibility issues.

Documentation Basics

• Spreadsheet (easiest for you)
• Word doc (easiest for remediation devs)
• What to include about the problem:
  • Name of problem
  • Contextualize in user experience
  • Screenshot
  • Code snippets
    • Current/problematic
    • Ideal

Documentation Basics - 2

What to include about the suggestion:

• Potential fix or what the new code should look like
• Explanation of the better experience the fix will provide to screen reader users
• updated experience

Documentation Downloads

• Spreadsheet - whatever you use now
• Word/Google Doc - https://bit.ly/sr-rec
• Give them both!
• Some people think in spreadsheets
• The rest of us just want some plain language
• Plain language is especially helpful in exploring the experience
• Help devs and owners imagine the experience
• Check out our Experiential Imagination Guide (https://bit.ly/sr-eig)

Screen Reader Practice 2: The World is Your Oyster

• Navigate to the website of your choice
• Your own, your favorite, the bane of your existence
• Turn your screen reader on
• NVDA: control + alt + n
• VoiceOver: ⌘-f5 (or command + triple click fingerprint)
• Try each keystroke on your cheat sheet a couple times
• Activate the screen curtain and try each again
• Plan a time on a regular basis to practice with your screen reader
• a dedicated half-hour a week will develop your proficiency and let you emulate a native better

Questions and Answers

• Let's connect!
• Deneb Pulsipher
• deneb@seamonsterstudios.com
• https://www.linkedin.com/in/deneb-pulsipher
• Kosi Asabere
• asabe20a@gmail.com
• https://www.linkedin.com/in/kosi-asabere/

Additional Resources

• California School for the Blind Screen Reader Training Course https://srt.csb-cde.ca.gov/index.html
• Paul J Adam's HTML Accessibility Obstacle Course https://pauljadam.com/demos/obstacle-course.html

Screen Reader Expected Announcements and Behavior

This section outlines what a screen reader typically announces during navigation and interaction. Use it as a mental checklist to confirm that you're hearing the right information, and to spot potential accessibility issues when elements are incorrectly coded.

1. Basic Page Navigation Elements

Page Loading

• Expected Announcements:
  • "Page title: [title text]" (first thing when page loads)
  • "Document loaded" or "Ready" (when page finishes loading)
• How to Tell Something is Wrong:
  • No page title announced — you won't know what page you're on.
  • No confirmation when loading finishes — you may be unsure if the page is ready.

2. Headings

Back to options

Expected Announcements:

• "Heading level 1, [heading text]" (for the main page title)
• "Heading level [2–6], [heading text]" (for sections)

How to Tell Something is Wrong:

• You hear "Heading level [number], blank" — the heading exists but has no text.
• Skipping heading levels when moving by heading (e.g., from level 1 to 4) — indicates poor structure.

3. Links

Back to options

Expected Announcements:

• "Link, [link text]"
• "Link, [link text], visited" (for visited links)
• "Link, graphic, [alt text]" (for image links)

How to Tell Something is Wrong:

• You hear "Link" with no description — the link text is missing.
• You encounter a clickable area that isn't announced as a link — improper coding.

4. Images

Back to options

Expected Announcements:

• "Graphic, [alt text]" (for meaningful images)

How to Tell Something is Wrong:

• Critical images (like buttons made of images) are completely silent — means no accessible label.

5. Buttons

Back to options

Expected Announcements:

• "Button, [button text]"
• "Button, [name], pressed" or "not pressed" (for toggle buttons)
• "Button, [name], disabled" (for inactive buttons)

How to Tell Something is Wrong:

• You hear "Button" with no name — the button label is missing.
• Toggle buttons do not announce whether they are pressed or not — state is missing.

6. Form Controls

Back to options

Expected Announcements:

• "Edit, [label]" (for text fields)
• "Edit, [label], required" (for required fields)
• "Password edit, [label]" (for password fields)
• "Edit, [label], invalid entry" (for fields with errors)
  • You hear "Edit" but no label — you don't know what information to enter.
  • Form errors (e.g., missing fields) are not announced — validation feedback is missing.

7. Checkboxes and Radio Buttons

Back to options

Expected Announcements:

• "Checkbox, [label], checked" or "not checked"
• "Radio button, [label], selected" or "not selected"
• "Group, [group name]" (for radio button sets)

How to Tell Something is Wrong:

• The checkbox or radio button name is missing — you can't tell what you're selecting.
• Selection status (checked/unchecked, selected/not selected) is not announced.

8. Select Menus and Comboboxes

Back to options

Expected Announcements:

• "Combo box, [label]"
• "Combo box, [label], [selected option]"
• "Expanded" (when the menu is opened)

How to Tell Something is Wrong:

• No announcement when you open a dropdown — screen reader can't tell it's expanded.
• Options are hard to distinguish or unannounced.

9. Lists

Back to options

Expected Announcements:

• "List with [number] items"
• "List item, [text]" for each item

How to Tell Something is Wrong:

• Lists are not recognized — the screen reader treats them like normal paragraphs.
• List items are not announced individually.

10. Tables

Back to options

Expected Announcements:

• "Table with [number] rows and [number] columns"
• "Row header, [text]" or "Column header, [text]" when moving through cells

How to Tell Something is Wrong:

• Cells are announced without row/column context — users can't understand how data is organized.
• The table sounds like a plain grid with no relationships.

11. Landmarks and Regions

Back to options

Expected Announcements:

• "Navigation landmark"
• "Main landmark"
• "Banner landmark"
• "Contentinfo landmark" (for footers)
• "Search landmark"

How to Tell Something is Wrong:

• You can't jump quickly between major sections.
• Landmarks aren't announced — the page feels like one long stream of content.

12. Tabs

Back to options

Expected Announcements:

• "Tab list"
• "Tab, [name], selected"
• "Tab panel, [name]"

How to Tell Something is Wrong:

• Tabs are not announced as a list.
• You don't know which tab is selected.

13. Dialogs and Modals

Back to options

Expected Announcements:

• "Dialog" or "Dialog, [title]"
• "Alert dialog, [message]"
• "Button, Close" (for dismissal)

How to Tell Something is Wrong:

• Modal popups appear but are not announced — users have no clue that focus shifted.

14. Expandable Content (Accordions, Details/Summary)

Back to options

Expected Announcements:

• "Button, [heading], collapsed" or "expanded"
• "Disclosure triangle, [summary]"

15. Menus

How to Tell Something is Wrong:

• Content expands or collapses visually but no change is announced by the screen reader.

Back to options

Expected Announcements:

• "Menu" or "Menu bar"
• "Menu item, [name]"
• "Menu item, [name], has popup"
• "Menu item, [name], expanded"
• How to Tell Something is Wrong:
  • Menu structure isn't announced — it sounds like isolated links.
  • Submenus open but no announcement of expanded state.

16. Dynamic Content and ARIA States

Back to options

Expected Announcements:

• "Updated content" (for polite or assertive updates)
• "Status message" (for temporary updates)
• "Progress bar, [percentage]"

How to Tell Something is Wrong:

• Dynamic updates happen, but the screen reader stays silent.
• No notification of progress changes or busy indicators.

17. Common Scenarios

Back to options

Search Functions

• "Edit, Search, [placeholder]"
• "Button, Search"
• "Search results, [count] items"

You may notice something is wrong if:

• You can't tell when a search completes.
• Results or no-results feedback is missing.

18. Learning and Practicing Tips

Back to options

• Start simple: Focus first on headings, links, and buttons.
• Listen carefully: Missing roles, names, or states signal accessibility problems.
• Notice patterns: Good sites have consistent, logical announcements.
• Practice repeatedly: Use accessible sites like gov.uk or Deque University.

Final Reminder

If at any time you cannot tell:

• What an element is,
• What its purpose is, or
• What its state is,

then something is wrong with the accessibility — and it can be detected without seeing the page, simply by listening.