Re: Looking at an a11y extension for magnifiers

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