E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Surendra
Date: Tue, Feb 07 2017 12:26AM
Subject: Dialog boxeson NVDA
No previous message | Next message →

Hi all,



I hope many of us have been using NVDA for long. I do not use it very often
personally, unless there arises any serious need. Like in my office, we have
to do testing in all possible scenarios on all possible platforms using all
screen readers including NVDA. Now, many a times, I get stuck on websites
with dialog boxes and pop-ups. Suppose there is a 'Table of Contents' button
on a page, hitting of which brings up a dialog box having table contents.
But NVDA would not read the same until Insert+SpaceBar is pressed. Should I
treat this as an accessibility issue? Because, I've seen some websites
wherein focus directly moves to the rellavant area and we can easily
navigate through the page with arrow keys, as we do in browse mode.

From: Rakesh P
Date: Tue, Feb 07 2017 1:14AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

Hi Surendra,


That is not an accessibility bug. Since it is a modal dialog developers use
role dialog. This causes NVDA to shift to the focus mode.

It is expected that user need to press insert + space bar to shift back to
browse mode and read the content.

On Tue, Feb 7, 2017 at 12:56 PM, Surendra < = EMAIL ADDRESS REMOVED = >
wrote:

> Hi all,
>
>
>
> I hope many of us have been using NVDA for long. I do not use it very often
> personally, unless there arises any serious need. Like in my office, we
> have
> to do testing in all possible scenarios on all possible platforms using all
> screen readers including NVDA. Now, many a times, I get stuck on websites
> with dialog boxes and pop-ups. Suppose there is a 'Table of Contents'
> button
> on a page, hitting of which brings up a dialog box having table contents.
> But NVDA would not read the same until Insert+SpaceBar is pressed. Should I
> treat this as an accessibility issue? Because, I've seen some websites
> wherein focus directly moves to the rellavant area and we can easily
> navigate through the page with arrow keys, as we do in browse mode.
>
> > > > >

From: Surendra
Date: Tue, Feb 07 2017 1:58AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

Thank you, Rakesh!

I was taking it as an accessibility bug, because NVDA reads
A hidden text 'Section' in case navigating through the modal dialog with Tab key. Isn't it an unwanted announcement?

From: Rakesh P
Date: Tue, Feb 07 2017 2:24AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

If screen reader is reading some hidden text while navigating through the
modal that does not make sense to the user, I will definitely consider as
an accessibility violation.


On Tue, Feb 7, 2017 at 2:28 PM, Surendra < = EMAIL ADDRESS REMOVED = >
wrote:

> Thank you, Rakesh!
>
> I was taking it as an accessibility bug, because NVDA reads
> A hidden text 'Section' in case navigating through the modal dialog with
> Tab key. Isn't it an unwanted announcement?
>

From: Surendra
Date: Tue, Feb 07 2017 3:01AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

Now,I was just wondering if there's any fix for that.

From: Rakesh P
Date: Tue, Feb 07 2017 5:48AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

Yes Surendra, As I said role="dialog" takes NVDA user to focus mode
directly. Developer can remove the role dialog and replace with
role="document". With this NVDA does not take the user to focus mode, it
will stay in browse mode.

If you are talking about the screen reader reading hidden / invisible
text,, with the use of aria-hidden property the hidden content can be made
ignorred by screen reader. aria-hidden="true".

Hope this helps.

On Tue, Feb 7, 2017 at 3:31 PM, Surendra < = EMAIL ADDRESS REMOVED = >
wrote:

> Now,I was just wondering if there's any fix for that.
>

From: Surendra
Date: Tue, Feb 07 2017 6:02AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

Thanks again!

Now my doubt is gone.
I liked role="document" so that NVDA does not automatically switch to Focus mode.

From: Jonathan Avila
Date: Wed, Feb 08 2017 10:47AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

> As I said role="dialog" takes NVDA user to focus mode directly. Developer can remove the role dialog and replace with role="document". With this NVDA does not take the user to focus mode, it will stay in browse mode.

I would generally not recommend using role of document instead of dialog or use it within dialogs. Role of region could be used with an aria-label or aria-labelledby as an alternative if dialog is misbehaving with some assistive technology.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Birkir R. Gunnarsson
Date: Wed, Feb 08 2017 11:48AM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

NVDA's behavior, to automatically go into application mode when focus
is moved into content with role="dialog" has often been discussed.
As far as I know NVDA is the only screen reader to go into application
mode when focus is moved to a dialog.

