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 11:55AM

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
> > >