Re: Testing Web Accessibility

Hi Charles,

You said:The initial mouse steps are handled by CSS and canvas (setting the
cursor property) well enough

can you send me it's link?

Best Regards

On Tue, Aug 16, 2011 at 12:54 AM, Charles Pritchard <chuck@jumis.com> wrote:

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


-- 
Paniz Alipour