Overcoming Screen Reader Testing

Reading Time: 5 minutes
computer volume indicator set to low
Zoomed-in photograph of a computer volume indicator set to a low volume.

I remember the first reaction I had when I started to work on a Web Accessibility project and did Screen Reader testing. So I turned on the Screen Reader for the first time, then I wanted to shut it down immediately. I got confused between what my eyes were reading and what my ears were hearing. Concentrating on both areas at the same time, the visual and the audio, was hard. Got worst when the Screen Reader was narrating and I was trying to speak, while screen sharing and presenting something.

A word for newcomers

It’s been a while since that, and I’m well adapted now. But that same reaction I had, I keep finding it whenever I have to coach newcomers to Web Accessibility. When explaining how to optimize, code, and then do Screen Reader testing to confirm vocalization. That perceivable embarrassment, when they can’t turn off the Screen Reader. So, I’m writing this article to quickly share a link with newcomers. What you feel is normal, and you will adapt the more you use it, but don’t turn it off. It’s like the first time using Windows coming from Mac, or vice-versa. Or switching from a native language to a new language. It feels like your brain stretches.

So, how do I turn it off, they ask? The answer is, “let it speak, that’s the whole point of Screen Reader testing”. Listening to the spoken representation of the User Interface, and then verifying if it’s equivalent to the visual experience. Emulating the listening experience, as Screen Reader users would experience it. Empathizing to emulate users is hard, it’s a process, and adaptation takes time, but it’s worth it. Then, patience and practice.

First Aid Kit

If you are seriously overwhelmed by the Screen Reader narration to the point where you just can’t focus on what you are doing. Then you could use the following tricks but don’t turn off the Screen Reader:

  • Press the Control key to pause it, works for all Screen Readers.
  • Turn down the volume and enable Speech Viewer for NVDA, comes free and can be enabled under “Tools” in the NVDA menu.
  • There is also JAWS Inspect for JAWS, which unfortunately has a cost.
  • If you are testing in VoiceOver for Mac, then you may already have seen the text output, so just turn down the volume.

Update on 11-22-2021, more aid tricks:

  • You could turn off the Speech Mode for NVDA. There are three Speech Mode settings so you can press Ins + S three times to cycle through them all.
  • On Windows 10, you could turn down the volume for just JAWS/NVDA with the “Sound and Volume Mixer” by right-clicking on the speaker icon on the system tray. Then select “Open Volume Mixer” to open it. Here you can change the volume for individual applications.

Uneasiness towards Web Accessibility

Sometimes I have also noticed that talking about Accessibility is uncomfortable for newcomers. Especially the user emulation part, it triggers different emotions ranging from fear to disdain. Going from “It’s scary to think about this, I don’t want to attract this”. Or “I can’t emulate because this will not happen to me, I don’t see myself there”. Well, on that, I guess it depends on the different authors we all read and our different points of view. Yet, Accessibility needs to be implemented, regardless. So, how do we break through this discomfort too?

Well, we have to be aware that, by avoiding or postponing Web Accessibility, either by omission or deliberately, we are discriminating against users with disabilities by preventing access to content or transactions. I know it’s a strong word, but that’s exactly what it is. In some jurisdictions, lawsuits would follow. Think of the users who can only use software with Screen Readers. They can’t turn it off.

Overcoming uneasiness

Last year I read author Brené Brown. In her book “Dare to Lead” she says discrimination comes as a result of shame. She proposes as an antidote for shame: Empathy and self-care. Understanding what triggers shame reduces its power, she says. I couldn’t agree more. It really sounds easy once placed in perspective. However, empathy is a process (it needs context, unlike sympathy). Self-care requires enough awareness for introspection, as well as a strong willpower.

So, it’s not easy to get to the antidote, although the effort is worth it. Nonetheless, sympathy is easy, because it doesn’t really require the context of “walking a mile in someone else’s shoes”. There, where we first need to learn how to tie those shoes, and the walking cadence. But sympathy is about caring and understanding.

Having said that, while working on the larger and well worth goal of removing shame, without being shameless. It should be sufficient to just be bold enough to have sympathy (caring). Understanding the fact that, we may be depriving users with disabilities of opportunities most users give for granted, and that is illegal in some places. It’s important to remember as well, that disabilities are something that can happen to anybody at any time in their lives. Accidents do happen to those born without disabilities, regardless of favourite authors or philosophical alignments. Also, most people in most cases, already know someone who was born with a disability.

Working in Web Accessibility projects gives the implementors a new perspective. Prepares them if a disability ever catches up with them, or puts them in a better position to help someone they know who was born with a disability. We implement Accessibility to empower users. Implementors are also users.

Empowering users with disabilities

While overcoming the uneasiness of the Screen Reader testing new surroundings, I suggest we always remember famous people with disabilities. Like Hellen Keller or Louis Braille. Back in their days, they were able to create systems to help, empower and inspire other people with disabilities. Shouldn’t it be easier now with the help of technology and the information we have at hand these days?

Brilliant minds like that of Stephen Hawking reached their highest point and popularity because they were empowered by the technology of their time, and by the people behind that technology.

As professionals involved in projects where Web Accessibility is implemented, we must focus on empowering users with the solutions we create in our daily work. Focus on making software everybody can use, just as intended for the physical world. If we plan for wheelchair ramps and automatic doors. Why not make sure keyboard navigation is provided as the first layer of Web Accessibility.

