If you could file separate bugs for each specific issue or proposal that would be very helpful in helping me track the issues. (You can mark them as blocking this bug using the Bugzilla "blocks"/"depends on" feature if you want to track them as one unit.)

(If you don't have the time to do this that's fine too; I can create separate bugs myself when I get to it.)

(from the cited blog post:)

* Text in canvas

There is a native method to display text in canvas (example of its use: Cufón), but no native method to output text as fallback. So the developer using canvas to replace text either needs to implement a method using scripting or manually add the fallback text.

It is suggested that to make it practical for developers to provide fallback for disabled users who cannot access the text content directly, a native method that outputs the text as fallback is added to the canvas API.


* Images in canvas

There is a native method for inserting images into canvas (Example of its use: Canvas Slideshow (with HTML5 canvas), but no methods to add a text alternative to the images or method to output such images as fallback. So the developer using images in canvas either needs to implement a method using scripting or manually add the fallback images and text alternatives.

It is suggested that to make it practical for developers to provide fallback for disabled users who cannot access the image content directly a native method that allows the addition of text alternatives and an output method that inserts img elements as fallback content, is added to the canvas API.


* User interface elements in canvas

canvas can be used to create interactive interfaces (example of its use: bespin), but there are no methods to assign roles, states and properties to areas of a canvas that represent widgets, controls or links. So the developer who wants to create an accessible interface has to duplicate the content of the canvas interface using HTML elements that provide native roles, states and properties.

It is suggested that to make it practical for developers to provide information about UI elements to disabled users who cannot access information visually, native methods be provided that allow for the identification of the roles, states and properties of user interface elements displayed on a canvas, futhermore a method to define discrete focusable areas of the canvas be provided.

A crude example of some of the features required in canvas can be illustrated using a HTML image map. The example uses a canvas pie menu demonstration by Ben Galbraith to which a transparent image map has been added. The image map provides  keyboard access to segments of the pie menu, it also provides information about their role and state of each and name (text alternative) for each segment. Note: Use of this image map technique, while useful for illustrative purposes is not proposed as a practical solution.

> It is suggested that to make it practical for developers to provide fallback
> for disabled users who cannot access the text content directly, a native method
> that outputs the text as fallback is added to the canvas API.

Isn't canvas.appendChild(document.createTextNode(s)) already such a method?

> It is suggested that to make it practical for developers to provide fallback
> for disabled users who cannot access the image content directly a native method
> that allows the addition of text alternatives and an output method that inserts
> img elements as fallback content, is added to the canvas API.

It seems that a native method to add text alternative is equivalent to a method to add text, which already exists:

    canvas.appendChild(document.createTextNode(alt));

I don't think that there would be any benefit to appending images per se; the <img> elements would never be seen and the text alternative would be no better than an actual text node.

> It is suggested that to make it practical for developers to provide information
> about UI elements to disabled users who cannot access information visually,
> native methods be provided that allow for the identification of the roles,
> states and properties of user interface elements displayed on a canvas,
> futhermore a method to define discrete focusable areas of the canvas be
> provided.

I have no idea how to do this; if anyone has any concrete proposals for such an API, I would be grateful for any suggestions.

>I have no idea how to do this; if anyone has any concrete proposals for such an
>API, I would be grateful for any suggestions.

I have reopned the bug, as you not having any idea does not make the problem go away.

please refer to:

http://lists.w3.org/Archives/Public/www-archive/2009Jun/0119.html

> hi Sam,
> 
> "if it is the case that canvas is not accessible, and that there is
> strong agreement on "We will design all features so as to ensure that
> they are accessible to users with disabilities", then I would simply
> suggest we delay Last Call until this is addressed."
> 
> There is nothing hypothetical about the inaccessibility of canvas
> content and accessible design is a cornertsone of W3C philosophy, so I
> would suggest that unless it is resolved before October, it would
> contribute to a delay.

That's why I chose it as a concrete example. :-)


and

SF: the other question is that with <canvas>.. what do you think is the best way to get this resolved? If more accessibility stuff doesn't get added to it could it be removed?

SR: Its possible, but unlikely
... Ian has said that he is committed to accessibility in canvas so he is motivated also by the upcoming deadline for CR
... People want <canvas> in and accessibility is a hard problem.

http://www.w3.org/2009/06/25-html-wg-minutes.html

How would you like me to proceed in resolving this issue?

>Isn't canvas.appendChild(document.createTextNode(s)) already such a method?
 
One of the issues I found when looking into canvas is that when canvas is added using document.createElement("canvas"), which appears to be quite a common method, there is not actually a container canvas <canvas></canvas> element created, just <canvas />, so there is not fallback container.
I have talked about it here:
http://www.paciellogroup.com/blog/?p=299
perhaps this issue is not an issue, just a misunderstanding due to my lack of expertise.

(In reply to comment #7)
> How would you like me to proceed in resolving this issue?

by giving it some thought and proposing some way to add the info required for accessibility, to content in canvas. 

I suggested a crude idea of mapping area elements to focusable areas on a canvas, which could have aria roles and states added to represent the many interface elements that authors may develop using canvas.

may be totally unworkable, but it is a start of an idea.

Another issue that comes to mind in relation to the current canvas fallback is that for any duplicate fallback that includes event handlers, there are going to be interaction issues between those event handlers on the canvas and those on the fallback. there is no mention of this currently, there needs to be a robust method specified to resolve this.

(In reply to comment #8)
> >Isn't canvas.appendChild(document.createTextNode(s)) already such a method?
> 
> One of the issues I found when looking into canvas is that when canvas is added
> using document.createElement("canvas"), which appears to be quite a common
> method, there is not actually a container canvas <canvas></canvas> element
> created, just <canvas />, so there is not fallback container.
> I have talked about it here:
> http://www.paciellogroup.com/blog/?p=299
> perhaps this issue is not an issue, just a misunderstanding due to my lack of
> expertise.
> 

I think it is not an issue: you can append a text node to a canvas element whether it was created with createElement() or appeared as <canvas></canvas> in the markup; there's no difference between the two.

Cufón could add the text to the canvas instead of as a sibling span, but it appears they don't do it because of a bug in Opera.
http://groups.google.com/group/cufon/browse_thread/thread/a938785c3c58addb?pli=1

So can you append an element?

I tried this
newp = document.createElement("p"); 
document.getElementById('myCanvas').appendChild(newp);

but didn't work.

(In reply to comment #10)
> (In reply to comment #8)
> > >Isn't canvas.appendChild(document.createTextNode(s)) already such a method?
> > 
> > One of the issues I found when looking into canvas is that when canvas is added
> > using document.createElement("canvas"), which appears to be quite a common
> > method, there is not actually a container canvas <canvas></canvas> element
> > created, just <canvas />, so there is not fallback container.
> > I have talked about it here:
> > http://www.paciellogroup.com/blog/?p=299
> > perhaps this issue is not an issue, just a misunderstanding due to my lack of
> > expertise.
> > 
> I think it is not an issue: you can append a text node to a canvas element
> whether it was created with createElement() or appeared as <canvas></canvas> in
> the markup; there's no difference between the two.
> Cufón could add the text to the canvas instead of as a sibling span, but it
> appears they don't do it because of a bug in Opera.
> http://groups.google.com/group/cufon/browse_thread/thread/a938785c3c58addb?pli=1

(In reply to comment #11)
> So can you append an element?

Sure.

> I tried this
> newp = document.createElement("p"); 
> document.getElementById('myCanvas').appendChild(newp);
> 
> but didn't work.

Works for me.
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/155

thanks

(In reply to comment #12)
> (In reply to comment #11)
> > So can you append an element?
> Sure.
> > I tried this
> > newp = document.createElement("p"); 
> > document.getElementById('myCanvas').appendChild(newp);
> > 
> > but didn't work.
> Works for me.
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/155

> by giving it some thought and proposing some way to add the info required for
> accessibility, to content in canvas. 

As far as I can tell, what the spec currently suggests is a pretty good solution to this. Basically it suggests generating a DOM tree (would could e.g. use ARIA roles if that is necessary) inside the <canvas>, exactly as Simon demonstrates above.


> I suggested a crude idea of mapping area elements to focusable areas on a
> canvas, which could have aria roles and states added to represent the many
> interface elements that authors may develop using canvas.

This seems equivalent to just including focusable areas as descendants of the <canvas> element, optionally with ARIA roles and states (or alternatively just using native HTML semantics like links and form controls).


> Another issue that comes to mind in relation to the current canvas fallback is
> that for any duplicate fallback that includes event handlers, there are going
> to be interaction issues between those event handlers on the canvas and
> those on the fallback. there is no mention of this currently, there needs to be
> a robust method specified to resolve this.

Could you elaborate on this? I don't understand. A user agent would presumably have the user interact with only one or the other, not both.

 what you are putting forward as 'a pretty good solution' is the antithesis of 'built in' accessibility. it asks the developer to duplicate the effort in creating content, it will also be 'hidden content' likely to become out of sync with the canvas based functionality.

if canvas is to be used , as it is already, to create UI elements, then it requires some 'built in' not 'bolt on' methods to ensure that name,role and state information of the interactive elements is available to assistive technology.

(In reply to comment #14)
> > by giving it some thought and proposing some way to add the info required for
> > accessibility, to content in canvas. 
> As far as I can tell, what the spec currently suggests is a pretty good
> solution to this. Basically it suggests generating a DOM tree (would could e.g.
> use ARIA roles if that is necessary) inside the <canvas>, exactly as Simon
> demonstrates above.
> > I suggested a crude idea of mapping area elements to focusable areas on a
> > canvas, which could have aria roles and states added to represent the many
> > interface elements that authors may develop using canvas.
> This seems equivalent to just including focusable areas as descendants of the
> <canvas> element, optionally with ARIA roles and states (or alternatively just
> using native HTML semantics like links and form controls).
> > Another issue that comes to mind in relation to the current canvas fallback is
> > that for any duplicate fallback that includes event handlers, there are going
> > to be interaction issues between those event handlers on the canvas and
> > those on the fallback. there is no mention of this currently, there needs to be
> > a robust method specified to resolve this.
> Could you elaborate on this? I don't understand. A user agent would presumably
> have the user interact with only one or the other, not both.

(In reply to comment #15)
>  what you are putting forward as 'a pretty good solution' is the antithesis of
> 'built in' accessibility. it asks the developer to duplicate the effort in
> creating content, it will also be 'hidden content' likely to become out of sync
> with the canvas based functionality.

Agreed.


> if canvas is to be used , as it is already, to create UI elements, then it
> requires some 'built in' not 'bolt on' methods to ensure that name,role and
> state information of the interactive elements is available to assistive
> technology.

I don't know how to do that. I'll contact the PFWG and see if they have any advice.

http://lists.w3.org/Archives/Public/wai-xtech/2009Jun/0093.html

in reply to 
http://lists.w3.org/Archives/Public/wai-xtech/2009Jun/0093.html


I would suggest 3 things:

1. For a problem that has stumped you we need as much technical
expertise as is possible, so have included the HTML WG in this email.
2. we use an example that embodies the problem:
http://people.mozilla.com/~jdicarlo/piemenus.html
contains 2 examples of UI controls rendered using canvas.

3. rephrase the question:  what  would need to be added to the canvas
API so that the UI controls in the example could have
programmtic focus (like an area on an image map) and
name, role and state information exposed to accessibility APIs,
without expecting the author to completely recreate the UI controls in
HTML.


http://lists.w3.org/Archives/Public/public-html/2009Jun/0761.html
http://lists.w3.org/Archives/Public/public-html/2009Jun/0762.html






(In reply to comment #16)
> (In reply to comment #15)
> >  what you are putting forward as 'a pretty good solution' is the antithesis of
> > 'built in' accessibility. it asks the developer to duplicate the effort in
> > creating content, it will also be 'hidden content' likely to become out of sync
> > with the canvas based functionality.
> 
> Agreed.
> 
> 
> > if canvas is to be used , as it is already, to create UI elements, then it
> > requires some 'built in' not 'bolt on' methods to ensure that name,role and
> > state information of the interactive elements is available to assistive
> > technology.
> 
> I don't know how to do that. I'll contact the PFWG and see if they have any
> advice.
> 

(In reply to comment #3)
> > It is suggested that to make it practical for developers to provide fallback
> > for disabled users who cannot access the text content directly, a native method
> > that outputs the text as fallback is added to the canvas API.
> 
> Isn't canvas.appendChild(document.createTextNode(s)) already such a method?
> 

what i meant was a method included as part of the canvas API, a way of inputting text is provided, why not a way of outputting it for fallback purposes? I am attempting to suggest ways to make it as easy as possible for authors to provide the content required for accessibility. we all know unless its easy it won't be done.

(In reply to comment #4)
> > It is suggested that to make it practical for developers to provide fallback
> > for disabled users who cannot access the image content directly a native method
> > that allows the addition of text alternatives and an output method that inserts
> > img elements as fallback content, is added to the canvas API.
> 
> It seems that a native method to add text alternative is equivalent to a method
> to add text, which already exists:
> 
>     canvas.appendChild(document.createTextNode(alt));
> 
> I don't think that there would be any benefit to appending images per se; the
> <img> elements would never be seen and the text alternative would be no better
> than an actual text node.
> 

again, what i meant was a method as part of the canvas api, to add text alternatives that could be outputted as fallback. If a method is provided, it is more likely it will be used to help make the content accessible, which is the result we all want.

Do you mean a single method that outputs text both to the canvas and the fallback content simultaneously?

(In reply to comment #21)
> Do you mean a single method that outputs text both to the canvas and the
> fallback content simultaneously?

one that provides the possibility of doing this , yes

comments by Richard Schwerdtfeger on what is considered to be required to for canvas accessibility:

In order to make canvas accessible we will need:

   An object model to which authors can apply an accessibility API.
   A collection of callback interfaces that can be applied to objects to
   support an accessibility API mapping on each browser and platform and
   potentially a vehicle to fire events to ATs.
   A provision for equivalent alternative references that allow a canvas
   author to specify an alternative resource for drawing that cannot be
   made accessible through traditional API.

full text:
http://lists.w3.org/Archives/Public/public-html/2009Jul/0867.html

Moving to REMIND to make sure I don't lose this.

This was escalated to ISSUE-74 and is blocked on getting input from the Canvas Accessibility Task Force (whose name I may just have mangled, in which case my apologies).

*** Bug 7740 has been marked as a duplicate of this bug. ***

This issue is important to PFWG.

It is being discussed as part of ISSUE-74. Rich Schwerdtfeger is leading a group to develop an accessibility model for canvas (ACTION-133). Discussion takes place on public-canvas-api@w3.org (http://lists.w3.org/Archives/Public/public-canvas-api/).

Removing myself from cc list, default on bug edits is to add, but I'm only acting on behalf of HTML A11Y TF which is already cc'd.

The HTML Accessibility Task Force intends to track these issues, per the proposal at http://lists.w3.org/Archives/Public/public-html-a11y/2010Jan/0245.html.

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.

Reopened per discussion on a11y TF telcon 2010-03-18

It's improper to reopen this bug, since it is already escalated to the tracker and tagged TrackerIssue. Putting back in VERIFIED.

(In reply to comment #17)
> Shouldn't be reopened since it's already escalated.

Maciej set the status of this bug to VERIFIED FIXED after it was reopened through a misunderstanding of the decision process at the a11y teleconference.

Maciej's rationale is that this bug is already escalated to a tracker issue. VERIFIED with a TrackerIssue keyword is indeed the correct state for a bug that has been "resolved" by the editor but has not yet in fact been decided by the working group via the escalation process. Maciej was correct to move the bug back to VERIFIED per HTML working group process.
http://dev.w3.org/html5/decision-policy/decision-policy.html#states-and-keywords

However, Ian did not FIX this bug. It is not FIXED so VERIFIED FIXED is not appropriate. 

It was last labeled NEEDSINFO.
http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0396.html

The accessibility task force is actively working on this problem.

Relabeling this VERIFIED NEEDSINFO until an appropriate label can be worked out.

(In reply to comment #33)
> 
> Relabeling this VERIFIED NEEDSINFO until an appropriate label can be worked
> out.
> 

My mistake. Thanks for correcting the resolution.

The relevant tracker issue is:

http://www.w3.org/html/wg/tracker/issues/74