The ARIA 1.1 spec for the dialog role:
http://www.w3.org/TR/wai-aria-1.1/#dialog
has actually added an explicit note
"In the description of this role, the term "web application" does not
refer to the application role, which specifies specific assistive
technology behaviors."
that seems to indicate that screen readers should not switch to forms mode.

Looking at NVDA's Github, particularly issue 5826
https://github.com/nvaccess/nvda/issues/5826
confirms my suspicion that the NVDA developers have decided that NVDA
should go into application mode in dialogs and are not budging from
that stance.

I personally disagree with that decision, I think it presents a much
worse experience for the users, but these are awesome guys, they have
the data, and it is their software (and NVDA is a truly amazing screen
reader).

But I do not advice people to hack around this by using
role="document" inside dialogs because of the way one screen reader
vendor interprets the spec.
If it causes problems for the users, the users should talk directly to
that vendor.
The problem can be solved either by the vendor changing the way the
software operates, or the users get better training on how to set
their own preferences or switch between modes.
The developer should only be concerned with using the right HTML
elements or, if not possible, ARIA roles and attributes for coding the
content.
When they start implementing hacks for one screen reader it can
present issues in other screen readers.
Cheers
-B


On 2/8/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> As I said role="dialog" takes NVDA user to focus mode directly. Developer
>> can remove the role dialog and replace with role="document". With this
>> NVDA does not take the user to focus mode, it will stay in browse mode.
>
> I would generally not recommend using role of document instead of dialog or
> use it within dialogs. Role of region could be used with an aria-label or
> aria-labelledby as an alternative if dialog is misbehaving with some
> assistive technology.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> See you at CSUN in March!
>
> The information contained in this transmission may be attorney privileged
> and/or confidential information intended for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any use, dissemination, distribution
> or copying of this communication is strictly prohibited.
>
>
>

From: Rakesh P
Date: Wed, Feb 08 2017 9:20PM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

I agree with you Birkir. I want to say that role document will push the
user to browse mode but my intention is not to recommend it. As Jonathen
mentioned aria-label or aria-labelledby can be used to announce the content
of the modal but if the modal contains lengthy content with headings,
tables etc user will miss the scemantics. I advice the users are given an
option to change to browse mode and read the content.

May be NVDA one day decides to take the users to forms mode when accessing
a modal .


On Thu, Feb 9, 2017 at 12:18 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> NVDA's behavior, to automatically go into application mode when focus
> is moved into content with role="dialog" has often been discussed.
> As far as I know NVDA is the only screen reader to go into application
> mode when focus is moved to a dialog.
>
> The ARIA 1.1 spec for the dialog role:
> http://www.w3.org/TR/wai-aria-1.1/#dialog
> has actually added an explicit note
> "In the description of this role, the term "web application" does not
> refer to the application role, which specifies specific assistive
> technology behaviors."
> that seems to indicate that screen readers should not switch to forms mode.
>
> Looking at NVDA's Github, particularly issue 5826
> https://github.com/nvaccess/nvda/issues/5826
> confirms my suspicion that the NVDA developers have decided that NVDA
> should go into application mode in dialogs and are not budging from
> that stance.
>
> I personally disagree with that decision, I think it presents a much
> worse experience for the users, but these are awesome guys, they have
> the data, and it is their software (and NVDA is a truly amazing screen
> reader).
>
> But I do not advice people to hack around this by using
> role="document" inside dialogs because of the way one screen reader
> vendor interprets the spec.
> If it causes problems for the users, the users should talk directly to
> that vendor.
> The problem can be solved either by the vendor changing the way the
> software operates, or the users get better training on how to set
> their own preferences or switch between modes.
> The developer should only be concerned with using the right HTML
> elements or, if not possible, ARIA roles and attributes for coding the
> content.
> When they start implementing hacks for one screen reader it can
> present issues in other screen readers.
> Cheers
> -B
>
>
> On 2/8/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> >> As I said role="dialog" takes NVDA user to focus mode directly.
> Developer
> >> can remove the role dialog and replace with role="document". With this
> >> NVDA does not take the user to focus mode, it will stay in browse mode.
> >
> > I would generally not recommend using role of document instead of dialog
> or
> > use it within dialogs. Role of region could be used with an aria-label
> or
> > aria-labelledby as an alternative if dialog is misbehaving with some
> > assistive technology.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > SSB BART Group
> > = EMAIL ADDRESS REMOVED =
> > 703.637.8957 (Office)
> >
> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> > See you at CSUN in March!
> >
> > The information contained in this transmission may be attorney privileged
> > and/or confidential information intended for the use of the individual or
> > entity named above. If the reader of this message is not the intended
> > recipient, you are hereby notified that any use, dissemination,
> distribution
> > or copying of this communication is strictly prohibited.
> >
> >
> >

