WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Ryan E. Benson
Date: Jan 5, 2013 4:39PM

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