In October 2025, my colleague Joe from UsableNet led a live webinar where he demonstrated what it is like to use a screen reader on a real website.
During the session, Joe navigated a site in real time using his screen reader. Attendees heard exactly what he hears as he moved through headings, links, product grids, filters, forms, and pop-ups. We talked through what worked, what got in the way, and how small code and structural changes can have a significant impact on usability.
A lot of great questions came in during and after the webinar.
This blog collects some of the most common questions and gives me a chance to answer them in more detail, using my own experiences as a full-time screen reader user.
If you were not able to join us live, I recommend watching the webinar recording and then coming back to this Q&A. Hearing Joe’s screen reader output as you read these answers will make the points here more concrete. You can find the webinar recording in the resources section on the UsableNet website or by clicking this link to register to view the webinar.
Answer: Deciding between using the tab or arrow keys when navigating a webpage depends on the characteristics of the content being navigated.
For example, a user may navigate up and down within a list using the arrow keys but press the tab key to move to the following site section or interactive element.
Additionally, the functionality of tab key versus arrow key navigation can vary slightly from one screen reader to another. JAWS relies heavily on the tab key to move manually through a website, while Apple VoiceOver users often perform most web navigation using arrow key commands.
Like most things, personal preference also plays a part in this discussion.
Answer: Yes, screen reader users can repeat the last spoken item if it is missed or for further clarification.
Even as a full-time screen reader user, I find myself doing this all the time, especially when a lot is happening on a website or when I get distracted.
The process varies by screen reader. For example, JAWS has a speech history option that logs recent announcements that the screen reader made for later reference.
Answer: This is personal preference. Through the screen reader’s settings, the user can choose word echo, letter echo, or even no echo at all.
I personally have my systems set to echo only words when typing. It is helpful for sentence structure and flow to hear the words as I type them, but I do not necessarily need to hear each letter, as I type pretty quickly.
Answer: Screen reader users heavily customize and personalize their systems to work in the best and most efficient way for their particular needs and use cases.
This includes a combination of memorization, setting up shortcuts for the most commonly used programs and functions, and developing familiarity over time. That familiarity allows us to perform basic tasks, like opening a program, at the same level of second nature as a sighted user.
This balance is nuanced and varies significantly from person to person.
For example, when navigating the non-Internet portions of my computer, such as the desktop and internal file menus, I almost never tab or arrow through the options manually one by one. Instead, I have customized a set of shortcuts and gestures that let me quickly and efficiently access my most commonly used programs and functions.
For example, pressing two specific keys at the same time will open my computer’s email program, which I use frequently.
Answer: This repeated announcement phenomenon can happen for several reasons.
I have found that the most common is when a product image is given a text description that is a direct repeat of the product’s text title. This can cause the user to hear the same announcement twice if the item title and image occur consecutively in the navigation sequence.
If you want to hear what that sounds like in practice, the webinar recording includes several e-commerce examples in which Joe navigates product lists and detail pages with his screen reader. Watching the recording while you read this section can help connect the behavior you hear to the code behind it.
Answer: Sudden layout changes or radically different design languages often disorient us.
When this happens, we usually need to explore the new interface's layout and accessibility features before we can navigate swiftly and efficiently.
Layout and design consistency goes a long way for accessibility and usability. Sudden changes, whether within a website or across websites, can slow the user down.
However, we learn to employ specific strategies when this occurs, such as switching from filtered to manual navigation to hear every web element more clearly.
Ultimately, these sudden and jarring transitions are more manageable when the accessibility of the different interfaces is up to par.
Answer: Unfortunately, the answer is often yes, though accessible pop-ups do exist on some sites.
Some common issues include an inability to dismiss the pop-up with screen reader commands, unclear pop-up appearance, and incorrectly labeled call-to-action options.
When pop-ups are built accessibly, they may still be disruptive, but are much more manageable.
Read this blog on how to make pop-ups accessible.
Answer: Some of the most common issues I encounter on web forms are unlabeled or mislabeled fields, clunky navigation when moving around the various form sections, and an inability to hear user-entered data when reviewing entries before submission.
Web forms are almost always crucial for the effective use of a digital experience.
For more about this, read my blog, Accessibility Challenges When Interacting With Web Forms on Mobile
Therefore, when testing and designing for accessibility, a web form must behave the same way for screen reader users as it does for sighted users.
While this must be true of all types of sites, it is especially important on government and similar websites because the tasks that users perform on these platforms are often highly sensitive and must be completed both timely and accurately.
Recommended: Check out our resource hub for government and higher ed organizations.
Answer: Screen readers allow users to set a specific filter parameter and then move through the site, hearing only that specific type of web element.
Common examples include headings, links, and images. Each screen reader has its own method of setting the filtered navigation option.
For example, JAWS users can use certain keyboard letters to cycle through the page, such as the “H” key for headings. VoiceOver users can use the rotor and arrow keys to specify which web element to navigate by.
I personally use the button and text field options all the time. As an example, button navigation is very useful on a shopping website when I want to quickly locate the “Add to Cart” button while browsing a product details screen.
Answer: Whether or not this is annoying varies from person to person.
Screen readers have customizable settings that let users specify which punctuation is spoken aloud and which is skipped in favor of a cleaner speech readout.
I personally have some shortcuts set up that let me change these settings on the fly, because different digital experiences call for varying levels of need for hearing some or all punctuation.
To close, here is a summary of the main ideas behind these questions. I hope it is helpful if you are planning accessibility work or searching for practical screen reader guidance.
Keyboard navigation depends on context and preference.
Screen reader users switch between tab and arrow keys based on the content and the screen reader. A logical focus order, clear headings, and semantic structure support both styles.
Duplicate announcements usually come from duplicate information.
When an image description repeats the visible text, a screen reader will often read it twice. Clear and concise alt text helps avoid that.
Consistency in layout supports confidence.
Sudden changes in layout or interaction patterns are disorienting. Keeping navigation, headings, and key actions consistent across pages helps screen reader users move more quickly and with less guesswork.
Pop-ups and forms are common problem areas.
Inaccessible pop-ups that cannot be dismissed, unlabeled form fields, and difficulty reviewing entered information all create serious barriers. This is especially true on government and service websites where people are trying to complete essential tasks.
Screen reader settings are flexible, and users rely on that flexibility.
Features like word echo, punctuation settings, and custom shortcuts let each person work at their own pace and preferences. When a site is built with good structure, those tools work even better.
Ultimately, the more predictable and well-structured your website is, the easier it is for screen reader users to explore, learn the pattern, and complete the tasks they came to do.
If you have not watched the October 2025 webinar, a Screen Reader Demo of Good vs Poor Accessibility, you can register here to watch it in full.
Hearing Joe use his screen reader on real pages while you keep these questions in mind is a powerful way to understand what truly helps and what gets in the way.
This is a guest post from our marketing contributor, Michael Taylor. It reflects his opinions and experiences. Read more about Michael and some other posts on his experience online here.