W3C home > Mailing lists > Public > public-canvas-api@w3.org > January to March 2010

Re: Updated proposal round two (based on feedback from Monday's meeting)

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 17 Feb 2010 15:50:21 -0600
To: Ian Hickson <ian@hixie.ch>
Cc: Steven Faulkner <faulkner.steve@gmail.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org
Message-ID: <OFA1779F59.6CEB5EC1-ON862576CD.007688D4-862576CD.0077F758@us.ibm.com>

Rich Schwerdtfeger
Distinguished Engineer, SWG Accessibility Architect/Strategist

public-canvas-api-request@w3.org wrote on 02/17/2010 03:03:01 PM:

> Ian Hickson <ian@hixie.ch>
> Sent by: public-canvas-api-request@w3.org
> 02/17/2010 03:03 PM
> To
> Steven Faulkner <faulkner.steve@gmail.com>
> cc
> Richard Schwerdtfeger/Austin/IBM@IBMUS, "public-canvas-api@w3.org"
> <public-canvas-api@w3.org>
> Subject
> Re: Updated proposal round two (based on feedback from Monday's
> On Wed, 17 Feb 2010, Steven Faulkner wrote:
> > >
> > >That makes sense, except I don't understand why we would ever want to
> > >turn that behaviour _off_.
> >
> > if there is focusable content in the canvas sub tree that is fallback,
> > why would you want it to be tabbable when the canvas is rendered?
> The same reason as when it's an "accessible DOM" -- to expose it to AT
> users.
> (If the author doesn't want this behaviour, it's trivial to empty the
> <canvas> of the fallback DOM from script after detecting canvas support.)
We don't have an issue with being able to reload the subtree. The issue is
knowing if the subtree that
is currently loaded maps to the <canvas> rendering. For example, if it is
not you definitely would not want to use the subtree in the keyboard
navigation order as you would never see visual rendering of focus. In fact
the subtree could have the following HTML content:

"canvas not supported - go get a <a ref="http://www.firefox.com">better

It is accessible content but does not make the <canvas> rendering
accessible. Consequently, if this would not be something we test for
accessibility on <canvas> supporting browsers as it would be pointless to

This is why we need the adom attribute - or if you have a better name that
is fine. Raman mentioned the name and we thought it was short enough.

We absolutely agree that the author can load content in the subtree based
on the user agent support. So, there is no need for an accessible dom
element in the subtree, just an attribute directive to tell a test tool and
user agent what to do with what is there.

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 17 February 2010 21:51:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:49 UTC