E-mail List Archives
Thread: Clarification on forms mode of screen readers
Number of posts in this thread: 4 (In chronological order)
From: Vemaarapu Venkatesh
Date: Tue, Jul 26 2016 6:11AM
Subject: Clarification on forms mode of screen readers
No previous message | Next message →
Hello all, Greetings
On the way to understand the interaction modes in JAWS, I got encountered
with few more uncertainities
From previous messages I got to know that screen readers will switch the
modes automatically and if that is the case no need to switch manually
which is happening perfectly.
Now as a screen reader user, when I am testing application using JAWS, it
starts guessing the things like the form lables and announce them even
though they are not associated. So, how the screen reader user will get to
know that the lable is programmatically labelled or not. Yes, if it is
labelled the label itself becomes clickable but how a screen reader user
will know as he can't click and JAWS even not announcing clickable when
focused to label text in virtual mode.
What I understood is if we turn off "virtual pc cursor" manually, JAWS is
rendering everything perfectly and I didn't find guessing behaviour in off
mode.
The same with "select country of residence" combobox example provided by me
in earlier messages.
My question is, whether I have to test all form elements by manually
turning off the virtual mode because I can't able to differentiate between
programmatically labelled elements and unlabelled elements in virtual mode.
But in NVDA I didn't find any such differences, form elements are similar
in both the modes. But I am finding difference in behaviour of JAWS not
only in form elements but also in few other contexts when I am manually
switching between virtual pc cursor on/ off.
Hope my concern is clear and clarify me about how to proceed my testing
with JAWS.
Regards,
venkatesh
From: Moore,Michael (Accessibility) (HHSC)
Date: Tue, Jul 26 2016 7:50AM
Subject: Re: Clarification on forms mode of screen readers
← Previous message | Next message →
If you are visually impaired and using a screen reader to test whether the form labels are properly associated with the form controls I recommend using NVDA to perform those tests. NVDA does not guess like JAWS does.
Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
From: Birkir R. Gunnarsson
Date: Tue, Jul 26 2016 8:01AM
Subject: Re: Clarification on forms mode of screen readers
← Previous message | Next message →
Hi
If you ar formally testing a webpage for accessibility, I recommend
you run an automated accessibility testing tool, such as aXe, on it
first.
The tool will catch and report issues such as when a label is not
provided for a form field. That is easier and more reliable than
relying on a screen reader to do that testing.
Then you can analyze the code behind the webpage in a couple of ways.
I wrote an article on how to inspect webpage code with a screen reader
and Firebug:
http://bats.fyi/2016/06/17/using-firebug-jaws-analyze-webpages/
I used to test with the Wave toolbar from WebAIM as well, but I have
not found a good and easy way to use it with Chrome, and it is no
longer available in Firefox (I heard a rumour that it may be coming
back, I will be excited when it does).
-B
On 7/26/16, Moore,Michael (Accessibility) (HHSC)
< = EMAIL ADDRESS REMOVED = > wrote:
> If you are visually impaired and using a screen reader to test whether the
> form labels are properly associated with the form controls I recommend using
> NVDA to perform those tests. NVDA does not guess like JAWS does.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
>
From: Léonie Watson
Date: Tue, Jul 26 2016 8:07AM
Subject: Re: Clarification on forms mode of screen readers
← Previous message | No next message
On 26/07/2016 13:11, Vemaarapu Venkatesh wrote:
> Now as a screen reader user, when I am testing application using JAWS, it
> starts guessing the things like the form lables and announce them even
> though they are not associated. So, how the screen reader user will get to
> know that the lable is programmatically labelled or not. Yes, if it is
> labelled the label itself becomes clickable but how a screen reader user
> will know as he can't click and JAWS even not announcing clickable when
> focused to label text in virtual mode.
When you test a website, you need to do two things:
1. Test the code to make sure it is correct.
In this case, make sure that a label has been provided for the form
field and that it is properly associated in the code.
2. Test to make sure it works with assistive technologies.
In this case, make sure that the correct label is announced by the
screen reader when focus moves to the form field.
>
> What I understood is if we turn off "virtual pc cursor" manually, JAWS is
> rendering everything perfectly and I didn't find guessing behaviour in off
> mode.
[...]
My question is, whether I have to test all form elements by manually
> turning off the virtual mode because I can't able to differentiate between
> programmatically labelled elements and unlabelled elements in virtual mode.
No. When you test it is important that you use the screen reader in the
way that people actually do. Most Jaws users do not manually turn the
virtual cursor on/off.
>
> But in NVDA I didn't find any such differences, form elements are similar
> in both the modes. But I am finding difference in behaviour of JAWS not
> only in form elements but also in few other contexts when I am manually
> switching between virtual pc cursor on/ off.
Jaws and NVDA do not behave the same all of the time. Jaws will also
behave differently depending whether you use it with IE or Firefox. They
both behave differently to VoiceOver on OSX/iOS.
This is why it's important to test both the code, and the experience of
using the site with an assistive technology.
Léonie.
--
@LeonieWatson tink.uk Carpe diem