WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Info widgets with role="dialog"

for

From: Roger Hudson
Date: Jan 20, 2015 2:40PM

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>