Re: hit testing and retained graphics

Rich Schwerdtfeger
CTO Accessibility Software Group

Doug Schepers <schepers@w3.org> wrote on 07/07/2011 12:07:17 PM:

> From: Doug Schepers <schepers@w3.org>
> To: Steve Faulkner <faulkner.steve@gmail.com>
> Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, Charles
> Pritchard <chuck@jumis.com>, Henri Sivonen <hsivonen@iki.fi>, Sean
> Hayes <Sean.Hayes@microsoft.com>, "E.J. Zufelt" <everett@zufelt.ca>,
> Paul Bakaus <pbakaus@zynga.com>, "Tab Atkins Jr."
> <jackalmage@gmail.com>, John Foliot <jfoliot@stanford.edu>, Charles
> McCathieNevile <chaals@opera.com>, Richard Schwerdtfeger/Austin/
> IBM@IBMUS, Cameron McCormack <cam@mcc.id.au>, Cynthia Shelly
> <cyns@microsoft.com>, "david.bolter@gmail.com"
> <david.bolter@gmail.com>, Frank Olivier
> <Frank.Olivier@microsoft.com>, "Mike@w3.org" <Mike@w3.org>, "public-
> canvas-api@w3.org" <public-canvas-api@w3.org>, "public-html@w3.org"
> <public-html@w3.org>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
> Date: 07/07/2011 12:07 PM
> Subject: Re: hit testing and retained graphics
>
> Hi, Steve-
>
> Steve Faulkner wrote (on 7/3/11 8:16 AM):
> >
> > For example if I increase the magnification in my browser to 200%, when
an
> > element or object receives focus is offscreen, the view changes so it
is no
> > longer offscreen. This does not happen if the objects are represented
on the
> > canvas, regardless of whether they are local or remote.
>
> That's because "there is no there there".  In a purely graphical
> display, as with the immediate-mode of the Canvas 2D API, there's no
> demarcated area for the magnifier to focus on.  There are several
> solutions to this:
>
> 1) Make AT that is is "smart" enough to identify an important shape,
> zoom in on it, and track it if it is moving (this seems like a hard
> problem, but wouldn't need any changes to specs);
>
That is hacking Doug. The author knows more about this than the AT.
Furthermore, it may not event be the shape that is important. It may be the
collection of UI drawing calls that were used to form a widget that be what
is important. Also, we don't want AT's hacking display driver drawing calls
either. As an industry we are trying to get away from that.

> 2) Make the shape, size, and position information available through a
> special accessibility API, updated and maintained in parallel to changes
> to the rendered shape;
>
I have suggested this, but, this also means the author must be responsible
for:

- Transformations
- Scrolling adjustments
- Potentially: Browser window moving adjustments.

> 3) Make the shape, size, and position information available through a
> standard API attached to a DOM element; some of the existing proposals
> on what this element could be include:
>
> 3a) an imagemap (HTML5 <map> element with <area shape="circle |
> rectangle | polygon">), updated and maintained by the author in parallel
> to changes to the rendered shape;
>
Ian and others from the browser working group shot this down. Also, you
have to remember that script is attached to this and the UI will change. We
are not talking about a fixed image map.This is probably why they shot this
down.

> 3b) a canvas subtree element (perhaps a <div>) with @aria-region,
> updated and maintained by the author in parallel to changes to the
> rendered shape (Cameron's proposal);
There are a lot of things in the canvas subtree that will need to be
updated in addition to this.

>
> 3c) a canvas subtree element with some other additional semantics,
> updated and maintained by the author in parallel to changes to the
> rendered shape, or perhaps automatically updated and maintained via the
> same API that the author uses to change the rendered shape (Charles and
> Rich's proposal;
>
> 3d) an SVG element, automatically updated and maintained via the same
> API that the author uses to change the rendered shape (Doug's proposal).
>
>
> I've already stated [1] why I think (3c) is seriously flawed as a
> general approach, in terms of scope, suitability (i.e. "does it solve
> the underlying problem"), and amenability to the majority of
> implementers.  Obviously, I think my proposal has the most potential.
>

Doug, we have:

- Caret and selection tracking support
- Keyboard navigation support that is consistent with HTML
- user blink rate setting detection
- The ability to make use of ARIA and all the semantic components provided
for in HTML in the subtree this includes directives on how to map to the
accessibility API
- All major browsers have ARIA mapping support
- focus ring support and we will have and a non-standard system focus ring
support piece coming

The only thing missing is the bounds of objects

SVG does not have:

- A clear defined accessibility mapping of ARIA or SVG for that matter
- Browser manufacturers have no consistent (if any) ARIA support.
- Browsers don't have consistent accessibility mappings (if any) of the
existing SVG accessibility features. IE 9 did not support the svg
description going into the accDescription.
- A consistentent keyboard navigation model with HTML
- Caret selection and tracking
- Focus Ring support

Honestly Doug, I know you are trying to help and that you want to have SVG
succeed but we need some realism here. SVG has a very long way to go and
all we need in canvas, really is the bounds of an object. Other than the
limited work IBM funded to put ARIA into Firefox a few years ago not a lot
has happened in this space.

>
> [1]
>
http://lists.w3.org/Archives/Public/public-canvas-api/2011JulSep/0093.html
>
> Regards-
> -Doug Schepers
> W3C Staff Contact, SVG, WebApps, Web Events, and Audio WGs