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 6:40PM

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