From: Jonathan Whiting
Date: Thu, Feb 09 2017 3:36PM
Subject: Re: Dialog boxeson NVDA
← Previous message | Next message →

I also agree with Birkir and Rakesh.

Last night I found an open issue on NVDA's Github and commented (
https://github.com/nvaccess/nvda/issues/4493). I suggested that NVDA would
better align with ARIA 1.1 if role="dialog" did not trigger focus mode.
James Teh replied, saying that this recommended change is on their 2017
roadmap. He also expressed some very valid concerns and frustrations.

Looks like a change is on the horizon!
Jonathan

Jonathan Whiting
WebAIM.org



On Wed, Feb 8, 2017 at 9:20 PM, Rakesh P < = EMAIL ADDRESS REMOVED = > wrote:

> I agree with you Birkir. I want to say that role document will push the
> user to browse mode but my intention is not to recommend it. As Jonathen
> mentioned aria-label or aria-labelledby can be used to announce the content
> of the modal but if the modal contains lengthy content with headings,
> tables etc user will miss the scemantics. I advice the users are given an
> option to change to browse mode and read the content.
>
> May be NVDA one day decides to take the users to forms mode when accessing
> a modal .
>
>
> On Thu, Feb 9, 2017 at 12:18 AM, Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > NVDA's behavior, to automatically go into application mode when focus
> > is moved into content with role="dialog" has often been discussed.
> > As far as I know NVDA is the only screen reader to go into application
> > mode when focus is moved to a dialog.
> >
> > The ARIA 1.1 spec for the dialog role:
> > http://www.w3.org/TR/wai-aria-1.1/#dialog
> > has actually added an explicit note
> > "In the description of this role, the term "web application" does not
> > refer to the application role, which specifies specific assistive
> > technology behaviors."
> > that seems to indicate that screen readers should not switch to forms
> mode.
> >
> > Looking at NVDA's Github, particularly issue 5826
> > https://github.com/nvaccess/nvda/issues/5826
> > confirms my suspicion that the NVDA developers have decided that NVDA
> > should go into application mode in dialogs and are not budging from
> > that stance.
> >
> > I personally disagree with that decision, I think it presents a much
> > worse experience for the users, but these are awesome guys, they have
> > the data, and it is their software (and NVDA is a truly amazing screen
> > reader).
> >
> > But I do not advice people to hack around this by using
> > role="document" inside dialogs because of the way one screen reader
> > vendor interprets the spec.
> > If it causes problems for the users, the users should talk directly to
> > that vendor.
> > The problem can be solved either by the vendor changing the way the
> > software operates, or the users get better training on how to set
> > their own preferences or switch between modes.
> > The developer should only be concerned with using the right HTML
> > elements or, if not possible, ARIA roles and attributes for coding the
> > content.
> > When they start implementing hacks for one screen reader it can
> > present issues in other screen readers.
> > Cheers
> > -B
> >
> >
> > On 2/8/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> > >> As I said role="dialog" takes NVDA user to focus mode directly.
> > Developer
> > >> can remove the role dialog and replace with role="document". With this
> > >> NVDA does not take the user to focus mode, it will stay in browse
> mode.
> > >
> > > I would generally not recommend using role of document instead of
> dialog
> > or
> > > use it within dialogs. Role of region could be used with an aria-label
> > or
> > > aria-labelledby as an alternative if dialog is misbehaving with some
> > > assistive technology.
> > >
> > > Jonathan
> > >
> > > Jonathan Avila
> > > Chief Accessibility Officer
> > > SSB BART Group
> > > = EMAIL ADDRESS REMOVED =
> > > 703.637.8957 (Office)
> > >
> > > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> > > See you at CSUN in March!
> > >
> > > The information contained in this transmission may be attorney
> privileged
> > > and/or confidential information intended for the use of the individual
> or
> > > entity named above. If the reader of this message is not the intended
> > > recipient, you are hereby notified that any use, dissemination,
> > distribution
> > > or copying of this communication is strictly prohibited.
> > >
> > >
> > >

