WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: ARIA modal dialogs only read out focusable items(formsand links)

for

From: Bryan Garaventa
Date: Jan 5, 2013 2:41PM

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 REMOVED> >
To: "WebAIM Discussion List" < <EMAIL 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 REMOVED> >
> To: "WebAIM Discussion List" < <EMAIL 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 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
>> >> >> >
> > >