This site is under development with an unstable development version of Drupal 7 for testing purposes.
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.
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.
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
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.
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.
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.
Comments
Disclaimer: I'm one of NVDA's
Disclaimer: I'm one of NVDA's lead developers. :)
Thanks for this thoroughly researched and well written article. However, I strongly disagree on several points, which I will attempt to outline below.
There is no real difference between a modal dialog and a modeless dialog as far as a screen reader is concerned. When examining these issues, it's important to consider desktop applications, as that is essentially how rich internet applications are intended to appear and operate. Whether a dialog is modal or modeless in a desktop application, you still cannot access the content behind it without using your review cursor or, in the case of modal dialogs, by switching application windows. Both dialogs are reported the same way. Therefore, I don't think there is a need for a modal state except perhaps for informational purposes for the user; the screen reader should not treat these any differently to any other dialogs.
You argue that NVDA's treatment of the dialog role as an ARIA application is a problem which needs ot be fixed. Following the same principle as above, I would argue that a dialog *should* be treated as an application; you should not be able to access information outside the dialog without using your review cursor. Otherwise, the interaction is different between ARIA dialogs and dialogs in traditional desktop applications. Failure to do this means that the user would interact with the dialog like they do with a document, which is (in my opinion) very incorrect and broken behaviour.
You note that when activating the dialog, NVDA announced the title of the dialog but nothing else. The dialog should have automatically set focus to the close button (as is standard behaviour for dialogs in desktop applications; i.e. set focus to some focusable child). The content not being read automatically is something we would need to consider more closely. NVDA has very specific rules about what should be considered "dialog text", but these obviously aren't matching here. I think the dialog should probably set aria-describedby to indicate the caption text, but again, we would need to consider this more closely for this particular case. You note that you were unable to navigate the content of the dialog with the standard NVDA reading keys. This depends which "standard NVDA reading keys" you are referring to. Certainly, you are unable to use the document reading keys here, but this is because a dialog isn't a document. You can, however, use the NVDA review commands as you would in a dialog in a traditional desktop application.
Interesting article. I
Interesting article. I noticed that Internet Explorer was not included in the test. Given the results I expect it and the screen readers would behave similarly.
I do bring htis up though as it seems that IE has its own (proprietary?) modal dialogs that can be generated. THey may be XAML based? You can experience them in certain parts of the online QuickBooks application. These dialogs do seem to solve the problem of identifying to the screen reader what part of the page is active and meant to be a dialog. Again, this could be IE specific and not be a technique Firefox or others have implemented, I do not have enough information. Perhaps you know?
It does suggest at a solution however: that the browsers and screen readers need to combine efforts to display modal dialogs. Perhaps an ARIA role of "modal-dialog" could be added? ...
@James Thanks for the
@James
Thanks for the comments.
In my opinion there are three issues that need to be addressed.
1. Users have to understand the distinction between the dialog and the underlying document.
2. For modeless dialogs users need an easy way to switch between the dialog and underlying document.
3. Users need to be able to use standard reading keys to access the content of the dialog, unless it truly is an ""application".
NVDA does 1 and 2 quite well. For 3 it is worth noting that you and I may agree that all dialogs * should * be applications. However, the multiple ways that developers may choose to implement a modal dialog (for example the Drupal 7 Overlay) shows that not all implementations of dialog are going to fit into the dialog as application paradigm. For those who are unfamiliar, in Drupal 7 a modal jQuery dialog is used to float an administration page over the underlying page from which the user activates the administration page. To argue that this "dialog" is an application would be to argue that any administration page in Drupal 6, or any other CMS, is an application, which in my opinion they are not.
One might argue that dialog implementations similar to the Drupal Overlay are not actually dialogs, but as they serve the same purpose, to float one document window separately and modally above another, then I believe that a use-case can be established for a aria modal state for dialogs.
At the end of the day an effective and robust method to allow developers to specify that a section of a document is modal, but not necessarily an "application" needs to be established.
Add new comment