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.

Introduction

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
• p15 – 27; Explains 1194.21 – 1194.22 in non-legal terms
• Chapter 2 – Understanding the Section 508 Requirements
• p41 – 44; high-level overview of legal requirements and Usability
• p46 – p48; UI Consistency
• p50 – p53; Accessibility options dialog
• p64 – 67; Color, Visual Cues, and Flash rate
• Chapter 4 – Dev Guidelines That Make Sense
• p115 – 117; Accessibility as a Design issue
• Chapter 6 – Using MSAA
• p183-236 (entire chapter); MSAA overview
• Chapter 7 – Adding Usage Cues to Desktop Applications
• 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.

ControlAccessibleDescription

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.

AccessibleDefaultActionDescription

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

• Page 189 shows “specialized tooltip code for displaying complete accessibility information in C#”
• page 218 shows the code for determining whether accessibility features are enabled, like High Contrast or Sticky Keys.
• 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.”
• 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.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.

View original comments

Last week, Aaron, our Accessibility Program Manager, and I did an informal usability study with a Visual Studio .Net 2003 user who has low vision. I shouldn’t say it was a usability study, since a usability study implies asking the user to perform certain tasks. Instead, we just discussed accessibility with Roger Van Houten, a Program Manager for MSCom and an ASP.NET developer (his name / rank used with permission), asking him where the trouble areas for the Visual Studio environment were and what was on his wish list for accessibility features.

The most surprising thing I learned from the study was that not all High Contrast users use large fonts. On the contrary, Roger said that he found it annoying for High Contrast to just enable large fonts without the user’s consent. Just as it is a against accessibility requirements to override the OS System Settings, vice versa is against accessibility requirements as well. Don’t change OS System Settings, even if you assume it is the right thing to do.

Here are some interesting items that we’ve learned from the meeting:

• Roger uses low font size to scan for info and then increases the font size to read. He increases the font size on-the-fly by using the mouse wheel plus control key.
• Marking keywords using different colors provided no assistance to Roger. Instead, in some cases, the keywords were set to a darker color, making it more difficult to see on High Contrast‘s black backgrounds.
• Roger wasn’t aware that we had an Accessibility section in the documentation.
• Tool windows in their docked position are difficult for a person with low-vision to use, especially if their font size does not increase automatically.

Here is my wish list for future versions…

• Provide all editor text fonts and colors as either white on black or black on white for a pure high contrast distinction. Roger’s best practice example of this was Powerpoints control which allows him to switch back and forth as he needs to.
• Undock all tool windows. In other words, make tool windows behave as if they were files, so the tool window is always “maximized.”
• Provide support for increasing / decreasing font size in the editor via mouse-wheel+control

The more I study UI Consistency and improving the user experience, and the more feedback I hear from customers who use accessibility features, I’m really starting to wonder if Usability and Accessibility are really just two sides of the same coin?

Yes, there is a difference between the two.

• Usability – how well a user understands the UI
• Accessibility – the ability to use the UI

Is it possible to have one without the other?  Is it possible to have good usability without good accessibility?  Is it possible to have good accessibility without good usability?  Let’s say that i have perfect MSAA support for a feature that works perfectly with Assistive Technologies.  Is it possible to have good usability without having good accessibility?

I don’t know yet.

I’m leaning towards “no, you can’t have one without the other because they are the same thing.”  During one of my 28 hours worth of meetings this week, I mentioned that if i went to graduate school for CS, i would probably write my thesis on this topic.

What do you think?

View original comments