- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 18 Apr 2011 15:28:44 +1200
- To: Charles Pritchard <chuck@jumis.com>
- Cc: public-fx@w3.org, www-svg@w3.org
Hi Charles. I am not overly familiar with ARIA, so please correct any misconceptions I have about it below. Charles Pritchard: > 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. Am I right in thinking that aria-activedescendant is a way to inform the AT about which element in the document is focused, when focus is being faked by the author (i.e., the author is not using built in focus, as you would get with tabindex="")? > 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. Why is that something you want to avoid? It is quite a common technique used in interactive SVG documents. > 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. I guess what you want is a way to indicate to the magnifier what the “main” region of some element is. What are the rules for how magnifiers determine the region to zoom in to currently? Is it always the bounding box of the currently focused element? Or is it based on which region is interactive, and which descendant elements have mouse event listeners added to it? > <path d="complex path" aria-d="simple path" > aria-activedescendant="submit"><input id="submit" > type="submit"></path> I don’t quite understand what having an <input> child of the <path> is meant to do. If I’m right, the <path> is meant to be an alternative presentation of the <input>. Is it a child because the only way in ARIA to specify a different element that is considered to have the focus is by using aria-activedescendant=""? Presumably this is in an HTML document that includes SVG content, but having <input> be a direct child of the <path> would be non-conforming. When parsed from text/html, it would be created as a {http://www.w3.org/2000/svg}input element instead of {http://www.w3.org/1999/xhtml}input, as I understand it. Wrapping the <input> with a <foreignObject> should solve that, though. So the markup could be like this, instead: <g aria-activedescendant="submit" aria-interestingregion="simple path"> <path d="complex path" onclick="$('submit').submit()"/> <foreignObject> <input id="submit" type="submit"> </foreignObject> </g> This is assuming that you want the exact <path> to be clickable, but to present some smaller region to the magnifier as the region to zoom in on when this element is focused. If you actually want only that smaller region to be clickable, then I would recommend using a transparent element: <path d="complex path" pointer-events="none"/> <g aria-activedescendant="submit"> <path d="smaller path" visibility="hidden" pointer-events="all" onclick="$('submit').submit()"/> <foreignObject display="none"> <input id="submit" type="submit"> </foreignObject> </g> Then we can leave off the aria-d="" (or aria-interestingregion="" as I called it above!), since the bounding box of the <g> is what you want the mangifier to use as the region to zoom in on. How do you achieve this kind of thing in HTML, incidentally? Let’s say you have this document: <!DOCTYPE html> <body> ... <p>Please enter your full name: <input name="fullname"> ... How could you ensure that a magnifier will, when focus is on the <input>, show the preceding text indicating what to type in to it? The idea of associating a region to zoom in on which is different from the bounding box of the focused element (or however mangifiers actually determine the region) doesn’t seem SVG specific. (Incidentally, I feel like whatever we end up with as a component solution – XBL2, Web Components, or something else – would be better suited to the task of providing an alternate presentation of an <input>, rather than having it as a hidden descendant element.) > 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. Yes, but that seems to work reasonably well. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 18 April 2011 03:30:43 UTC