Can a modal dialog be made to work properly for screen-reader users on the web?
A while back I started a discussion in the jQuery Accessibility group: Screen-readers and UI modal dialog. I was really happy with the quality of the discussion that my question generated, and thought I'd take a moment to share some of my thoughts and conclusions. I want to be clear that the ideas that I am sharing here were only made possible through the people who were so willing to collaborate with me in this discussion.
What is a dialog?
A dialog is a little window or box that pops up over-top of the window that you are currently working in and generally asks you a pretty simple question. For example: "Are you sure you want to quit without saving your changes? Yes, No". A dialog is modal if it prevents you from being able to access its parent, or the window underneath. You may be able to see the underlying window, but you cannot interact with it.
On the web there are two ways that a dialog can be generated. The first way is if a dialog is generated by a web browser itself, the second way is if a dialog is generated by a client-side-scripting language (usually Javascript with some CSS for positioning and style). An example of a browser generated dialog might be a prompt asking you if you would like to Run or Open a file you are downloading, while An example of a scripted dialog might be a prompt asking you if you are sure that you want to delete the blog article you just posted.
Note: that using a client-side-scripting language you can invoke some types of browser dialogs.
What is the challenge for screen-reader users?
Being a screen-reader user I tested several modal dialogs, including the jQuery modal dialog, with several screen-reader / browser combinations. In short, the user experience was unpredictable and ranged from the existence of the dialog not being reasonably perceivable to the user, to not all of the content in the dialog being perceivable to the user. It is important to note that best practices have been developed explaining how to create an accessible modal dialog, however it would appear that even when following these practices modal dialogs cannot be made accessible for screen-reader users.
Technologies
Firefox 3.6 and JAWS 11
Firefox 3.6 and NVDA 2009.1
Safari 4.0.4 and VoiceOver (OS X 10.6.2)
Results of Testing
Firefox 3.6 and JAWS 11
When activating the modal dialog nothing appeared to happen. Once I refreshed the JAWS virtual buffer and navigated to the bottom of the page I was able to find the dialog. The dialog was "modal" to the extent that I could not activate links on the underlying page, however, there was no indication that the links were disabled, they just simply didn't work.
Firefox 3.6 and NVDA 2009.1
When activating the modal dialog NVDA announced the title of the dialog. I was unable to navigate the content of the dialog with the standard NVDA reading keys. When I pressed tab NVDA announced the Close button. I was still unable to access any of the other content in the dialog. The dialog was "modal", I was unable to interact with the underlying page, including not being able to read any of the content from the underlying page.
Safari 4.0.4 and VoiceOver (OS X 10.6.2)
When activating the modal dialog nothing appeared to happen. When I navigated to the bottom of the page I found the dialog. The dialog was "modal" to the extent that I could not activate links on the underlying page, however, there was no indication that the links were disabled, they just simply didn't work.
The problems identified in testing modal dialogs with screen-readers can be broken down into two general groups. 1. Problem with perceiving the existence of a dialog, and 2. problem with accessing the content within the dialog, separate from the content of the underlying page.
Problem with perceiving the existence of the dialog
This problem is caused either by focus not being set to the dialog after it is appended to the page, or with the screen-reader (JAWS 11 / VoiceOver OS X 10.6.2) not respecting the change in focus. I will not discuss this issue further here other than to say that it is an area where further research should be performed to identify the exact cause of the problem.
Problem with accessing the content of the dialog, separate from the underlying page
This problem can be broken down into two issues. 1. Problems identifying what content is in the dialog and what content is part of the underlying page; and 2. not being able to access all content in the dialog. The cause of both of these problems is that there is no markup or technology through which a developer can communicate to assistive technology that a certain portion of the page is meant to be interpreted as a modal dialog. The ARIA 1.0 W3C draft recommendation does provide roles and states that can be used to communicate to assistive technology that a portion of a page is meant to be interpreted as a dialog, however, there is no state or property to indicate the modality of the dialog.
The reason that NVDA does respect the modality of the dialog is that it respects the ARIA application role that is set on the dialog. This role tells screen-readers to interact with the portion of the page as if it were an application, and not as if it were a document. This means that users will be restricted to the same tab boundaries as users who do not use screen-readers. The problem with this is that once a screen-reader switches into application mode users are no longer able to interact with the page, particularly the dialog, using the standard reading keys. The only portions of the dialog that will be read are those that can receive tab focus.
JAWS and VoiceOver do not exhibit the problem that NVDA exhibits, because these screen-readers do not respect the application role. JAWS will respect the role if it is applied to the body element of a document, VoiceOver does not respect the role at all. This leads to a separate problem. Users are able to use the standard reading keys to interact with the dialog, but they are not bound by the boundaries of the dialog and can therefore read the content from the underlying page, making it difficult to understand the concept that the dialog is modal and floating as a virtual window over top of the original page.
Recommendations for improving the accessibility of modal dialogs
1.As the purpose of the ARIA application role is to make a portion of a page behave as an application and not as a document, and as there may be document style text within a dialog it is likely not useful to apply the application role to a dialog.
2.As there is no standard method for developers to communicate to assistive technology that a dialog is modal ARIA should adopt a modal state for dialogs, which assistive technology vendors can choose to interpret as they see fit.