Re: Review of Ian's changes for path

Ian Hickson <ian@hixie.ch> wrote on 03/21/2012 06:21:28 PM:

> From: Ian Hickson <ian@hixie.ch>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
> Cc: public-html-a11y@w3.org
> Date: 03/21/2012 06:22 PM
> Subject: Re: Review of Ian's changes for path
>
> On Tue, 20 Mar 2012, Richard Schwerdtfeger wrote:
> >
> > 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.
>
> There seems to be some implication here that the addHitRegion() feature
> has something to do with work that the Chrome team is doing. This is not
> the case. For the record, the Web Components model being developed in the

> public-webapps working group (which I assume is what you are referring
to)
> is in fact DOM-based, and is not "a new MVC model". It is not separate
> from the DOM any more than XBL is. It has no bearing on the addHitRegion
()
> work.
>
If that were true then there would be no reason to add accessibility
properties to the method that are already provided in the DOM for when an
element is not provided. I am referring to the discussion we had on the
WIKI.

> The model that addHitRegion() is based on is in fact the same model that
> ATs use for applications outside of HTML, but it defers to HTML for
> anything beyond the simplest of cases (namely labeled non-interactive
> content and containers). It's intentionally not DOM based for the simple
> case, for the same reason that canvas as a whole is not a retained mode
> API -- for that use case we already have SVG -- but it is straightforward

> to map it to accessibility APIs (much more so than the DOM, in fact). It
> is misleading to characterise it as "DOM circumvention", unless one would

> also describe, say, Microsoft Word or Lotus Notes as "circumventing the
> DOM"; nor do I see any reason to believe that it would require a
> "comprehensive effort" to introduce.
>
While it is straight forward to map SVG elements to the accessibility API
SVG's model does not adequately convey semantic structure. Essentially for
SVG you have a blob of drawing calls that you may or may not group into
something but unlike HTML the XML model is not a semantic structural model
that is comprehensible to a user. I assure you that producing a semantic
structural model for SVG is much more complicated than you have simplified
it to be. If you don't believe me I suggest you speak with your
accessibility team at Google.  I meet with them one of them regularly.

Accessibility infrastructure requires semantics to be attached to something
- if not an element then what?

Both Microsoft Word and Notes have a DOM. They simply are not a W3C DOM.
Specific Notes DOM elements are bound to accessibility API. In fact, most
assistive technologies on Windows access the Microsoft Word DOM today. The
point being that they support accessibility.

The real issue to point out here is that if an alternative DOM is used,
that is not the HTML browser DOM, then the targeted DOM needs to support
accessibility semantics and API mapping. Perhaps that was  not clear in my
response. Today, assistive technologies access the W3C DOM either directly
or through an accessibility API. If an alternative DOM is used we don't
know that it supports accessibility.

> It addresses the use cases that were provided, does so simply and
> straightforwardly, and with minimum impact, while fitting in with the
> canvas API design aesthetic.
>
> I hope to have a more formal proposal to present in the near future.
>
That is great. We look forward to a change proposal that highlighted what
changed and why. Many people, including the chairs were upset that the Path
proposal went in without a formal change proposal to see what changed and
why.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>