There is a book out on the market for Accessibility called Accessibility For Everybody: Understanding the Section 508 Accessibility Requirements, a 500 page book written by John Paul Mueller and published by APress in 2003.
A few months ago, a dev on my team discovered a book called Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements. As stated on the front cover, “The only book on the market to target Section 508 requirements!” I ordered the book to come to a local Barnes and Nobel, so I could view its contents. I randomly opened the book to page 51. It showed a picture of the “Accessibility Options” dialog under High Contrast. Its caption reads, “Failure to plan for user needs often result in applications that don’t work in Accessibility modes.”
I immediately purchased the book.
Much of the book contains what I’d call filler, just information to fill up a space in a chapter. The author spent a significant percentage (perhaps as much as a quarter) of each chapter trying to sell accessibility to its audience. I believe that most people are reading this book because they must support accessibility in their product or website, not because they are interested in learning about accessibility.
These chapters or pages within chapters remove all of the filler sections, so you are only reading the most relevant information. Note that this is only for non-web-based applications, as I haven’t finished reading the web-based apps yet.
Items I Disagree with
OK and Cancel and keyboard shortcuts
The author states on page 62,
“The OK button is the default action, so you could activate it by pressing enter. The user will know that this is the default action because there’s a dark square around OK. However, there’s no obvious quick method of accessing Cancel. You can activate it by pressing Escape, but this is hardly common knowledge and leads to usage problems. In short, all of the buttons should have speed keys associated with them.”
Within Visual Studio and many other windows application, it is standard for enter to activate OK and ESC to activate Cancel. I can’t see how not having a shortcut key for the Cancel button can lead to usage problems. One of our customers mentioned to me that it could be problematic to use enter as the OK button’s accelerator, which I can completely understand. But pressing ESC is basically saying, “do no harm” or “get me out of here,” hence it is the escape key.
The author states on page 157,
“This entry says that the application lacks an accessible description that someone with special accessibility devices will require when using your application.”
The only place in the MSAA SDK that absolutely requires a control to have a description is a list view with headers, where the description contains the information in any additional columns for that list item. Otherwise, description isn’t required or isn’t used by an Assistive Technology device (or at least the ones I’ve worked with).
The author states on page 206,
“The ShowSounds feature tells Windows XP and your applications to display captions for the sounds they make. This includes speech. Instead of actually making the sound, the system requests that the application provide a description of the sound in a balloon help dialog.”
This is incorrect. ShowSounds is for Closed-Captioning in Multi-media content only.
The author states on page 264,
“Notice that the application passes most tests, but it fails in a few important places. For example, the get_accDefaultAction test fails because the example doesn’t define this value using the AccessibleDefaultActionDescription property described in the ‘Using the AccessibleDefaultActionDescription Property’ section of the chapter.”
A dialog’s default action is either the name of the control with the default activation or “Press.” Either is acceptable. If there isn’t a default action, it is okay to return null. For example, static text performs no action, so it is okay to return DISP_E_MEMBERNOTFOUND.
These verifications the author is referring to are for an Assistive Technology Vendor, not for internal debugging.
Figure 7 – 11 on page 265 has the caption, “Running the accessibility tests shows flaws in your application setup.”
No. These verifications are for an Assistive Technology Vendor. They are not for internal debugging. And the Help Topic returning junk value is a bug within AccExplorer. You cannot rely on these verifications to tell you whether or not a property or method is implemented correctly.
http://www.hollyworks.com – a “section 508 compliant web site”, as quoted on page 70.
http://www.wired.com/news/technology/0,1282,49716,00.html – a glove that translates sign language to text
http://news.bbc.co.uk/1/hi/technology/2403913.stm – text messaging for the blind
http://www.microsoft.com/presspass/features/2002/Oct02/10-16NDEAM.asp – PAC Mate, Pocket PC for the blind.
http://www.vischeck.com/vischeck/vischeckImage.php – upload your images and vischeck will show you how a color blind user would see them.