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

Re: html5 editor responds to Canvas accessibility related bugs

From: Charles Pritchard <chuck@jumis.com>
Date: Sun, 26 Sep 2010 12:09:33 -0700
Message-ID: <4C9F9A6D.3020901@jumis.com>
To: Ian Hickson <ian@hixie.ch>
CC: Richard Schwerdtfeger <schwer@us.ibm.com>, janina@rednote.net, Steven Faulkner <faulkner.steve@gmail.com>, public-canvas-api@w3.org
  On 9/26/2010 11:04 AM, Ian Hickson wrote:
> On Sun, 26 Sep 2010, Richard Schwerdtfeger wrote:
>> We can certainly suggest that authors do something the right way as Ian
>> suggests but frankly that is nothing more than a recommendation.
> Why would an author who doesn't care about accessibility enough to use the
> tools we have provided to make editors accessible, and who instead uses
> canvas, care enough about accessibility to use the canvas tools we could
> provide to make editors accessible?

I'm glad to take you up on this conversation. This is a three-part response:

Your sentiment about coders not caring is incorrect (if not insincere).
Your repulsion from canvas is a bit confusing.

Your continued attendance on Web Accessibility matters would be greatly 
and have positive consequences beyond quibbles with canvas.


I'm certain that many authors (such as myself) working with Canvas elements
application interfaces are very much interested in maintaining 
accessibility standards.

drawFocusRing was a step forward. MS has gone ahead with tab-based focus.

I'm telling you, as a web application developer, that I care very much 
about accessibility.
Richard is telling you, as a developer, that there is a deficiency with 
the current spec,
blocking all programmers from implementing current accessibility standards.

I've presented direct evidence that coders working with canvas do care 
about accessibility.

As you're well aware, many projects MUST provide accessibility routines.


I'd like to see a continued good-faith effort on supporting Web 
Accessibility throughout the HTML 5 specs:
leave no tag behind.

HTML is intended for semantic structure; you seem hung up on the fact
that coders may progressively enhance their CSS presentation with Canvas
and ECMAScript.

My range-sliders may not use the browser or OS user-interface modules,
but they certainly follow the HTML 5 standard in their implementation 
within the DOM.

I am confused. Why are you putting your foot down on HTML being
presented via Canvas or a combination of CSS and Canvas?


I'm certain that any work done on enhancing accessibility APIs for Canvas
will benefit implementations of HTML Form controls, however they're 

Many APIs are be used internally. WebCore provides so many examples of 
that practice.

You'll find items like drawFocusRing adopted within C++ code, within 
opaque implementations
of form elements, regardless of exposure to the DOM. There are difficult 
issues with accessibility
in graphical user interface elements. Whether tackled as part of canvas, 
or as part of the implementation
of HTML elements, they need to be addressed.

Received on Sunday, 26 September 2010 19:09:48 UTC

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