Book Report on “Accessibility for Everybody: Understanding the Section 508 Accessibility Requirements”

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. 

Suggested Reading

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.

·         Chapter 1 – What is Section 508

o        p15 – 27;  Explains 1194.21 – 1194.22 in non-legal terms

·         Chapter 2 –  Understanding the Section 508 Requirements

o        p41 – 44;  high-level overview of legal requirements and Usability

o        p46 – p48;  UI Consistency

o        p50 – p53;  Accessibility options dialog  

o        p64 – 67;  Color, Visual Cues, and Flash rate    

·         Chapter 4 – Dev Guidelines That Make Sense

o        p115 – 117;  Accessibility as a Design issue

·         Chapter 6 – Using MSAA

o        p183-236 (entire chapter);  MSAA overview 

·         Chapter 7 – Adding Usage Cues to Desktop Applications

o        p258 – p271;  How to use MSAA testing tools and Using .Net Accessibility Features


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). 

Show Sounds

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.

AccExplorer Verifications

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. 

Miscellaneous Items

1.      Page 189 shows “specialized tooltip code for displaying complete accessibility information in C#”

2.      page 218 shows the code for determining whether accessibility features are enabled, like High Contrast or Sticky Keys.

3.      page 210-11 is a feature request for .Net Framework.  “One of the first problems you’ll notice with the .net Framework is a lack of support for direct Windows Accessibility feature manipulation.  You can check the status of High Contrast, cursor size, and showsounds setting using properties in the SystemInformation class, but that’s about it.”

4.      page 259 is a feature request for .Net Framework about providing support for the MSAAtext 1.0 Type Library found in the MSSAText.Dll file. 

Interesting links

http://www.hollyworks.coma “section 508 compliant web site”, as quoted on page 70.,1282,49716,00.htmla glove that translates sign language to text messaging for the blind Mate, Pocket PC for the blind. your images and vischeck will show you how a color blind user would see them.

Comments (0)

Skip to main content