The W3.org Modal Design Pattern is lacking instructions for hiding background content from screen reader users.

This is in regard to the page and section at
http://www.w3.org/TR/wai-aria-practices/#modal_dialog
and
http://www.w3.org/TR/wai-aria-practices/#dialog_modal

Specifically:

"WAI-ARIA provides for two dialog roles - dialog and alertdialog. When authors simulate dialogs on a web page they often limit their interaction considerations to the mouse. Unlike Graphical User Interface dialog boxes on a desktop computer, a user during keyboard navigation could accidentally navigate outside the dialog box and become disoriented. This can happen when the user is tabbing in the dialog. A modal dialog prevents the user from setting focus outside of the dialog until the dialog is closed. Mouse clicks outside of the dialog must be ignored and the user must not be able to tab into or out of the dialog itself. All WAI-ARIA enabled dialog boxes should be modal. This section describes how."

This is incorrect. The use of the roles "dialog" and "alertdialog" don't make a dialog modal, since all background content remains visible and actionable to screen reader users regardless. This can be seen using JAWS in IE and FF, plus Voiceover on iOS devices. Additionally, as submitted previously, the use of these roles, has serious ramifications that all developers need to take into account, and should not be generally applied to all modals.

"When the dialog box is opened, focus should be set to the first tab focusable element within the dialog."
and
"make it visible and set focus to the first tab focusable item in the dialog box."

If the dialog includes important instructional information at the beginning of the dialog, or required license agreement text for example, setting focus to the first active element is likely to cause screen readers to skip passed all of this information when focus is set. It would be more helpful to set focus to the beginning of the dialog when it opens, and then, to manage focus appropriately when Tab and Shift+tab are used after that point to enforce circular tabbing.

"Search the contents of the dialog container to find the first and last tab focusable elements. This can be implemented by walking the DOM tree of the dialog container to find all visible and enabled anchor elements, input elements, and all elements that have a tabindex value greater than or equal to 0. Remember that elements with a tabindex > 0 will appear in the tab order before all other focusable elements in ascending order by tabindex. Store the first and last tab focusable items within variables in the scope of the dialog box code."

This can also be achieved using the HTML5 data attribute to specify the first and last active elements, then simply query the nodes using a CSS selector to identify which is which, thus increasing speed.
E.G
<input type="text" name="username" data-first="true" ... >
...
<button class="cancelBtn" data-last="true" ... >

What is not addressed by this section is that, in order for a modal to be truly modal for screen reader users, the background content must be hidden from screen readers. Otherwise the background content can be navigated using the Virtual Cursor regardless.

Here is one way to do this effectively, which does not require role="dialog" or role="alertdialog".

. When the modal is rendered, append the modal container to the body element so that it is a first level child of the body element.
. Set aria-hidden="true" on all other first child nodes of the body element, excluding the modal container element.

Then, when the modal is dismissed or canceled:

. Set aria-hidden="false" or remove the attribute on all other first child nodes of the body element.
. Return focus to the triggering element after the modal is dismissed.

This can be tested at the following location, which includes all of the above mentioned concepts.
http://whatsock.com/tsg/Coding%20Arena/Modals/Modal%20(Internal%20Content)/demo.htm
Functionality verified using JAWS and NVDA in IE, FF, and Chrome, plus Voiceover in iOS Safari.