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

[Bug 7011] [in off-bug discussion] canvas accessible fallback provision is under specified

From: <bugzilla@wiggum.w3.org>
Date: Sun, 28 Jun 2009 12:02:11 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1MKt5H-0002Ly-Am@wiggum.w3.org>

--- Comment #18 from steve faulkner <faulkner.steve@gmail.com>  2009-06-28 12:02:10 ---
in reply to 

I would suggest 3 things:

1. For a problem that has stumped you we need as much technical
expertise as is possible, so have included the HTML WG in this email.
2. we use an example that embodies the problem:
contains 2 examples of UI controls rendered using canvas.

3. rephrase the question:  what  would need to be added to the canvas
API so that the UI controls in the example could have
programmtic focus (like an area on an image map) and
name, role and state information exposed to accessibility APIs,
without expecting the author to completely recreate the UI controls in


(In reply to comment #16)
> (In reply to comment #15)
> >  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.
> Agreed.
> > 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
> > technology.
> I don't know how to do that. I'll contact the PFWG and see if they have any
> advice.

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 Sunday, 28 June 2009 12:02:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:00:55 UTC