W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

Looking at an a11y extension for magnifiers

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 15 Apr 2011 12:38:08 -0700
Message-ID: <4DA89EA0.4040800@jumis.com>
To: public-fx@w3.org, "www-svg@w3.org" <www-svg@w3.org>
I'm looking for feedback / ideas on new ARIA attributes relating to SVG 
/ coordinate space information.

Consider the case where an SVG/Canvas element is used to manage an 
underlying HTML form element:
the association needs to be made, for focus events, so that, when a user 
"focuses" on the displayed
element, the underlying HTML form element also receives focus events.

This has more-or-less been solved via aria-activedescendant and the 
Canvas drawFocusRing method.
The pointer-events attribute is another asset of SVG relating to 
clickable events.

An SVG-based may employ visually complex paths, to present a relatively 
simple clickable region.
For basic authoring, things may stop there.

For more complex cases, transparent elements may be used to setup 
clickable regions. And that's something
we generally would like to avoid.

In the following example, the complex path may be a star-like-shape, 
with long spokes reaching far away from the center
area. In this case, a screen magnifier, calculating the centroid and 
bounding box, would attempt to show the entire shape.

By supplying additional information, via aria-* semantics, the magnifier 
could instead zoom-in, showing only
part of the shape.

<path d="complex path" aria-d="simple path" 
aria-activedescendant="submit"><input id="submit" type="submit"></path>

This would also be useful for touch based devices where a complex shape 
would not be useful,
but a simpler shape with some fidelity to the original, would be useful.

Currently, the pointer-events property, and a transparent element would 
have to be used to get this effect.


While -ideally- accessibility software can simply walk the DOM and get 
computed values; and that's often
the case; there are cases where more information needs to be expressed. 
That's where ARIA has given us
a wealth of vocabulary, and could be extended to allow authors to 
specify additional a11y information.

The next draft of ARIA (aria 1.1?) will likely need to address a11y 
issues brought up in SVG/HTML Canvas.
For those unfamiliar with ARIA, I recommend reading T.V Raman's post 
prior to reading through the spec:

Current ARIA 1.0 draft:

Received on Friday, 15 April 2011 19:38:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC