Re: Integration of HTM

The biggest challenge with the <accessibility> element as
proposed is how one is going to ensure that it's true to and
synchronized with what is actually drawn by the canvas element.
The only way to ensure that the  alternative content is in sync
is if that content were generated by *the same code* that did the
drawing on the canvas -- think documentation generated from
source code as an analogy.

Maciej Stachowiak writes:
 > On Feb 4, 2010, at 8:40 AM, Richard Schwerdtfeger wrote:
 > 
 > > Maciej, 
 > > 
 > > This is in contradiction with your earlier statements. 
 > > 
 > My previous statements were that I agree an accessible DOM as immediate children of the <canvas> is practical to implement and a good solution. I have been consistent in opposing a special <accessible> element and having multiple accessible alternatives declared through markup.
 > 
 > Regards,
 > Maciej
 > 
 > > 
 > > Rich
 > > 
 > > 
 > > Rich Schwerdtfeger
 > > Distinguished Engineer, SWG Accessibility Architect/Strategist
 > > 
 > > <graycol.gif>Maciej Stachowiak ---02/04/2010 10:16:39 AM---On Feb 3, 2010, at 5:49 PM, Ian Hickson wrote:
 > > 
 > > Maciej Stachowiak <mjs@apple.com>  
 > > 02/04/2010 10:16 AM
 > > 
 > > <ecblank.gif>
 > > To
 > > <ecblank.gif>
 > > Ian Hickson <ian@hixie.ch>
 > > <ecblank.gif>
 > > cc
 > > <ecblank.gif>
 > > Richard Schwerdtfeger/Austin/IBM@IBMUS, Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>
 > > <ecblank.gif>
 > > Subject
 > > <ecblank.gif>
 > > Re: Integration of HTM
 > > <ecblank.gif>	<ecblank.gif>
 > > 
 > > 
 > > On Feb 3, 2010, at 5:49 PM, Ian Hickson wrote:
 > > 
 > > > On Wed, 3 Feb 2010, Richard Schwerdtfeger wrote:
 > > >> 
 > > >> We are calling it the accessible DOM for canvas. It starts and ends with 
 > > >> the <accessible></accessible> tags and it is not visually rendered.
 > > > 
 > > > I really don't think this is a good idea, as explained in the following 
 > > > e-mails:
 > > > 
 > > >   http://lists.w3.org/Archives/Public/public-html/2010Jan/0488.html
 > > >   http://lists.w3.org/Archives/Public/public-html/2010Jan/1151.html
 > > >   http://lists.w3.org/Archives/Public/public-html/2010Jan/0931.html
 > > > 
 > > > I do not think it is necessary to have multiple inline alternatives for 
 > > > <canvas>, nor do I think it is necessary for widgets that represent the 
 > > > graphically-rendered widgets on a <canvas> to be marked up separately from 
 > > > an inline alternative representation. The existing features of HTML 
 > > > already allow us to have multiple alternatives. Adding more features for 
 > > > this is IMHO a mistake.
 > > 
 > > I agree. I don't think the <accessible> tag is an improvement. In the common case, the same content can work as an accessible DOM and as fallback content. And that's also the model for other elements that use fallback content partly for accessibility purposes (e.g. <object>). I don't see the case for making canvas accessibility intrinsically more complicated.
 > > 
 > > Regards,
 > > Maciej
 > > 
 > > 
 >

Received on Thursday, 4 February 2010 18:31:20 UTC