Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010 (resending)

Richard

I think you may be misunderstanding the position.  I agree, today, the fallback content is discarded by browsers that understand canvas.

We discussed the flag to indicate whether the fallback content should be used as the (initial) accessibility content, and we also discussed what the default for the flag should be.  Someone suggested perhaps it should be 'true' by default (unlike today, where it is effectively false).

Now one asks:  is it ever worth setting it to 'false'?  In some cases, it can save some work on the part of a script;  consider, for example, the case where the fallback content merely says "get a better browser", but the accessibility content is a more complex structure that gives (for example) alternative input method support.  In this case, building the accessibility DOM tree means you have to tear down that "get a better browser" sub-tree, but that is easy.

So, if we make the flag true by default, is it needed at all?  Can it be always true?

On Feb 21, 2010, at 11:14 , Richard Schwerdtfeger wrote:

> HTML <canvas> content should be accessible too. However, I can think of none on the web that are today. Your statement of "partially inaccessible" makes no sense either technically or logically based on what has been implemented for <canvas> to date.
> 
> The purpose of the adom attribute is not an accessibility compliance statement "flag." It is an indication to the browser to map what is in the subtree to the accessibility infrastructure and to include it in the keyboard navigation tree. The subtree, today, is not designed to do that. It is basically ignored a browser unless it does not support canvas. Setting the flag is not a guarantee that the author has done a good job any more than anything else that is out there today. That is what accessibility test tools are for.
> 
> The reality is that you should not map the subtree DOM to the accessibility API and include it in the navigation order, by default, because neither the AT, an accessibility test tool, nor the user have any way of knowing the purpose of that content. As for Ian's content about the content being non-conforming there is no restrictions on what the fallback content is today. It can be anything. Cynthia made a very important point, at one of the previous meetings, in that an accessibility test tool need to know the content in the sub-tree is directly related to the visual rendering to test it. That cannot be known unless the author indicates it is. 
> 
> There are authors that do not care about meeting accessibility criteria and our making a blind assumption that the author should care to do so would be irresponsible on our part. Without the attribute you would have to REQUIRE that the author make the structure and accessibility properties exactly match what you are rendering on the canvas in all instances. That is an unrealistic expectation of authors and creates an unmanageable situation for accessibility test tools. We would also create a situation where two people sitting down with a web page application (one sighted and one not) will try to operate a web page application and the solution the blind user has access to will have absolutely no correlation to the one being rendered on canvas keyboard-wise, semantically, etc. It may be an entirely different collection of components, which the neither user cansee and behaves nothing like the visual rendering.
> 
> I am sorry James, but the argument you present holds no water to me and I see no way of us ever reaching consensus on it.
> 
> Rich
> 
> 
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist
> 
> <27158101.gif>James Craig ---02/19/2010 08:17:59 PM---I discussed agenda item #2 (@adom) today with Maciej and David, and I've come to agree with Ian's original argument that canvas
> James Craig <jcraig@apple.com> 
> Sent by: public-canvas-api-request@w3.org
> 02/19/2010 08:17 PM
> 
> <27027431.gif>
> To
> <27027431.gif>
> Richard Schwerdtfeger/Austin/IBM@IBMUS
> <27027431.gif>
> cc
> <27027431.gif>
> David Bolter <david.bolter@gmail.com>, cooper@w3.org, janina@rednote.net, Charles McCathieNevile <chaals@opera.com>, cyns@exchange.microsoft.com, Steven Faulkner <faulkner.steve@gmail.com>, Frank Olivier <franko@microsoft.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>, surkov.alexander@gmail.com
> <27027431.gif>
> Subject
> <27027431.gif>
> Re: Agenda: HTML 5 Canvas Accessibility Meeting February 22, 2010
> <27027431.gif>	<27027431.gif>
> 
> I discussed agenda item #2 (@adom) today with Maciej and David, and I've come to agree with Ian's original argument that canvas contents should just be accessible by default. Though the idea of using an attribute was slightly more palatable than an extra element, adding a flag of any kind doesn't provide much benefit in the best case scenario. In the worst case scenario, it would render partially accessible content completely inaccessible.
> 
> James
> 
> 
> On Feb 19, 2010, at 5:23 PM, Richard Schwerdtfeger wrote:
> 
> Monday, 2010-2-15
> Time: 3:00pm-4:00pm Boston local
> Name: WAI_PFWG(CANVAS)
> Code: 92473 ("WAIPF")
> One time
> 
> irc channel= #html-a11y
> 
> Agenda:
> 
> 1. Identify Scribe
> 2. Final Review for spec. ready adom text for Issue 74
> http://lists.w3.org/Archives/Public/public-canvas-api/2010JanMar/0178.html
> 3. Progress on caret tracking: http://www.w3.org/WAI/PF/HTML/track/actions/19 - Steve Faukner
> 
> 
> Rich Schwerdtfeger
> Distinguished Engineer, SWG Accessibility Architect/Strategist

David Singer
Multimedia and Software Standards, Apple Inc.