Re: Looking at an a11y extension for magnifiers

On 4/17/2011 8:28 PM, Cameron McCormack wrote:
>> 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="")?
I prefer to use the term "managed" and "implemented" in place of "faked" 
and "emulated".
The latter have connotations that it's a work-around, whereas the former 
suggests that the
methods are part of normal and expected practice.

Yes, it informs the AT about the element in focus.
It's does not necessarily exclude tabindex -- it may be used in addition.

There's a simple example here:
http://www.w3.org/TR/wai-aria/usage#managingfocus
A user may focus on a large grid, with the scripting environment managing
which column the user is actively focused on, via aria-activedescendant
The user is likely using arrow keys, or the mouse, to navigate the grid.

>> 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.
Apologies for using "we" without qualification: in HTML/CSS, the scripting
environment is more often used for processing mouse events, and superfluous
DOM nodes are something to avoid.

However, it certainly makes sense that in SVG, with its advanced path 
management,
DOM nodes would have a more flexible role in managing pointer events.

When working with HTML+Canvas backward compatibility, I do
use the same technique with the box model -- I will lay the element
I want the AT/UA to respond to, on top, and make it transparent,
via opacity: 0, or other techniques.

As long as appropriate ARIA vocabulary is used [when needed], extra SVG 
path elements may
be a reasonable long term technique.

>> 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?
Rules only apply to the UA. The AT may use any heuristics the AT author 
puts in there.

The UA is required to send bounding box information on focused elements, 
and modern UAs
expose simple DOM to the AT, so the AT can query for more information, 
beyond that shared
by simple accessibility events.

An AT may zoom into a region that's not even in focus.

Consider text search operations, where a magnifier moves around the screen
as the user hits "next result", for a particular text string query.

>> <path d="complex path" aria-d="simple path"
>> aria-activedescendant="submit"><input id="submit"
>> type="submit"></path>
>
> 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>
Thanks for putting this together. Sorry about the non-conformant code.

> 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.
Would display: none exclude the input element from receiving DOM events?

With css, style="display: none" would exclude events,
style="visibility: hidden  -or- transform: scale(0,0)" are used.

Lets continue working with this example, and get AT vendor feedback.

It feels like it's still missing some reference, letting the AT know
that "smaller path" represents <input>, and that <g> represents "complex 
path".

The aria-owns attribute may be enough to convey that information.
http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/#relations_owning

> 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 <label> tag, and aria-describedby would both work.

There are no assurances from the AT:
the AT interacts with the soup that semantic XML, css and aria have to 
provide.

I'm saying soup, in some jest, as WCAG sets out best practices and documents
some de facto standards.

> 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.
It's not SVG specific. HTML Canvas also requires this.
That's why drawFocusRing was added to the canvas 2d context standard.
> (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.)
I agree, that XBL2 and Web Components face the same issue.
I don't think that's an exclusionary condition.

It's quite possible that web components would be built from an SVG 
compliant tree.

<foreignObject> is a suboptimal solution for dynamic SVG,

aria-owns and other descendant controllers do allow for the element
to be outside of the SVG tree.


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

I'd like to continue exploring mixed uses of SVG and HTML
as they relate to exposing information to an AT.

With an understanding of how it should appear in a live DOM,
we may discover cases where SVG is inaccessible to the AT,
or otherwise requires aria markup.

I'm here to explore what exists, how we can make it work
with available standards, and to see if new methods or
attributes are needed by the AT and/or content authors.


-Charles

Received on Monday, 18 April 2011 21:47:45 UTC