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

Re: HTML 5 Canvas Accessibility Call on January 10

From: Charles Pritchard <chuck@jumis.com>
Date: Fri, 14 Jan 2011 13:53:20 -0800
Message-ID: <4D30C5D0.7030503@jumis.com>
To: Richard Schwerdtfeger <schwer@us.ibm.com>
CC: Frank Olivier <Frank.Olivier@microsoft.com>, Cynthia Shelly <cyns@microsoft.com>, "david.bolter@gmail.com" <david.bolter@gmail.com>, "janina@rednote.net" <janina@rednote.net>, "oedipus@hicom.net" <oedipus@hicom.net>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, public-canvas-api-request@w3.org, "public-html-a11y@w3.org" <public-html-a11y@w3.org>, Shawn Warren <swarren@aisquared.com>, Tim Lalor <tlalor@aisquared.com>

I took the <canvas><iframe></iframe></canvas> issue over to the WHATWG.
No movement there.

I don't see any security issue in its current form. I'm not sure what 
the concern is at MS.

In my now-usual style, I approached it in an indirect manner:
<canvas><img src="fallback.jpg" /></canvas>

All browsers currently send out a network request for fallback.jpg, 
regardless as to
whether or not canvas is supported. It's a waste of bandwidth, but 
that's how it goes.

Mozilla has recently enabled fallback content for iframe as well:
<iframe><script src="...."></script></iframe>

Under that philosophy, fallback content is always loaded. So, the same 
would apply to IFRAME in canvas.

I don't see a security concern. It just seems inefficient. I don't think 
we'll see a change anywhere.

We'd need to expose  img.abort() and iframe.abort(). Currently, that's 
handled by execCommand('stop'), document-wide.


As for the Canvas Rendering Context 2D proposal:
I'd like to see it sent over to WHATWG for feedback from Ian and 
Mozilla. They're the most difficult bunch.

Blink rate is a requirement of WCAG. selection and focus ring seem 
pretty solid, though I know Ian really
wants them in one function, we all know they're better as two separate 

If we push those through, we'll be able to wrap up this particular issue 
of Canvas A11Y, and refocus into HTML A11Y.

As I've noted, I'm dispirited by the misguided attitude of Mozilla's 
Robert and Boris, as well as Ian.

Most of the issues I'm facing in Canvas can be re-framed as usability 
issues with HTML forms and <img> tags.
With MS and Mozilla publicly against supporting Canvas-based IME use 
cases, it's a lost cause for this generation of browsers.

I don't think there's going to be public push-back against making 
<input> tags work better for A11Y.
I've been using the "Google Books" use case for <img> tags, as it 
requires selection and resolution adjustment,
in the exact same manner as a Canvas-based text viewer would.


On 1/14/2011 9:37 AM, Richard Schwerdtfeger wrote:
> Frank,
> I think the IE team needs to look at the following:
> I can't make the browser vendors address accessibility for canvas but 
> we have an AT vendor here willing to work with us on this problem. I 
> would ask that we get our first proposals through and move forward on 
> RTE and these other use cases.
Received on Friday, 14 January 2011 21:52:45 UTC

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