In his book “Outliers”, Malcolm Gladwell presents a series of interesting facts about successful people. We want to be successful as Web Accessibility implementors, don’t we? Gladwell writes about how they became “outliers”, and how the same formula can be applied to anybody, consisting mainly of 3 elements:

  • 10,000-Hour Rule: Practicing a skill for 10,000 hrs.
  • Generational opportunity: being there while key events are happening.
  • Help from others: People that will propel those skills into action.

So, this is the best time in a generation to start empowering people with disabilities by means of technology, it’s a key event. Their perspective, and their unique circumstances, will provide humanity with contributions that wouldn’t be possible otherwise. We, as implementors, must use our talents and skills to propel theirs. And yes, it takes time.

The Accessibility Advocate Checklist

Reading Time: < 1 minute
The hand of an Accessibility Advocate checking boxes on a checklist

This Accessibility Advocate Checklist is a compass. A non-thorough and non-technical Accessibility checklist for the person taking the role of Accessibility Advocate in a development team. All steps in this checklist lead to knowledge discovery for the Advocate as well as for team members.


  • Critical user journeys.
  • Testing cases and QA scenarios for Accessibility


  • All User Interface components have Keyboard Accessible Patterns.
  • User journeys are doable using only the keyboard.
  • Keyboard traps do not interrupt or prevent user journeys from being successful.
  • User journeys vocalize properly using a Screen Reader with keyboard navigation.
  • If the project is for government employees in a regulated environment.
  • VPAT document preparedness if required.
  • If we need the services of an Accessibility Test Center for this project.


  • Stakeholders are aware of the consequences of not complying with Accessibility requirements for this project.
  • The team is aware of the WCAG 2.1 level of compliance for this project.
  • Developers know where to find the Success Criteria and Techniques for WCAG 2.1.
  • Team members have a link to a predefined Accessibility Resource Center according to their roles.
  • There is a documented plan for gradually implementing Accessibility (a Roadmap).

What is an Accessibility Advocate

Reading Time: 3 minutes
5 people seated at a conference table watching a monitor.
Team of 5 people seated at a conference table examining a User Interface on a monitor.

A Web Accessibility Advocate, in the context of Software Development, is the team member in charge of raising awareness and increasing the Web Accessibility literacy of the team. Also ensuring that knowledge stays in the team.

Among the responsibilities of a Web Accessibility Advocate are the following:

  • Raise awareness of potential consequences of non-compliance,
  • Point team members to an Accessibility Resource Center based on their roles.
  • Run the Accessibility Advocate Checklist for all team’s projects.
  • Provide accessibility questions for interviewing job candidates.

There are similar “advocacy” roles in software development teams. Such as the “UX Advocate” role, following along the lines of the User Advocacy principle. These advocacy roles become handy especially when the Designers’ ratio in development teams is very low. Also, when designers are temporary contractors. Once delivering wires and visuals, they leave. Hence, the need for a developer, who also has “that” UX awareness, to take on that role.

All that said, the same principle applies to Web Accessibility. Consequently, any team member can take on the role of Accessibility Advocate. However, coding practices covered in the topic are better communicated from one developer to another. It’s best if a developer takes on that role. Still, it could be anybody.

When taking on the Web Accessibility Advocate role, the huge body of knowledge should not be intimidating. There is no need to understand it deeply when starting, not even the empathy part. There are tools and tricks to learn how to empathize. However, the reasons for taking the role should be clear and convincing. Not just because it’s fancy-sounding or a trend.

Why it’s important

First of all, is important to understand why Web Accessibility is important in software? besides the fact that it’s the right thing to do. The web has the potential to bring an unprecedented level of independence to people with disabilities. For them Web Accessibility is freedom. As IT professionals, one has the great opportunity to enable this independence for people with disabilities and improve their lives.

People with disabilities can’t easily leave their houses They may encounter barriers outside their homes. But they can perform tasks from their computers like working, shopping, banking. Even have access to entertainment or playing games online. But that’s only if the websites or the software are built with accessibility in mind.

There’s a different approach to Accessibility, that also renders results. By not worrying about being “nice” for a moment, and just focusing on being “smart”. Then embracing Web Accessibility to “show-off”, protect or build a brand. Most likely competitors are also doing their part in complying with Web Accessibility.

Plus, a clear benefit of building inclusive software is that it often results in a larger user base. Yes, more clients, due to the positive impact on more people’s lives.

Now, if the previous “nice” or “smart” reasons aren’t good enough to convince. Then, the “litigation avoidance” reason should prevail. Lawsuits for non-compliance are very common these days. Litigation is the most expensive way to implement accessibility.

All the previous goes to show, that being a Web Accessibility Advocate is a way of being proactive. By anticipating and preventing lawsuits for software companies and their clients.

How to start

Every process is different, niches vary, teams have their own personalities. In my experience, I have found that answering the following questions helps in shaping up the Advocate role. Also, they help to outline an Accessibility Roadmap.

  1. Who is the person that will take the role of Accessibility Advocate?
  2. Is our product static and likely to have flawless and durable 100% Accessible status?
  3. If our product evolves, when are regressions likely to happen?
  4. How do we “painlessly” dive into Accessibility Requirements to anticipate and reduce legal problems?
  5. How do we recognize the pitfalls to avoid?
  6. Accessibility is a practice, not a one-time project. So how do we know where to start and where to end the cycle?
  7. How do we know when we have arrived, or how much is left?
  8. Do we start from scratch or retrofit?
  9. Where will we build our Accessibility Resource Center? (Virtual space where we can pour in statistics, tips and tricks, references and painless approaches concerning Accessibility for our product).
  10. Review the Accessibility Advocate Checklist.