WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Info widgets with role="dialog"

for

From: Birkir R. Gunnarsson
Date: Jan 21, 2015 9:37AM

The ARIA authoring spec recommends role="document" on static text as
well as tabindex="0" to make sure infomration stays in focus order
http://www.w3.org/TR/wai-aria-practices/#alertdialog
Actually there is an NVDA bug, which I have to file, .. when the
message area of a dialog has role document, NVDA will disregard the
aria-describebby attribute that points to it .. simply removing
role="document" causes NVDA to automatically read the message again.
Cheers

On 1/20/15, Roger Hudson < <EMAIL REMOVED> > wrote:
> Thanks Detlev and Jared for your concise and useful info about this problem
> which I am seeing more and more.
> Roger
>
> -----Original Message-----
> From: Jared Smith [mailto: <EMAIL REMOVED> ]
> Sent: Wednesday, 21 January 2015 8:14 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Info widgets with role="dialog"
>
> Detlev Fischer wrote:
>
>> I wonder whether there is consensus in the community, especially among
> screen reader users, whether modal pop-ups that contain non-form elements
> such as tab panels, data tables with information etc. should be marked up
> as
> dialog.
>
> Consensus? From the accessibility community? Ha, ha! :-)
>
> The ARIA specification states: "A dialog is an application window that is
> designed to interrupt the current processing of an application in order to
> prompt the user to enter information or require a response."
>
> The key here is that a dialog is an *application window*. This generally
> means that the diaIog contains application elements - primarily form
> controls for input. If the pop-up is instead a *content dialog*, then it
> shouldn't be marked up as a dialog.
>
> A problem is that all scripting libraries that support dialog roles do not
> provide any differentiation - all pop-ups are marked up as application
> dialogs regardless of their nature. I think it's possible that the majority
> of dialogs on the web shouldn't be marked up as dialogs at all.
>
>> 1. When calling up a dialog, will screen reader users generally know /
> expect that they (may) have to switch to a reader mode to reach
> non-focusable content?
>
> My experience has been that they very often do not know this. Many users
> don't even know how to switch modes.
>
>> 2. If 1 is answered in the negative, should info-widgets better NOT be
>> given role=dialog
>
> If the pop-up is an info-widget and not an application dialog (it presents
> content, not application controls), then it should not be given
> role=dialog.
>
> But often a true dialog has a mix of application controls AND content.
> In these cases, as Steve suggested, you should use role=document on the
> non-application stuff. This, however, does not always mean the user will
> readily be able to locate or read it because they will generally be tabbing
> within the dialog and skipping over the non-application stuff regardless.
>
>> 3. Is adding tabindex=0 to ensure that usually non-focusable content is
> read a good practice to solve this particular problem?
>
> Not good practice, but it may suffice. Tabable (I'm not sure that is even a
> word) elements inherently indicate that they are actionable.
> Allowing navigation focus to an element that cannot receive input or
> activation can be confusing. With that said, it can be *more* confusing if
> important content is bypassed. I have seen tabindex=0 used in places where
> there was no other reasonable method of providing access to *important*
> non-actionable information (such as vital instructions within a form)
> within
> a navigation flow.
>
> Jared
> > > messages to <EMAIL REMOVED>
>
> > > >


--
Work hard. Have fun. Make history.