Re: Review of Ian's changes for path

Judy,

My reluctance to be so direct is that Ian has not put a formal change
proposal forward and what he is working on may change. For example, if you
look at the page there is a clearRect function that says nothing about
clearing path element bindings for hit testing. When I raised that issue he
stated it could be made to state it could. So, I am patiently waiting. I
have done my best to put feedback to him on his WIKI and in response to his
response to my assessment.

We did discuss this some on the task force meeting today and I believe
Cynthia stated it very clearly that adding declarative accessibility API,
essentially piecemeal, is a very bad idea. Doing so correctly will take a
significant amount of time and these additional advancements are targeted
for ARIA 2.0 - as is improved SVG accessibility support. One of the reasons
that the current version of longdesc has not met the needs of the community
is that a piecemeal approach was taken at the end of HTML4. I would much
prefer that Ian simply have addHitRegion take an element and an optional
path where the current canvas path is used unless one is provided. That is
essentially what Frank had with the added new path that Ian put in. That
said Microsoft has said they would not implement path.

All this said it appears that the IE team may have implemented Frank's
proposal which means we have an implementation by a major browser provider.
This is my assumption and nothing has been told to me. If IE later wanted
to allow the method to take an optional Path and IE would support Ian's
Path proposal we could reach a consensus approach.

Rich


Rich Schwerdtfeger



From:	Judy Brewer <jbrewer@w3.org>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS,
            public-html-a11y@w3.org,
Cc:	chuck@jumis.com, "Frank Olivier" <Frank.Olivier@microsoft.com>,
            cyns@exchange.microsoft.com, janina@rednote.net,
            david.bolter@gmail.com, faulkner.steve@gmail.com
Date:	03/21/2012 06:54 PM
Subject:	Re: Review of Ian's changes for path



Rich,

Thanks for your analysis below of Ian's recent and apparent planned
upcoming canvas changes.

I note your rather neutral wording of "That would have accessibility
implications," but gather from your specific observations below,
though they are not detailed, that these would very likely be
detrimental changes for accessibility, or at best that it would
require substantial additional work to overcome new problems for
accessibility that would be introduced by these approaches.

Additional detail would be welcome if you have the time, or otherwise
perhaps you can further describe during the Accessibility Task Force
meeting tomorrow.

Thanks,

- Judy

At 04:27 PM 3/20/2012 -0500, Richard Schwerdtfeger wrote:

>I was asked to review Ian's changes to the canvas 2D Context API and
>its impact on the accessibility issue for magnifiers, hit testing,
>and Frank Olivier's proposal:
>
>1. Ian's change was only to introduce SVG's path functionality to
>Canvas.  Standing on its own it does not address Issue-201
>(<http://www.w3.org/html/wg/tracker/issues/201>
http://www.w3.org/html/wg/tracker/issues/201)
>for supporting canvas hit testing and providing location information
>to assistive technologies. I don't know if an issue was logged to
>provide SVG Path support but it was discussed on the list.
>2. His proposal is part of a collection of changes that Ian is
>working on that would impact these accessibility defects:
><http://wiki.whatwg.org/wiki/Canvas>http://wiki.whatwg.org/wiki/Canvas
>As I may have mentioned Steve Faulkner and I have been providing use
>cases to Ian and feedback on work he is doing to address Issue-201.
>You can see some of that on this page. That said, Ian has not made a
>direct change to the W3C spec. to address our defects nor has he
>submitted a change proposal to the working group for a new function
>addHitRegion().
>
>That said, the change does impact Frank's proposal
>(<http://www.w3.org/wiki/Canvas_hit_testing>
http://www.w3.org/wiki/Canvas_hit_testing)
>and the work being done on the link, if submitted, would introduce a
>new web MVC mechanism to the Web that either non-WebKit-based or
>non-Chrome browsers does not support today. That would have
>accessibility implications. I will elaborate:
>
>1. Frank's proposal assumed the using the current canvas path. Ian
>has introduced an entirely new path mechanism, that is a bit heavy
>weight, that was not there before. Frank's proposal would need to
>change to accommodate it, yet Frank stated Microsoft would not
>support it. - a conundrum.
>2. When I was at TPAC a Google developer showed me new work he was
>doing on a new MVC model for the Web, similar to XBL, with a new
>model that could be bound to different rendering engines: SVG,
>Canvas, etc. This object model is separate from the DOM and I was
>told that this recently went into a Chrome trunk. The addHitRegion()
>function would allow for access to a separate model in that the
>element parameter is not required (See Ian's comments). None of the
>ATs, including Google Chrome make use of it today so introducing
>this mechanism would require a comprehensive accessibility effort as
>it is a DOM circumvention. Please read my comments on addHitRegion.
>
>Rich
>
>Rich Schwerdtfeger