E-mail List Archives
Thread: NVDA and auto-switching of reading modes
Number of posts in this thread: 8 (In chronological order)
From: Joe Chidzik
Date: Fri, Nov 20 2015 3:20AM
Subject: NVDA and auto-switching of reading modes
No previous message | Next message →
Hi all,
I've reviewed a page that makes use of an overlay. Focus is managed well, and the overlay works well with JAWS 16IE11.
When the overlay is opened, the dialog title is announced, and the focus is set to the overlay close button. At this point, arrowing down with JAWS will proceed to read through the overlay contents as expected. NVDA however, is switched into focus mode on opening the overlay (presumably by the focus being set to a control of type=button). As such, arrowing down simply scrolls the page, and does not read the overlay contents. It is necessary to toggle to browse mode via alt+space in order to start reading through the overlay.
I've raised this as a failure, but this comes down to user awareness. The only indication that the screenreader will have switched modes is the announcement of a button being selected which implies NVDA is in focus mode. Not being a native screenreader user, I don't know whether it is a reasonable assumption that allmanysome screenreader users will hear button being announced, and instinctively know to toggle back into browse mode to continue reading.
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.
So, question: Will screenreader users, by and large, be generally aware of toggling focus modes if something, like arrowing down to read content, isn't working?
Cheers
Joe
--
Joe Chidzik
Senior Accessibility & Usability Consultant | AbilityNet | www.abilitynet.org.uk<;http://www.abilitynet.org.uk/>;
Registered Charity No. 1067673 Scotland No. SC039866
Company Limited by guarantee registered in England and Wales No. 3469653
Registered Office: Acre House, 11/15 William Road, London NW1 3ER VAT No. 380597914
Follow us on Twitter: @AbilityNet | Facebook: www.facebook.com/abilitynet<;http://www.facebook.com/abilitynet>; | Support us online: https://mydonate.bt.com/charities/abilitynet
WARNING: AbilityNet has taken reasonable precautions to ensure no viruses are present in this email, but cannot, however, accept responsibility for any loss or damage arising from the use of this email or attachments. You are strongly recommended to carry out your own virus checks.
From: _mallory
Date: Fri, Nov 20 2015 5:52AM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
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
From: Lucy Greco
Date: Fri, Nov 20 2015 5:06PM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
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 ADDRESS 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
From: Birkir R. Gunnarsson
Date: Sat, Nov 21 2015 6:27PM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
From: Gijs Veyfeyken
Date: Mon, Nov 23 2015 1:40AM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
Until NVDA changes it's default behaviour, you can add a child <div role="document"> inside the parent <div role="dialog"> to force NVDA into browse mode.
Kind regards,
Gijs
---
Gijs Veyfeyken
AnySurfer - towards an accessible internet
http://www.anysurfer.be/en
Brussels - Belgium
From: Jonathan Whiting
Date: Mon, Nov 23 2015 9:55AM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
On Mon, Nov 23, 2015 at 1:40 AM, Gijs Veyfeyken < = EMAIL ADDRESS REMOVED = > wrote:
> Until NVDA changes it's default behaviour, you can add a child <div
> role="document"> inside the parent <div role="dialog"> to force NVDA into
> browse mode.
>
If you're going to add a child with role="document", I would give it
tabindex="0" as well (<div role="document" tabindex="0">). Because NVDA is
in application mode, users will not be able to 'read' into <div> with
role="document", they will only be able to 'tab" to the next element that
can receive keyboard focus. Giving the element tabindex="0" allows users to
navigate into it, which will trigger browse mode. From there they can begin
reading and navigating normally. The one drawback to this approach is that
it does add one extra tab stop, which could be a bit confusing for other
keyboard/screen reader users.
Better than this is to remove role="dialog" if possible, unless it is being
used with a true application dialog. In my experience, this role is seldom
used correctly.
Jonathan
Jonathan Whiting
WebAIM.org
>
> Kind regards,
>
> Gijs
>
> ---
> Gijs Veyfeyken
> AnySurfer - towards an accessible internet
> http://www.anysurfer.be/en
> Brussels - Belgium
> > > > >
From: Gijs Veyfeyken
Date: Wed, Nov 25 2015 12:38AM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | Next message →
Good example:
jQuery simple and accessible modal window, using ARIA by Nicolas Hoffmann
http://a11y.nicolas-hoffmann.net/modal/ <http://a11y.nicolas-hoffmann.net/modal/>;
Kind regards,
Gijs
From: Birkir R. Gunnarsson
Date: Wed, Nov 25 2015 7:17AM
Subject: Re: NVDA and auto-switching of reading modes
← Previous message | No next message
There are several alert and modal dialog examples at
https://dequeuniversity.com/resources
)you can see the contrasting styles by comparing the 1st and the 4th
example, alertdialog vs. modal dialog).
If you click on "copy and paste full page example" button once you
ahve activated the dialog link, you should be able to copy and paste
the code into your text editor of choice, save it with a .html
extension, and run it.
Then you can play around with the code, such as puttina div with
role="document" and tabindex="0" around static test etc.
Thanks
On 11/25/15, Gijs Veyfeyken < = EMAIL ADDRESS REMOVED = > wrote:
> Good example:
>
> jQuery simple and accessible modal window, using ARIA by Nicolas Hoffmann
> http://a11y.nicolas-hoffmann.net/modal/
> <http://a11y.nicolas-hoffmann.net/modal/>;
>
> Kind regards,
>
> Gijs
>
>
> > > > >
--
Work hard. Have fun. Make history.