Fw: The W3.org Design Patterns that include role=dialog, role=alertdialog, and role=application cause critical accessibility issues for screen reader users.

In case this too is helpful.
 
----- Original Message ----- 
From: Bryan Garaventa 
To: public-pfwg-comments@w3.org 
Sent: Monday, August 12, 2013 7:00 PM
Subject: The W3.org Design Patterns that include role=dialog, role=alertdialog, and role=application cause critical accessibility issues for screen reader users.


This issue exists within multiple design patterns at
http://www.w3.org/TR/wai-aria-practices/

Specifically, all of the following design patterns specify or reference the use of role=dialog or role=alertdialog as a general practice:
Alert (widget)
Alert or Message Dialog (widget)
Dialog (Modal) (widget)
Dialog (Non-Modal) (widget)
Dialog (Tooltip) (widget)
Popup Help (aka Bubble Help) (widget)
Wizard (widget)

The problem with recommending these attributes as a general practice for all of these design patterns, is that it has the strong likelihood of introducing critical accessibility issues for screen reader users, while at the same time, not increasing accessibility in any way.

Here is a simple example of this that uses mixed content as part of a dialog construct:
http://whatsock.com/test/Compare%20role=dialog%20vs%20no%20role=dialog.html

By examining the code, you can see how the first dialog container is constructed, using only role="region" and aria-label="dialog" to set a region.

Now, in order to make the same dialog content compliant when role="dialog" is added, you can examine the code for the second dialog to see how complicated the same content has become.

This is just from the coding perspective.

Also, it's important to note that the second dialog that includes role="dialog" is not in any way more accessible to screen reader users, than the first dialog that does not.

The opposite is true instead.

When you view this page using NVDA in both IE and FF, you can use the arrow keys to navigate through the first dialog container content with no problem.

Then, when you get the to the second dialog that uses role="dialog", you'll notice that the content is totally invisible within the Virtual Buffer.

Additionally, when tabbing through the active elements within the second dialog, notice that the File Upload field label is not accessible, even though it has an explicit label. The reason, because the browser automatically sets the edit field to readonly with no tab stop, then provides a "Browse" button instead, which does not share the explicit label that was originally assigned to the edit field. Since role=dialog is present on the parent container, it's impossible to get NVDA to read this label.

These behaviors occur for every instance of role="application", role="dialog", and role="alertdialog" on every webpage where these attributes are implemented.

Adding to the problem is that, unlike the sample above which is specifically programmed to be as accessible as possible via tabindex="0" and role="document" as specified by the ARIA documentation, the vast majority of websites that have implemented these attributes have not also implemented these secondary attributes which are necessary to ensure accessibility for screen reader users. In such cases, the textual content within these containers is totally inaccessible to NVDA users, and there is nothing they can do to access it without a sighted person to read the content to them.

For example, you can see that this is built into jQuery UI, within the Dialog widget, at
http://jqueryui.com/dialog/#modal-message
Where, if you try to read the content using NVDA, it is literally impossible. The reason being, that none of the textual content includes these secondary attributes as required by the ARIA spec.
This also means that all websites that utilize this component as is without applying the same secondary attributes as well, will encounter the same accessibility issues for screen reader users. 

To see how widespread this problem is, view the Usage statistics for jQuery UI from drupal.org, at
https://drupal.org/project/usage/jquery_ui
Which is just the tip of the iceberg.

Another example can be seen at: http://www.oaa-accessibility.org/examplep/alertdialog1/
Which is directly referenced within the W3 design pattern documentation, within the section "Alert or Message Dialog (widget)".

If you attempt to read the following text using NVDA, you will notice that it is literally impossible.
"Instructions: In this game you guess a number between 1 an 10 and then press the "Check My Guess" button to check your responses. An ARIA dialog box will display the results of your guess. To start over again to press the "Play Again" button."

The reason being, that role="application" is used to surround the region.

The use of the roles "application", "dialog", and "alertdialog" are useful when you have to capture specific keystrokes such as the arrow keys, Home/End, PageUp/PageDown, and others when implementing a specific widget type.

This should not be generalized though, to say that all modals, dialogs, popups, tooltips, wizards, and similar widget types should include role="dialog" or role="alertdialog", as the ARIA design patterns currently state.

Doing so is guaranteed to cause critical accessibility issues for screen reader users in the future.