- blog n.
- Website on which an individual or group of users produces an ongoing narrative.
15 06/2009To mode or not to mode?
As regular visitors will know, we’ve recently re-built our site from the ground up, deleting old features and out-of-date content and introducing some new features along the way.
After perusing Modal Windows In Modern Web Design at Smashing Magazine it got me thinking about using a modal window for our contact form or PropellerMail login form. This would look cool and speed things up for regular visitors but what about accessibility?
I’ll come to Damien’s response shortly but this morning I noticed this great tutorial – Integrate Thickbox with a contact form on TXP Tips and the reminder prompted me to start writing. Now before I go further, I just want to state that I’m not criticising either Smashing Magazine or TXP Tips as both are well put together, helpful articles, neither am I an expert in this area but with Modal windows seeming (for obvious reasons) to be flavour of the month, I just wanted to discuss the accessibility ramifications and hopefully some higher powers will swing by and add their experience to the discussion.
Damien McCormack from Vision Australia had this to say about it:
âEven for screen readers that can detect dynamic changes, the update (e.g. displaying a lightbox) is identified by a visual change on the appearance of the page however there is no equivalent notification for a screen reader user that new content has appeared â it is just there if they keep reading through the page. Where the new content for the lightbox appears is also important as the screen reader user will only meaningfully notice the new content if it appears as the next thing on the page.
For example if the lightbox is displayed after the user presses a Contact Us button, the new content needs to occur immediately after the code for the button for it to be meaningfully visible â however the screen reader user is likely to wonder what, if anything, happened when they pushed the button because they will not receive any notification.
Finally, because the screen reader user is actually moving through the page using a specific reading cursor provided by their assistive technology there is nothing to constrain this cursor to the modal area of the lightbox. Therefore the screen reader user can actually access any of the content on the page even if it is not part of the modal window. This could happen because they are reading through the content unaware that it is part of a lightbox, or more likely because the person uses link or heading navigation which accesses the entire page. Once the user moves outside the modal area it could be very difficult for them to identify the specific action they need to complete to get past the modal window and will probably lead to further confusion as they try and do things on other areas of the page that donât work because they are not part of the modal window.
At this time, we therefore recommend that lightboxes are not used. If modal functionality is required then this should be implemented using either dialog boxes or by loading a new page.â
I did wonder if there were satisfactory fallbacks for those who do want to utilise these kinds of functions – perhaps providing a standard contact page in addition to the modal window? This could offer the best of both world’s though on another hand it could confuse matters more – by providing more than one link to the same or similar resources, this goes against the guidelines and for those using screen-readers, how would they know which to use – an informative title attribute perhaps?
No doubt the discussion will go on and regardless of the accessibility factors, people will continue to use modal windows in increasing numbers (just use Facebook for five minutes and you’ll work your way through them) – perhaps its time for screen-reader vendors to develop a solution (if indeed they haven’t already). For now, however, I’ve decided to stick with the current contact and login pages.