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 13, 2013 9:47PM

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