W3C home > Mailing lists > Public > public-html@w3.org > January 2010

Re: Proposal: Canvas accessibility and a media querries approach for alternative content (Action Item 6 in the HTML Accessibility Task Force)

From: Joe D Williams <joedwil@earthlink.net>
Date: Sat, 23 Jan 2010 09:04:57 -0800
Message-ID: <B511A04B3278496B96A1192158074ADA@joe1446a4150a8>
To: "Ian Hickson" <ian@hixie.ch>, "Maciej Stachowiak" <mjs@apple.com>
Cc: "Richard Schwerdtfeger" <schwer@us.ibm.com>, "James Craig" <jcraig@apple.com>, <public-canvas-api@w3.org>, "HTML WG" <public-html@w3.org>, "David Singer" <singer@apple.com>
> I entirely agree. This is exactly the problem I have with Richard's 
> proposed fallback markup.

I agree with some of the problems but the main thing is, I just think 
the plan is not a fallback.
It seems to me to look like this is fundamental stuff to get the 
canvas2d in a window to be interactive with a sighted viewer using a 
mouse and that user expects the author has provided the same 
functionality from 2d <canvas> as from an ordinary scripted and styled 
html/svg/x3d select interaction, The user might expect many features 
to work just like in a "live" media.
This is not "free" in <canvas>. You, the author, has to build it from 
scratch or else leverage some screen and pointer mapping or whatever. 
It is wide open. As a system like that evolves it may be possible to 
somehow model it in a way to be marked up using aria so its 
interactive features are recognizable to AT.

but the common problem to all embedded elements is that navigation 
details may be in a different context. For example in html, svg, and 
x3d even though they may be embedded content, their interactive 
elements can use aria notation, and state information can be 
transferred back and forth between the parent and nested contexts 
programatically. The idea of abstracting some interface information 
into a non-rendered container that is optionally included in embedded 
content elements could work in canvas, object, image/map, iframe, 
embed, etc.as a way to model the authors plan for interactions. Maybe 
without the need to look at the embedded content user code in detail 
for hints.

So now it begins to look more like actual fallback to me because maybe 
the most natural way to produce  a model of a canvas interactivity, or 
of any other interactive embedded content, is a set of ordinary html 
controls marked up with aria. If content doesn't play or needs help 
and user interaction is important, then what better alternative than 
nice clean aria annotated html controls as a replacement/augmentation? 
Also, just thinking that a more accessible pattern and surely less 
authoring work esp for canvas2d is have most or all controls outside 
the embedded content in the parent html. In that case, maybe problem 
is mostly solved. .

Thanks and Best Regards,
Received on Saturday, 23 January 2010 17:05:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:57 UTC