Geeks With Blogs
CodeSeeker Just another developer trying to do the right thing

I recently wrote an internal memo identifying accessibility problems with Telerik RadWindows for the website I'm currently working on. I post the items here hoping that they might be useful for some of you out there. Some of this is specific to our environment (IE6) and design standards but may be helpful for you too. Some apply to other modal window implementations as well.

1. Modal windows complicate the page. One of the primary axioms of designing for accessibility is simplification. I also experienced this first-hand when working with a visually impaired user: more stuff on the screen makes it harder to create a mental picture of the screen, and to navigate around and work with the screen.
2. Cursor focus manipulation is inconsistent. The screen reader reads from the cursor focus location on the screen. In order to help the user not to get "lost" on the page, when for example, checking a checkbox causes the screen to refresh, we programmatically force the cursor focus to be placed back on that same checkbox. Otherwise the focus would just land at the top of the browser in the address bar and since the user can't see that a page refresh happened, the user gets confused as to why the cursor moved there. In modal windows, even though the program code specifies that the focus should be set at a specific location, it works inconsistently for some reason.
3. The same focus manipulation issue exists for our standard for error/success messages, but is even worse. Setting the focus requires something clickable to set the focus on. Our standard design for messages places text on the screen which does not accept the focus directly. Setting the focus on a clickable page element directly above the message works, but only maybe 10% of the time for some reason. This is not only inconsistent, but dramatically so. As a workaround, we implemented messages in another popup (using Javascript) when they occur on a modal window. This helped, but is now inconsistent with messages elsewhere in the system.
4. Accessible solutions for modal windows are inconsistent with our standard page designs. Another axiom of designing for accessibility is consistency. If all of the pages behave and are laid out the same, even if the pages are complex, it becomes easier to use the system because the pages are familiar. As noted above, and in other situations as well, the guidelines that were developed for accessibility within modal windows are different than for standard pages.
5. RadWindows are not truly modal. Non-visual users are keyboard users. When working with a RadWindow, users can still tab onto and work with the parent page with the keyboard. The definition of a modal window states that the user cannot interact with the parent page while the modal window is active. Unfortunately, Telerik's attempt at implementing a modal window in the web environment falls short. It works for mouse users, as you cannot click on the parent page or any of its controls with the mouse while the modal window is active. But when using only the keyboard, you can tab onto the parent page, edit values on the parent page, and even submit information on the parent page while the modal window is active.
6. Implementing accessibility for modal windows is more time consuming than for standard pages. In addition to all of our standard developer guidelines for implementing accessibility, there are a number of additional guidelines for working with modal windows. Additional testing must also occur in development and QA.

We did some brief testing with the ASP.NET AJAX ModalPopup control and with modal windows that included some complexity, it had problem #5 as well, even though the online example does not. The ModalPopup would also have problems #1 and #6. I'm not sure about #2 or #3, and #4 is possible if accessibility was not considered in your page designs from the ground up.

Posted on Thursday, November 6, 2008 1:50 PM | Back to top

Copyright © Mike Ellis | Powered by: GeeksWithBlogs.net