WebAIM - Web Accessibility In Mind

E-mail List Archives

-recommendationsforscreenreadertraining?

for

From: Dean.Vasile
Date: Mar 26, 2024 7:54AM

Tim, that is excellent advice.
I just want to add a little bit more to it so people have better understanding.
I’ve been testing with my screen reader for a couple of years now and I find that using JAWS or NVDA the experience changes depending on the browser you are using on the website They say that NVDA works better with Firefox however I’ve noticed that some websites work better when you use chrome and NVDA on it and JAWS definitely works better with chrome
I actually have issues with both of them using Microsoft edge.
However, I test with that as well.
So keep all that information in mind when testing with a screen reader and as Tim recommends
Involve Actual screen reader users in your testing because they will have a completely different experience than a tester that only uses the screen reader for testing

Dean Vasile


617-799-1162

> On Mar 26, 2024, at 9:19 AM, <EMAIL REMOVED> wrote:
>
> I want to offer some general advice about screen reader testing.
>
> You should think of screen reader testing like browser testing. The goal of browser testing generally is to determine if the site or application is working as expected. You don't conduct browser testing with the expectation that you will understand the user experience. The same is true about screen reader testing.
>
> You should focus your screen reader testing on determining if the site, application, document, or whatever is working as expected. That does mean you need to learn about what the expectations are for accessibility. If you are wanting to understand the user experience of people using screen readers, you need to test involving people who use screen readers.
>
> It will take time and effort to learn both how to use a screen reader and what those accessibility expectations are. However, I think you will end up with better results if you focus your screen reader testing on meeting accessibility requirements and then conduct user testing for understanding the user experience.
>
> Another thing to keep in mind is that screen reader testing isn't just about screen readers. Many assistive technologies rely to some degree on the programmatic information provided by user interfaces. Screen readers differ in that they tend to rely more heavily on that programmatic information. It would be nice if you could test with all assistive technologies. However, if you cannot, testing with a screen reader (with an understanding of how other assistive technologies use that information) can sometimes help you find issues that might impact other assistive technologies as well.
>
> When you start testing with a screen reader, be aware of the nature of screen readers. The primary intent of screen readers are to help people with disabilities access interface. Their primary intent is not for testing. This means that screen readers often will add features that are intended to help someone with a disability use a broken site or application. You want to be aware of this because you don't want the accessibility of your digital content to rely on these features. These features are never as good as just making the content accessible. These features can vary between screen readers which means one might have the feature and another one does not.
>
> Thanks!
> Tim
>