Re: Testing Web Accessibility

The article does not really cover mouse accessibility, sorry about the 
confusion.

The initial steps of ensuring that pointer-events are accessible include
making indicators to the user, such as adding style to the cursor or style
to the underlying window area.  That said, "hover"-alone is not sufficient,
as users may be on touch screens.

It's important that clickable areas be large enough to identify on a 
small screen,
large enough to press accurately, when using a touch screen, and not 
require
dexterous maneuvering... Often there are popup menus that, if the user 
slightly edges
their mouse off the menu, the entire menu disappears.

These are -mostly- issues with the visual design, appropriate use of 
CSS, title,
colors and spacing, handles most of them.

http://www.google.com/search?q=mouse+accessibility
http://www.bltt.org/accessibility/mouse.htm
http://www.syntagm.co.uk/design/articles/fitts50.htm
http://www.accessvt.atc.vt.edu/standards/links.html
"9.3 - Avoid using small images and text as links."



  On 8/16/2011 3:04 AM, paniz alipour wrote:
> 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 
> <mailto: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
>
>     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