W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > June 2009

[Bug 7011] canvas accessible fallback provision is under specified

From: <bugzilla@wiggum.w3.org>
Date: Fri, 26 Jun 2009 21:35:31 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1MKJ51-0005L3-Ks@wiggum.w3.org>

--- Comment #15 from steve faulkner <faulkner.steve@gmail.com>  2009-06-26 21:35:31 ---
 what you are putting forward as 'a pretty good solution' is the antithesis of
'built in' accessibility. it asks the developer to duplicate the effort in
creating content, it will also be 'hidden content' likely to become out of sync
with the canvas based functionality.

if canvas is to be used , as it is already, to create UI elements, then it
requires some 'built in' not 'bolt on' methods to ensure that name,role and
state information of the interactive elements is available to assistive

(In reply to comment #14)
> > by giving it some thought and proposing some way to add the info required for
> > accessibility, to content in canvas. 
> As far as I can tell, what the spec currently suggests is a pretty good
> solution to this. Basically it suggests generating a DOM tree (would could e.g.
> use ARIA roles if that is necessary) inside the <canvas>, exactly as Simon
> demonstrates above.
> > I suggested a crude idea of mapping area elements to focusable areas on a
> > canvas, which could have aria roles and states added to represent the many
> > interface elements that authors may develop using canvas.
> This seems equivalent to just including focusable areas as descendants of the
> <canvas> element, optionally with ARIA roles and states (or alternatively just
> using native HTML semantics like links and form controls).
> > Another issue that comes to mind in relation to the current canvas fallback is
> > that for any duplicate fallback that includes event handlers, there are going
> > to be interaction issues between those event handlers on the canvas and
> > those on the fallback. there is no mention of this currently, there needs to be
> > a robust method specified to resolve this.
> Could you elaborate on this? I don't understand. A user agent would presumably
> have the user interact with only one or the other, not both.

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 26 June 2009 21:35:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:37 UTC