Testing Web Accessibility

Though I hope to see a revised article in the near future, the following 
link gives a pretty good breakdown
of what kind of "accessibility" we're hoping to achieve with our 
canvas-a11y work.

http://msdn.microsoft.com/en-us/library/ms971307.aspx

Going through the list:

Introduction
What Is Keyboard Accessibility?
Keyboard Steps
Mouse Steps
How to Test Keyboard Accessibility
What Is High Contrast?
How To Test High Contrast
Explanation of Focus and Selection
<snip>
How to Test for Assistive Technology Compatibility
Conclusion

Here are my comments on that list:

We've covered the keyboard steps. With DOM Core (events) and the canvas 
subtree.
The initial mouse steps are handled by CSS and canvas (setting the 
cursor property) well enough.

High contrast mode is not something we have access to, and, it's 
something that can mean different things across platforms. OS X high 
contrast is very different than Windows high contrast. That said, we're 
able to meet WCAG standards in Canvas applications by simply following 
the standard to begin-with -- that is, by using appropriate contrast 
between foreground
and background colors. I don't think high contrast is a canvas-api 
issue. It's a design consciousness issue, and can easily be done by 
filing in appropriate fillText and fill colors.

Focus and selection are covered well by DOM, ARIA and again, the 
drawFocusRing and associated canvas
APIs that we've gone over.

And that takes us to the end of the article:
"How Microsoft Active Accessibility Works for a Custom-Drawn Button"
"Microsoft Active Accessibility ...  IAccessible object through 
AccessibleObjectFromWindow, AccessibleObjectFromEvent, and so forth... a 
pointer to the IAccessible implementation. Since it is custom control, 
the developer has implemented IAccessible, so a pointer to this 
implementation is returned. The client calls IAccessible::get_accName"

"How to Test for Assistive Technology Compatibility"

"The Microsoft Active Accessibility information must be correct to 
support Assistive Technologies. So, the first thing to test is Microsoft 
Active Accessibility. Inspect is a great tool to view the IAccessible 
properties and method of a particular control. However, there is no 
mechanism to tell you if the properties or methods are supported correctly."


I can tell you that I have opened up Inspect, and looked at the 
resulting accessibility tree in Microsoft's IE9, currently the browser 
with the best canvas accessibility support. The actual tree has various 
items that are matter of human interpretation -- much of the tree 
represents human language and human interaction. That said, it's 
reasonable to look at the tree and its data set, and figure out whether 
the data is sufficient to be understandable by an end user. The same 
goes for simply looking at a design and trying to use it.

Currently, the bounding box information is missing in the tree. 
Otherwise, we have a fully populated tree, in large part because ARIA 
and the canvas subtree are working very well in IE9.


I'm bringing this up, again, because it seems many on the list are 
examining "use cases" of accessible canvas, forgoing the chore of 
examining the existing APIs that we're trying to solve.  While there is 
a time and place for invention, I urge people to post-pone such 
inventions until we have met our existing commitments to the IAccessible 
infrastructure.


-Charles

Received on Monday, 15 August 2011 20:25:11 UTC