WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: NVDA and auto-switching of reading modes

for

From: Birkir R. Gunnarsson
Date: Nov 21, 2015 6:27PM

If, by overlay, you mean dialog or alertdialog (you can verify this by
seeing whether he attribute role="dialog" or alertdialog is present on
the visible overlay container).
NVDA automatically switches into forms mode when its focus is moved
inside a dialog container (regardless of what type of element inside
the container receives focus).
Jaws does not do this.
This is an NVDA decision, one which I disagree with after seeing
countless users frustrated and confused by not being able to explore
the overlay in their virtual buffer.
The confusion is compounded because most NVDA users use the escape key
to switch from interactive/formms mode to browse mode.
But a dialog that implements full keyboard accessibility is closed
when use presses the escape key.
Therefore, when the user tries to switch modes in NVDA, he closes the
dialog he is trying to explore.
This can be resolved if the user switches modes by pressing the NVDA
key and spacebar (instead of the escape key), but many users are not
fully aware of that shortcut.

I would not call this a failure if the developer is providing correct
roles, labeling and focus management.
NVDA made this decision for their users, and I think it might be due
for a discussion/review.
My recommendation for screen reader vendors would be to keep auto
switching to forms mode only when the alertdialog role is used, not
when the dialog role is used.
I can write a whole article about why, in fact I have, I just haven´t
published it.
Cheers
-B



On 11/20/15, Lucy Greco < <EMAIL REMOVED> > wrote:
> are you sure that the over lay does not have the role of application
> witch is why this should normally happen and yes the default for nvda is to
> let the user know the mode has changed with sounds
>
> On Fri, Nov 20, 2015 at 4:52 AM, _mallory < <EMAIL REMOVED> > wrote:
>
>> On Fri, Nov 20, 2015 at 04:20:48AM -0600, Joe Chidzik wrote:
>> > I can see to potentially resolve this would be to simply change the
>> button to a link, which shouldn't invoke focus mode, but don't want to
>> suggest this if it is not necessary.
>> >
>> Semantically I would argue this cannot be a link. It performs a
>> scripty function on the page (button) instead of navigating to
>> a URI (link).
>>
>> I think it's a setting, but I get various sounds/beeps when switching
>> between modes.
>>
>> _mallory
>> >> >> >> >>
>
>
>
> --
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
> > > > >


--
Work hard. Have fun. Make history.