WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Info widgets with role="dialog"

for

From: Jared Smith
Date: Jan 20, 2015 2:14PM

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