From: Rakesh P
Date: Thu, Feb 09 2017 7:09PM
Subject: Re: Dialog boxeson NVDA
← Previous message | No next message

That"s a great new deed indeed Jonathan.

On Fri, Feb 10, 2017 at 4:06 AM, Jonathan Whiting < = EMAIL ADDRESS REMOVED = >
wrote:

> I also agree with Birkir and Rakesh.
>
> Last night I found an open issue on NVDA's Github and commented (
> https://github.com/nvaccess/nvda/issues/4493). I suggested that NVDA would
> better align with ARIA 1.1 if role="dialog" did not trigger focus mode.
> James Teh replied, saying that this recommended change is on their 2017
> roadmap. He also expressed some very valid concerns and frustrations.
>
> Looks like a change is on the horizon!
> Jonathan
>
> Jonathan Whiting
> WebAIM.org
>
>
>
> On Wed, Feb 8, 2017 at 9:20 PM, Rakesh P < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > I agree with you Birkir. I want to say that role document will push the
> > user to browse mode but my intention is not to recommend it. As Jonathen
> > mentioned aria-label or aria-labelledby can be used to announce the
> content
> > of the modal but if the modal contains lengthy content with headings,
> > tables etc user will miss the scemantics. I advice the users are given an
> > option to change to browse mode and read the content.
> >
> > May be NVDA one day decides to take the users to forms mode when
> accessing
> > a modal .
> >
> >
> > On Thu, Feb 9, 2017 at 12:18 AM, Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > NVDA's behavior, to automatically go into application mode when focus
> > > is moved into content with role="dialog" has often been discussed.
> > > As far as I know NVDA is the only screen reader to go into application
> > > mode when focus is moved to a dialog.
> > >
> > > The ARIA 1.1 spec for the dialog role:
> > > http://www.w3.org/TR/wai-aria-1.1/#dialog
> > > has actually added an explicit note
> > > "In the description of this role, the term "web application" does not
> > > refer to the application role, which specifies specific assistive
> > > technology behaviors."
> > > that seems to indicate that screen readers should not switch to forms
> > mode.
> > >
> > > Looking at NVDA's Github, particularly issue 5826
> > > https://github.com/nvaccess/nvda/issues/5826
> > > confirms my suspicion that the NVDA developers have decided that NVDA
> > > should go into application mode in dialogs and are not budging from
> > > that stance.
> > >
> > > I personally disagree with that decision, I think it presents a much
> > > worse experience for the users, but these are awesome guys, they have
> > > the data, and it is their software (and NVDA is a truly amazing screen
> > > reader).
> > >
> > > But I do not advice people to hack around this by using
> > > role="document" inside dialogs because of the way one screen reader
> > > vendor interprets the spec.
> > > If it causes problems for the users, the users should talk directly to
> > > that vendor.
> > > The problem can be solved either by the vendor changing the way the
> > > software operates, or the users get better training on how to set
> > > their own preferences or switch between modes.
> > > The developer should only be concerned with using the right HTML
> > > elements or, if not possible, ARIA roles and attributes for coding the
> > > content.
> > > When they start implementing hacks for one screen reader it can
> > > present issues in other screen readers.
> > > Cheers
> > > -B
> > >
> > >
> > > On 2/8/17, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> > > >> As I said role="dialog" takes NVDA user to focus mode directly.
> > > Developer
> > > >> can remove the role dialog and replace with role="document". With
> this
> > > >> NVDA does not take the user to focus mode, it will stay in browse
> > mode.
> > > >
> > > > I would generally not recommend using role of document instead of
> > dialog
> > > or
> > > > use it within dialogs. Role of region could be used with an
> aria-label
> > > or
> > > > aria-labelledby as an alternative if dialog is misbehaving with some
> > > > assistive technology.
> > > >
> > > > Jonathan
> > > >
> > > > Jonathan Avila
> > > > Chief Accessibility Officer
> > > > SSB BART Group
> > > > = EMAIL ADDRESS REMOVED =
> > > > 703.637.8957 (Office)
> > > >
> > > > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> > > > See you at CSUN in March!
> > > >
> > > > The information contained in this transmission may be attorney
> > privileged
> > > > and/or confidential information intended for the use of the
> individual
> > or
> > > > entity named above. If the reader of this message is not the intended
> > > > recipient, you are hereby notified that any use, dissemination,
> > > distribution
> > > > or copying of this communication is strictly prohibited.
> > > >
> > > >
> > > >