E-mail List Archives

Search E-mail List Archives for

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

From: Humbert, Joseph A
Date: Fri, Jan 04 2013 9:06AM
Subject: ARIA modal dialogs only read out focusable items (forms and links)
No previous message | Next message →

Hi All,

This issue has been brought up in multiple projects I have been involved with, ARIA modal dialogs only read out focusable items (form controls and links) while ignoring plain text (e.g., instructions) when using some AT software. You can view an example for testing at http://jqueryui.com/resources/demos/dialog/modal.html. I have tested with JAWS 13, latest version of NVDA, and Voiceover (mac OSX) on IE, Firefox and Safari. I can reproduce the issue with JAWS 13 and NVDA on Firefox and IE. Voiceover seems to work ok.

We have found non-elegant ways around the issue, but it would be nice not to have to use hacks.

I believe this issue stems from the ARIA authoring practices modal dialog (http://www.w3.org/TR/wai-aria-practices/#dialog_modal) keyboard interaction description which appears to only cover dealing with focusable items. So AT manufactures may have coded there products to follow the ARIA authoring practices.

What are people's opinions about suggesting modifications to the authoring practices to address keyboard interaction with plain text? Are there elegant cross-browser and cross-AT solutions? Thankx.

Joe Humbert, Adaptive Technology and Accessibility Specialist
UITS Adaptive Technology and Accessibility Centers
Indiana University, Indianapolis and Bloomington
535 W Michigan St. IT214 E
Indianapolis, IN 46202
Office Phone: (317) 274-4378
Cell Phone: (317) 644-6824
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
http://iuadapts.Indiana.edu/<;http://iuadapts.indiana.edu/>;

From: Jared Smith
Date: Fri, Jan 04 2013 9:22AM
Subject: Re: ARIA modal dialogs only read out focusable items (forms and links)
← Previous message | Next message →

The behavior you describe is correct. All content within a modal
dialog is to be keyboard focusable, at least as far as ARIA is
concerned. This, of course, is not the reality (and, I would argue, is
the exception for most modal dialogs). One suboptimal solution it to
somehow make the non-focusable text focusable and then convey this
non-standard keyboard interaction to the user.

Simply omitting the role="dialog" or "alertdialog" on the modal
element will keep the screen reader from entering application mode
(assuming the dialog is not within another element that would trigger
application mode). This would allow the screen reader to navigate all
elements within the dialog. The disadvantage of this approach is that
other navigation mechanisms are also allowed, which makes it very easy
for the user to navigate away from the modal dialog to other page
elements - hitting H to navigate headings, for example, would not
constrain the user to headings within the dialog. This has potential
to cause great confusion.

There is no perfect solution to these issues (that I'm aware of). It
seems to me that there should be some mechanism for easily
navigating/reading non-focusable elements while in application mode
dialog windows (and tab panels, etc.)

Jared

From: Ramya Sethuraman
Date: Fri, Jan 04 2013 11:06AM
Subject: Re: ARIA modal dialogs only read out focusable items (forms and links)
← Previous message | Next message →

This seems to be so common a scenario that it's almost as if we need a new aria attribute just to handle the non-focusable text in the dialog.

I have gotten around the issue by adding an aria-descibedby attribute on a focusable element in the dialog and pointing it to the text although the text doesn't really 'describe' the element...an inelegant solution but at least the screen reader announces the text. This can't be used if the text is more than a few lines long, gets too annoying.

Ramya

Sent from my iPhone

On Jan 4, 2013, at 11:22 AM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> The behavior you describe is correct. All content within a modal
> dialog is to be keyboard focusable, at least as far as ARIA is
> concerned. This, of course, is not the reality (and, I would argue, is
> the exception for most modal dialogs). One suboptimal solution it to
> somehow make the non-focusable text focusable and then convey this
> non-standard keyboard interaction to the user.
>
> Simply omitting the role="dialog" or "alertdialog" on the modal
> element will keep the screen reader from entering application mode
> (assuming the dialog is not within another element that would trigger
> application mode). This would allow the screen reader to navigate all
> elements within the dialog. The disadvantage of this approach is that
> other navigation mechanisms are also allowed, which makes it very easy
> for the user to navigate away from the modal dialog to other page
> elements - hitting H to navigate headings, for example, would not
> constrain the user to headings within the dialog. This has potential
> to cause great confusion.
>
> There is no perfect solution to these issues (that I'm aware of). It
> seems to me that there should be some mechanism for easily
> navigating/reading non-focusable elements while in application mode
> dialog windows (and tab panels, etc.)
>
> Jared
> > >

From: Bryan Garaventa
Date: Fri, Jan 04 2013 11:08AM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

There is an eloquent solution available for this, which is to not use
role=dialog, and instead use aria-hidden=true on the background content so
that it is invisible to screen reader users. This way, the modal is still
the only content that screen reader users interact with, and there is no
negative impact on navigation in the Virtual Buffer.

You can see this in action at
http://whatsock.com/bootstrap
on the Modal tab.

All the best,
Bryan

----- Original Message -----
From: "Humbert, Joseph A" < = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
Sent: Friday, January 04, 2013 8:06 AM
Subject: [WebAIM] ARIA modal dialogs only read out focusable items (formsand
links)


> Hi All,
>
> This issue has been brought up in multiple projects I have been involved
> with, ARIA modal dialogs only read out focusable items (form controls and
> links) while ignoring plain text (e.g., instructions) when using some AT
> software. You can view an example for testing at
> http://jqueryui.com/resources/demos/dialog/modal.html. I have tested with
> JAWS 13, latest version of NVDA, and Voiceover (mac OSX) on IE, Firefox
> and Safari. I can reproduce the issue with JAWS 13 and NVDA on Firefox and
> IE. Voiceover seems to work ok.
>
> We have found non-elegant ways around the issue, but it would be nice not
> to have to use hacks.
>
> I believe this issue stems from the ARIA authoring practices modal dialog
> (http://www.w3.org/TR/wai-aria-practices/#dialog_modal) keyboard
> interaction description which appears to only cover dealing with focusable
> items. So AT manufactures may have coded there products to follow the ARIA
> authoring practices.
>
> What are people's opinions about suggesting modifications to the authoring
> practices to address keyboard interaction with plain text? Are there
> elegant cross-browser and cross-AT solutions? Thankx.
>
> Joe Humbert, Adaptive Technology and Accessibility Specialist
> UITS Adaptive Technology and Accessibility Centers
> Indiana University, Indianapolis and Bloomington
> 535 W Michigan St. IT214 E
> Indianapolis, IN 46202
> Office Phone: (317) 274-4378
> Cell Phone: (317) 644-6824
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
> http://iuadapts.Indiana.edu/<;http://iuadapts.indiana.edu/>;
>
> > >

From: Sailesh Panchang
Date: Fri, Jan 04 2013 12:50PM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

Bryan,
Joseph's email above refers to content that is not focusable but
should be available to AT. Aria-hidden will not help there, right?
Also, with reference to Jared's note:
>> All content within a modal dialog is to be keyboard focusable, at least as far as ARIA is
>>concerned.
Is this a practical and realistic assumption?
Sailesh


On 1/4/13, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
> There is an eloquent solution available for this, which is to not use
> role=dialog, and instead use aria-hidden=true on the background content so
> that it is invisible to screen reader users. This way, the modal is still
> the only content that screen reader users interact with, and there is no
> negative impact on navigation in the Virtual Buffer.
>
> You can see this in action at
> http://whatsock.com/bootstrap
> on the Modal tab.
>
> All the best,
> Bryan
>
> ----- Original Message -----
> From: "Humbert, Joseph A" < = EMAIL ADDRESS REMOVED = >
> To: < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
> Sent: Friday, January 04, 2013 8:06 AM
> Subject: [WebAIM] ARIA modal dialogs only read out focusable items (formsand
>
> links)
>
>
>> Hi All,
>>
>> This issue has been brought up in multiple projects I have been involved
>> with, ARIA modal dialogs only read out focusable items (form controls and
>>
>> links) while ignoring plain text (e.g., instructions) when using some AT
>> software. You can view an example for testing at
>> http://jqueryui.com/resources/demos/dialog/modal.html. I have tested with
>>
>> JAWS 13, latest version of NVDA, and Voiceover (mac OSX) on IE, Firefox
>> and Safari. I can reproduce the issue with JAWS 13 and NVDA on Firefox and
>>
>> IE. Voiceover seems to work ok.
>>
>> We have found non-elegant ways around the issue, but it would be nice not
>>
>> to have to use hacks.
>>
>> I believe this issue stems from the ARIA authoring practices modal dialog
>>
>> (http://www.w3.org/TR/wai-aria-practices/#dialog_modal) keyboard
>> interaction description which appears to only cover dealing with focusable
>>
>> items. So AT manufactures may have coded there products to follow the ARIA
>>
>> authoring practices.
>>
>> What are people's opinions about suggesting modifications to the authoring
>>
>> practices to address keyboard interaction with plain text? Are there
>> elegant cross-browser and cross-AT solutions? Thankx.
>>
>> Joe Humbert, Adaptive Technology and Accessibility Specialist
>> UITS Adaptive Technology and Accessibility Centers
>> Indiana University, Indianapolis and Bloomington
>> 535 W Michigan St. IT214 E
>> Indianapolis, IN 46202
>> Office Phone: (317) 274-4378
>> Cell Phone: (317) 644-6824
>> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>> http://iuadapts.Indiana.edu/<;http://iuadapts.indiana.edu/>;
>>
>> >> >> >
> > > >

From: Bryan Garaventa
Date: Fri, Jan 04 2013 1:02PM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

Yes, aria-hidden only hides the background content, and not the dialog
content.

The dialog content is standard HTML, so all elements within it are
accessible, regardless whether these are focusable or not.

The use of role=dialog isn't scalable, because there is no guarantee that
content will be focusable, and in many cases it would be confusing to make
non-actionable elements focusable just to put them in the tab order, when
these would be confused with elements that are actionable.

Here is an example of this.

<div role="dialog" aria-label="Register">
<div class="scrollableLicenseAgreement">
Several paragraphs of license agreement text goes here...
</div>
<form>
Focusable form fields go here...
</form>
</div>

The use of role=dialog makes the license agreement text inaccessible.

However, if aria-hidden is used to simply hide the background content
instead, then all of the dialog is accessible regardless.




----- Original Message -----
From: "Sailesh Panchang" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Friday, January 04, 2013 11:50 AM
Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
(formsand links)


> Bryan,
> Joseph's email above refers to content that is not focusable but
> should be available to AT. Aria-hidden will not help there, right?
> Also, with reference to Jared's note:
>>> All content within a modal dialog is to be keyboard focusable, at least
>>> as far as ARIA is
>>>concerned.
> Is this a practical and realistic assumption?
> Sailesh
>
>
> On 1/4/13, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:
>> There is an eloquent solution available for this, which is to not use
>> role=dialog, and instead use aria-hidden=true on the background content
>> so
>> that it is invisible to screen reader users. This way, the modal is still
>> the only content that screen reader users interact with, and there is no
>> negative impact on navigation in the Virtual Buffer.
>>
>> You can see this in action at
>> http://whatsock.com/bootstrap
>> on the Modal tab.
>>
>> All the best,
>> Bryan
>>
>> ----- Original Message -----
>> From: "Humbert, Joseph A" < = EMAIL ADDRESS REMOVED = >
>> To: < = EMAIL ADDRESS REMOVED = >; < = EMAIL ADDRESS REMOVED = >
>> Sent: Friday, January 04, 2013 8:06 AM
>> Subject: [WebAIM] ARIA modal dialogs only read out focusable items
>> (formsand
>>
>> links)
>>
>>
>>> Hi All,
>>>
>>> This issue has been brought up in multiple projects I have been involved
>>> with, ARIA modal dialogs only read out focusable items (form controls
>>> and
>>>
>>> links) while ignoring plain text (e.g., instructions) when using some AT
>>> software. You can view an example for testing at
>>> http://jqueryui.com/resources/demos/dialog/modal.html. I have tested
>>> with
>>>
>>> JAWS 13, latest version of NVDA, and Voiceover (mac OSX) on IE, Firefox
>>> and Safari. I can reproduce the issue with JAWS 13 and NVDA on Firefox
>>> and
>>>
>>> IE. Voiceover seems to work ok.
>>>
>>> We have found non-elegant ways around the issue, but it would be nice
>>> not
>>>
>>> to have to use hacks.
>>>
>>> I believe this issue stems from the ARIA authoring practices modal
>>> dialog
>>>
>>> (http://www.w3.org/TR/wai-aria-practices/#dialog_modal) keyboard
>>> interaction description which appears to only cover dealing with
>>> focusable
>>>
>>> items. So AT manufactures may have coded there products to follow the
>>> ARIA
>>>
>>> authoring practices.
>>>
>>> What are people's opinions about suggesting modifications to the
>>> authoring
>>>
>>> practices to address keyboard interaction with plain text? Are there
>>> elegant cross-browser and cross-AT solutions? Thankx.
>>>
>>> Joe Humbert, Adaptive Technology and Accessibility Specialist
>>> UITS Adaptive Technology and Accessibility Centers
>>> Indiana University, Indianapolis and Bloomington
>>> 535 W Michigan St. IT214 E
>>> Indianapolis, IN 46202
>>> Office Phone: (317) 274-4378
>>> Cell Phone: (317) 644-6824
>>> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>>> http://iuadapts.Indiana.edu/<;http://iuadapts.indiana.edu/>;
>>>
>>> >>> >>> >>
>> >> >> >>
> > >

From: Jared Smith
Date: Fri, Jan 04 2013 1:03PM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:

> Joseph's email above refers to content that is not focusable but
> should be available to AT. Aria-hidden will not help there, right?

It will if you do not set use an ARIA role to trigger application mode
on the dialog. In other words, aria-hidden would hide everything from
AT except for the dialog box, which could then be navigated as
standard web content.

A difficulty with this approach is that the dialog must generally be
in the DOM or markup at the very beginning or very end of the
document. It cannot be somewhere within the content that has
aria-hidden applied to it - you can't unhide content within hidden
content (i.e., aria-hiddenúlse doesn't work inside
aria-hidden=true).

> Also, with reference to Jared's note:
>>> All content within a modal dialog is to be keyboard focusable, at least as far as ARIA is
>>>concerned.
> Is this a practical and realistic assumption?

I think this thread is highlighting that it is not always practical.
It requires hacks and/or ignoring this aspect of the specification.
Remember, however, that ARIA is intended for *applications*, in which
it would generally be uncommon for a dialog to contain anything other
than focusable controls. It is our applying the dialog role to
non-application dialogs that is causing these issues.

Jared

From: Steve Faulkner
Date: Sat, Jan 05 2013 7:47AM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

Hi all,

if the dialog is like a standard desktop dialog with only form controls use

<div role="dialog">
...
</div>


if it also contains text and other stuff use

<div role="dialog">
...
<div role=document tabindex=0>

...
</div>

</div>


On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
>
> > Joseph's email above refers to content that is not focusable but
> > should be available to AT. Aria-hidden will not help there, right?
>
> It will if you do not set use an ARIA role to trigger application mode
> on the dialog. In other words, aria-hidden would hide everything from
> AT except for the dialog box, which could then be navigated as
> standard web content.
>
> A difficulty with this approach is that the dialog must generally be
> in the DOM or markup at the very beginning or very end of the
> document. It cannot be somewhere within the content that has
> aria-hidden applied to it - you can't unhide content within hidden
> content (i.e., aria-hiddenúlse doesn't work inside
> aria-hidden=true).
>
> > Also, with reference to Jared's note:
> >>> All content within a modal dialog is to be keyboard focusable, at
> least as far as ARIA is
> >>>concerned.
> > Is this a practical and realistic assumption?
>
> I think this thread is highlighting that it is not always practical.
> It requires hacks and/or ignoring this aspect of the specification.
> Remember, however, that ARIA is intended for *applications*, in which
> it would generally be uncommon for a dialog to contain anything other
> than focusable controls. It is our applying the dialog role to
> non-application dialogs that is causing these issues.
>
> Jared
> > > >



--
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

From: Bryan Garaventa
Date: Sat, Jan 05 2013 11:55AM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

And if the container with tabindex=0 and role=document contains other active
elements like links, how does this work for keyboard only users that are not
running a screen reader? Since, this would be nesting active elements, and
may also conflict with voice navigation software.

Is there a problem with simply not using role=dialog, and just hiding the
background content using aria-hidden as I've described?

----- Original Message -----
From: "Steve Faulkner" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, January 05, 2013 6:47 AM
Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
(formsand links)


> Hi all,
>
> if the dialog is like a standard desktop dialog with only form controls
> use
>
> <div role="dialog">
> ...
> </div>
>
>
> if it also contains text and other stuff use
>
> <div role="dialog">
> ...
> <div role=document tabindex=0>
>
> ...
> </div>
>
> </div>
>
>
> On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
>>
>> > Joseph's email above refers to content that is not focusable but
>> > should be available to AT. Aria-hidden will not help there, right?
>>
>> It will if you do not set use an ARIA role to trigger application mode
>> on the dialog. In other words, aria-hidden would hide everything from
>> AT except for the dialog box, which could then be navigated as
>> standard web content.
>>
>> A difficulty with this approach is that the dialog must generally be
>> in the DOM or markup at the very beginning or very end of the
>> document. It cannot be somewhere within the content that has
>> aria-hidden applied to it - you can't unhide content within hidden
>> content (i.e., aria-hiddenúlse doesn't work inside
>> aria-hidden=true).
>>
>> > Also, with reference to Jared's note:
>> >>> All content within a modal dialog is to be keyboard focusable, at
>> least as far as ARIA is
>> >>>concerned.
>> > Is this a practical and realistic assumption?
>>
>> I think this thread is highlighting that it is not always practical.
>> It requires hacks and/or ignoring this aspect of the specification.
>> Remember, however, that ARIA is intended for *applications*, in which
>> it would generally be uncommon for a dialog to contain anything other
>> than focusable controls. It is our applying the dialog role to
>> non-application dialogs that is causing these issues.
>>
>> Jared
>> >> >> >>
>
>
>
> --
> with regards
>
> Steve Faulkner
> Technical Director - TPG
>
> www.paciellogroup.com | www.HTML5accessibility.com |
> www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives -
> dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar -
> www.paciellogroup.com/resources/wat-ie-about.html
> > >

From: Bryan Garaventa
Date: Sat, Jan 05 2013 2:41PM
Subject: Re: ARIA modal dialogs only read out focusable items(formsand links)
← Previous message | Next message →

To clarify one important point for those who aren't familiar with it, the
use of role=dialog doesn't actually hide any background content from screen
reader users.

JAWS users for example, can press insert+z to abort this functionality to
continue standard Virtual Cursor navigation. This is something I do
personally every time I encounter dialogs formed in this manner, because
I've found that, in most cases, developers have also included additional
content that can't be accessed otherwise. So, without disabling Applications
Mode to check, there isn't a way for me to know for certain when this is the
case.

So, regarding the hiding of background content, this is important with
regard to cross browser implementations.

If you rely on role=dialog for example, this will make no difference in iOS
touch screen devices. Neither of the beginning and ending boundaries of a
dialog with role=dialog are conveyed, nor is the background content hidden
from Voiceover users, so that the background content can't be distinguished
from dialog content.

You can see an example of this at
http://whatsock.com/test/test.html
By opening this in your iOS device.

In contrast, if you hide the background content using aria-hidden, only the
modal content is conveyed to screen reader users. This works in IE, FF,
Chrome, and Safari.

So then, you can say, use aria-hidden on background content, and also use
role=dialog on the modal.

My question though is, what additional value does adding role=dialog
actually provide for screen reader users?

From what I can see through testing, not adding role=dialog when the
background content is already invisible via aria-hidden, is already fully
accessible to the highest percentage of users.

The addition of role=dialog appears to add no additional value for screen
reader users, increases the likelihood of developer misinterpretation when
differing types of static content are involved, and is more likely to cause
difficulties for users with differing disability types.

So what are the benefits of using role=dialog that cannot be achieved
without using it?

----- Original Message -----
From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, January 05, 2013 10:55 AM
Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable
items(formsand links)


> And if the container with tabindex=0 and role=document contains other
> active
> elements like links, how does this work for keyboard only users that are
> not
> running a screen reader? Since, this would be nesting active elements, and
> may also conflict with voice navigation software.
>
> Is there a problem with simply not using role=dialog, and just hiding the
> background content using aria-hidden as I've described?
>
> ----- Original Message -----
> From: "Steve Faulkner" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, January 05, 2013 6:47 AM
> Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
> (formsand links)
>
>
>> Hi all,
>>
>> if the dialog is like a standard desktop dialog with only form controls
>> use
>>
>> <div role="dialog">
>> ...
>> </div>
>>
>>
>> if it also contains text and other stuff use
>>
>> <div role="dialog">
>> ...
>> <div role=document tabindex=0>
>>
>> ...
>> </div>
>>
>> </div>
>>
>>
>> On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
>>>
>>> > Joseph's email above refers to content that is not focusable but
>>> > should be available to AT. Aria-hidden will not help there, right?
>>>
>>> It will if you do not set use an ARIA role to trigger application mode
>>> on the dialog. In other words, aria-hidden would hide everything from
>>> AT except for the dialog box, which could then be navigated as
>>> standard web content.
>>>
>>> A difficulty with this approach is that the dialog must generally be
>>> in the DOM or markup at the very beginning or very end of the
>>> document. It cannot be somewhere within the content that has
>>> aria-hidden applied to it - you can't unhide content within hidden
>>> content (i.e., aria-hiddenúlse doesn't work inside
>>> aria-hidden=true).
>>>
>>> > Also, with reference to Jared's note:
>>> >>> All content within a modal dialog is to be keyboard focusable, at
>>> least as far as ARIA is
>>> >>>concerned.
>>> > Is this a practical and realistic assumption?
>>>
>>> I think this thread is highlighting that it is not always practical.
>>> It requires hacks and/or ignoring this aspect of the specification.
>>> Remember, however, that ARIA is intended for *applications*, in which
>>> it would generally be uncommon for a dialog to contain anything other
>>> than focusable controls. It is our applying the dialog role to
>>> non-application dialogs that is causing these issues.
>>>
>>> Jared
>>> >>> >>> >>>
>>
>>
>>
>> --
>> with regards
>>
>> Steve Faulkner
>> Technical Director - TPG
>>
>> www.paciellogroup.com | www.HTML5accessibility.com |
>> www.twitter.com/stevefaulkner
>> HTML5: Techniques for providing useful text alternatives -
>> dev.w3.org/html5/alt-techniques/
>> Web Accessibility Toolbar -
>> www.paciellogroup.com/resources/wat-ie-about.html
>> >> >> >
> > >

From: Ryan E. Benson
Date: Sat, Jan 05 2013 4:39PM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

I don't quite follow your opening question Bryan. The div having the
document role, essentially creates a DOM within the modal window. From a
keyboard only viewpoint, if focus is brought into the modal window on
launch, there is no issues that I can see. My question to Steve would be,
why can't we have:
<div role="dialog" tabindex="0">
..
</div>
Does the nested document role, trap the focus into the modal better?

Bryan said
> Is there a problem with simply not using role=dialog, and just hiding the
background content using aria-hidden as I've described?

Steve has a blog post on this (<
http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/>;),
but putting aria-hidden=true randomly on a word in a sentence, people not
using AT would still see that word, people using a screen reader won't. I
haven't seen any articles regarding Dragon and ARIA, but if Dragon does
support ARIA and the word chose to apply aria-hidden to was a link, that
wouldn't be clickable with Dragon.

--
Ryan E. Benson


On Sat, Jan 5, 2013 at 1:55 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> And if the container with tabindex=0 and role=document contains other
> active
> elements like links, how does this work for keyboard only users that are
> not
> running a screen reader? Since, this would be nesting active elements, and
> may also conflict with voice navigation software.
>
> Is there a problem with simply not using role=dialog, and just hiding the
> background content using aria-hidden as I've described?
>
> ----- Original Message -----
> From: "Steve Faulkner" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, January 05, 2013 6:47 AM
> Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
> (formsand links)
>
>
> > Hi all,
> >
> > if the dialog is like a standard desktop dialog with only form controls
> > use
> >
> > <div role="dialog">
> > ...
> > </div>
> >
> >
> > if it also contains text and other stuff use
> >
> > <div role="dialog">
> > ...
> > <div role=document tabindex=0>
> >
> > ...
> > </div>
> >
> > </div>
> >
> >
> > On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> >
> >> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
> >>
> >> > Joseph's email above refers to content that is not focusable but
> >> > should be available to AT. Aria-hidden will not help there, right?
> >>
> >> It will if you do not set use an ARIA role to trigger application mode
> >> on the dialog. In other words, aria-hidden would hide everything from
> >> AT except for the dialog box, which could then be navigated as
> >> standard web content.
> >>
> >> A difficulty with this approach is that the dialog must generally be
> >> in the DOM or markup at the very beginning or very end of the
> >> document. It cannot be somewhere within the content that has
> >> aria-hidden applied to it - you can't unhide content within hidden
> >> content (i.e., aria-hiddenúlse doesn't work inside
> >> aria-hidden=true).
> >>
> >> > Also, with reference to Jared's note:
> >> >>> All content within a modal dialog is to be keyboard focusable, at
> >> least as far as ARIA is
> >> >>>concerned.
> >> > Is this a practical and realistic assumption?
> >>
> >> I think this thread is highlighting that it is not always practical.
> >> It requires hacks and/or ignoring this aspect of the specification.
> >> Remember, however, that ARIA is intended for *applications*, in which
> >> it would generally be uncommon for a dialog to contain anything other
> >> than focusable controls. It is our applying the dialog role to
> >> non-application dialogs that is causing these issues.
> >>
> >> Jared
> >> > >> > >> > >>
> >
> >
> >
> > --
> > with regards
> >
> > Steve Faulkner
> > Technical Director - TPG
> >
> > www.paciellogroup.com | www.HTML5accessibility.com |
> > www.twitter.com/stevefaulkner
> > HTML5: Techniques for providing useful text alternatives -
> > dev.w3.org/html5/alt-techniques/
> > Web Accessibility Toolbar -
> > www.paciellogroup.com/resources/wat-ie-about.html
> > > > > > >
> > > >

From: Bryan Garaventa
Date: Sat, Jan 05 2013 6:40PM
Subject: Re: ARIA modal dialogs only read out focusable items (formsand links)
← Previous message | Next message →

It is a common accessibility best practice that non-active elements should
not receive keyboard focus.

This is what my initial question refers to. Putting tabindex=0 on non-active
elements simply to route keyboard focus into static content sections within
dialogs doesn't make sense, when these sections are already fully accessible
without the use of role=dialog in the first place. Doing so would mean you
would have to do the same for all types of instructional text, constraint
information for form fields, disclaimers, and so on. Yes you can put
aria-describedby on a form field so it announces constraint information, but
what happens if the text is unclear or the punctuation, abbreviation, or
unfamiliar wording isn't announced properly, and the user wishes to manually
check the spelling for a particular word? Preventing screen reader users
from being able to do this when sighted users can simply see what they need
to, would be a violation of equal accessibility.

Doing so also means that keyboard only users get to tab through a bunch of
non-active elements within the modal content, which appear to have no
purpose.

My second question is more of a broad one.

What additional benefits does the addition of role=dialog on modals provide
for screen reader users? I've never actually received an answer to this
question before, and I would genuinely like to know.

For example, please test the following using JAWS, NVDA, and Voiceover.
1. Visit http://whatsock.com/bootstrap
2. Activate the Modal tab, and activate the Login button.

This uses the aria-hidden method I previously described, and it hides the
background content fully from screen reader users, in JAWS, NVDA, and
Voiceover using IE, FF, Chrome, and Safari. It does not use role=dialog
however.

So what additional functionality would adding role=dialog provide for this
type of modal, that doesn't already exist?

Or perhaps I'm asking the wrong question, which would be better phrased as

How would adding role=dialog to this control type, make it more accessible
for screen reader users?



----- Original Message -----
From: "Ryan E. Benson" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, January 05, 2013 3:39 PM
Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
(formsand links)


>I don't quite follow your opening question Bryan. The div having the
> document role, essentially creates a DOM within the modal window. From a
> keyboard only viewpoint, if focus is brought into the modal window on
> launch, there is no issues that I can see. My question to Steve would be,
> why can't we have:
> <div role="dialog" tabindex="0">
> ..
> </div>
> Does the nested document role, trap the focus into the modal better?
>
> Bryan said
>> Is there a problem with simply not using role=dialog, and just hiding the
> background content using aria-hidden as I've described?
>
> Steve has a blog post on this (<
> http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/>;),
> but putting aria-hidden=true randomly on a word in a sentence, people not
> using AT would still see that word, people using a screen reader won't. I
> haven't seen any articles regarding Dragon and ARIA, but if Dragon does
> support ARIA and the word chose to apply aria-hidden to was a link, that
> wouldn't be clickable with Dragon.
>
> --
> Ryan E. Benson
>
>
> On Sat, Jan 5, 2013 at 1:55 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> And if the container with tabindex=0 and role=document contains other
>> active
>> elements like links, how does this work for keyboard only users that are
>> not
>> running a screen reader? Since, this would be nesting active elements,
>> and
>> may also conflict with voice navigation software.
>>
>> Is there a problem with simply not using role=dialog, and just hiding the
>> background content using aria-hidden as I've described?
>>
>> ----- Original Message -----
>> From: "Steve Faulkner" < = EMAIL ADDRESS REMOVED = >
>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>> Sent: Saturday, January 05, 2013 6:47 AM
>> Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
>> (formsand links)
>>
>>
>> > Hi all,
>> >
>> > if the dialog is like a standard desktop dialog with only form controls
>> > use
>> >
>> > <div role="dialog">
>> > ...
>> > </div>
>> >
>> >
>> > if it also contains text and other stuff use
>> >
>> > <div role="dialog">
>> > ...
>> > <div role=document tabindex=0>
>> >
>> > ...
>> > </div>
>> >
>> > </div>
>> >
>> >
>> > On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>> >
>> >> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
>> >>
>> >> > Joseph's email above refers to content that is not focusable but
>> >> > should be available to AT. Aria-hidden will not help there, right?
>> >>
>> >> It will if you do not set use an ARIA role to trigger application mode
>> >> on the dialog. In other words, aria-hidden would hide everything from
>> >> AT except for the dialog box, which could then be navigated as
>> >> standard web content.
>> >>
>> >> A difficulty with this approach is that the dialog must generally be
>> >> in the DOM or markup at the very beginning or very end of the
>> >> document. It cannot be somewhere within the content that has
>> >> aria-hidden applied to it - you can't unhide content within hidden
>> >> content (i.e., aria-hiddenúlse doesn't work inside
>> >> aria-hidden=true).
>> >>
>> >> > Also, with reference to Jared's note:
>> >> >>> All content within a modal dialog is to be keyboard focusable, at
>> >> least as far as ARIA is
>> >> >>>concerned.
>> >> > Is this a practical and realistic assumption?
>> >>
>> >> I think this thread is highlighting that it is not always practical.
>> >> It requires hacks and/or ignoring this aspect of the specification.
>> >> Remember, however, that ARIA is intended for *applications*, in which
>> >> it would generally be uncommon for a dialog to contain anything other
>> >> than focusable controls. It is our applying the dialog role to
>> >> non-application dialogs that is causing these issues.
>> >>
>> >> Jared
>> >> >> >> >> >> >> >>
>> >
>> >
>> >
>> > --
>> > with regards
>> >
>> > Steve Faulkner
>> > Technical Director - TPG
>> >
>> > www.paciellogroup.com | www.HTML5accessibility.com |
>> > www.twitter.com/stevefaulkner
>> > HTML5: Techniques for providing useful text alternatives -
>> > dev.w3.org/html5/alt-techniques/
>> > Web Accessibility Toolbar -
>> > www.paciellogroup.com/resources/wat-ie-about.html
>> > >> > >> > >>
>> >> >> >>
> > >

From: Bryan Garaventa
Date: Sun, Jan 13 2013 9:47PM
Subject: Re: ARIA modal dialogs only read out focusable items(formsand links)
← Previous message | No next message

I didn't mean for this to be rhetorical.

If anyone ever finds an answer to these questions, please let me know.

----- Original Message -----
From: "Bryan Garaventa" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Saturday, January 05, 2013 5:40 PM
Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable
items(formsand links)


> It is a common accessibility best practice that non-active elements should
> not receive keyboard focus.
>
> This is what my initial question refers to. Putting tabindex=0 on
> non-active
> elements simply to route keyboard focus into static content sections
> within
> dialogs doesn't make sense, when these sections are already fully
> accessible
> without the use of role=dialog in the first place. Doing so would mean you
> would have to do the same for all types of instructional text, constraint
> information for form fields, disclaimers, and so on. Yes you can put
> aria-describedby on a form field so it announces constraint information,
> but
> what happens if the text is unclear or the punctuation, abbreviation, or
> unfamiliar wording isn't announced properly, and the user wishes to
> manually
> check the spelling for a particular word? Preventing screen reader users
> from being able to do this when sighted users can simply see what they
> need
> to, would be a violation of equal accessibility.
>
> Doing so also means that keyboard only users get to tab through a bunch of
> non-active elements within the modal content, which appear to have no
> purpose.
>
> My second question is more of a broad one.
>
> What additional benefits does the addition of role=dialog on modals
> provide
> for screen reader users? I've never actually received an answer to this
> question before, and I would genuinely like to know.
>
> For example, please test the following using JAWS, NVDA, and Voiceover.
> 1. Visit http://whatsock.com/bootstrap
> 2. Activate the Modal tab, and activate the Login button.
>
> This uses the aria-hidden method I previously described, and it hides the
> background content fully from screen reader users, in JAWS, NVDA, and
> Voiceover using IE, FF, Chrome, and Safari. It does not use role=dialog
> however.
>
> So what additional functionality would adding role=dialog provide for this
> type of modal, that doesn't already exist?
>
> Or perhaps I'm asking the wrong question, which would be better phrased as
>
> How would adding role=dialog to this control type, make it more accessible
> for screen reader users?
>
>
>
> ----- Original Message -----
> From: "Ryan E. Benson" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Saturday, January 05, 2013 3:39 PM
> Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
> (formsand links)
>
>
>>I don't quite follow your opening question Bryan. The div having the
>> document role, essentially creates a DOM within the modal window. From a
>> keyboard only viewpoint, if focus is brought into the modal window on
>> launch, there is no issues that I can see. My question to Steve would be,
>> why can't we have:
>> <div role="dialog" tabindex="0">
>> ..
>> </div>
>> Does the nested document role, trap the focus into the modal better?
>>
>> Bryan said
>>> Is there a problem with simply not using role=dialog, and just hiding
>>> the
>> background content using aria-hidden as I've described?
>>
>> Steve has a blog post on this (<
>> http://www.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/>;),
>> but putting aria-hidden=true randomly on a word in a sentence, people not
>> using AT would still see that word, people using a screen reader won't. I
>> haven't seen any articles regarding Dragon and ARIA, but if Dragon does
>> support ARIA and the word chose to apply aria-hidden to was a link, that
>> wouldn't be clickable with Dragon.
>>
>> --
>> Ryan E. Benson
>>
>>
>> On Sat, Jan 5, 2013 at 1:55 PM, Bryan Garaventa <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> And if the container with tabindex=0 and role=document contains other
>>> active
>>> elements like links, how does this work for keyboard only users that are
>>> not
>>> running a screen reader? Since, this would be nesting active elements,
>>> and
>>> may also conflict with voice navigation software.
>>>
>>> Is there a problem with simply not using role=dialog, and just hiding
>>> the
>>> background content using aria-hidden as I've described?
>>>
>>> ----- Original Message -----
>>> From: "Steve Faulkner" < = EMAIL ADDRESS REMOVED = >
>>> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
>>> Sent: Saturday, January 05, 2013 6:47 AM
>>> Subject: Re: [WebAIM] ARIA modal dialogs only read out focusable items
>>> (formsand links)
>>>
>>>
>>> > Hi all,
>>> >
>>> > if the dialog is like a standard desktop dialog with only form
>>> > controls
>>> > use
>>> >
>>> > <div role="dialog">
>>> > ...
>>> > </div>
>>> >
>>> >
>>> > if it also contains text and other stuff use
>>> >
>>> > <div role="dialog">
>>> > ...
>>> > <div role=document tabindex=0>
>>> >
>>> > ...
>>> > </div>
>>> >
>>> > </div>
>>> >
>>> >
>>> > On 4 January 2013 20:03, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
>>> >
>>> >> On Fri, Jan 4, 2013 at 12:50 PM, Sailesh Panchang wrote:
>>> >>
>>> >> > Joseph's email above refers to content that is not focusable but
>>> >> > should be available to AT. Aria-hidden will not help there, right?
>>> >>
>>> >> It will if you do not set use an ARIA role to trigger application
>>> >> mode
>>> >> on the dialog. In other words, aria-hidden would hide everything from
>>> >> AT except for the dialog box, which could then be navigated as
>>> >> standard web content.
>>> >>
>>> >> A difficulty with this approach is that the dialog must generally be
>>> >> in the DOM or markup at the very beginning or very end of the
>>> >> document. It cannot be somewhere within the content that has
>>> >> aria-hidden applied to it - you can't unhide content within hidden
>>> >> content (i.e., aria-hiddenúlse doesn't work inside
>>> >> aria-hidden=true).
>>> >>
>>> >> > Also, with reference to Jared's note:
>>> >> >>> All content within a modal dialog is to be keyboard focusable, at
>>> >> least as far as ARIA is
>>> >> >>>concerned.
>>> >> > Is this a practical and realistic assumption?
>>> >>
>>> >> I think this thread is highlighting that it is not always practical.
>>> >> It requires hacks and/or ignoring this aspect of the specification.
>>> >> Remember, however, that ARIA is intended for *applications*, in which
>>> >> it would generally be uncommon for a dialog to contain anything other
>>> >> than focusable controls. It is our applying the dialog role to
>>> >> non-application dialogs that is causing these issues.
>>> >>
>>> >> Jared
>>> >> >>> >> >>> >> >>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > with regards
>>> >
>>> > Steve Faulkner
>>> > Technical Director - TPG
>>> >
>>> > www.paciellogroup.com | www.HTML5accessibility.com |
>>> > www.twitter.com/stevefaulkner
>>> > HTML5: Techniques for providing useful text alternatives -
>>> > dev.w3.org/html5/alt-techniques/
>>> > Web Accessibility Toolbar -
>>> > www.paciellogroup.com/resources/wat-ie-about.html
>>> > >>> > >>> > >>>
>>> >>> >>> >>>
>> >> >> >
> > >