I should clarify that this is for rich text editing.

(In reply to comment #0)
> In order to support a text editing in the subtree and ensure properer
> positioning of text canvas must support:
> 
> - application of CSS to the canvas subtree even though the content is hidden to
> support proper text layout and support a screen reader

Nothing prevents applying CSS to the children of a <canvas> right now.


> - provisions for capturing events used in contenteditable areas to allow for
> backingstore synchronization with the visual canvas. Examples of these event
> capture of text events, selection, and text insertion, text deletion, and caret
> movement, within contenteditable areas in the canvas subtree also known as
> fallback content. This is to allow synchronization with visual canvas to allow
> an accessible one for one mapping. 
> 
> - Functions for retrieving selected text ranges and the caret position in
> content editable areas

I'm not sure how either of these have anything to do with <canvas>'s backing store.  The backing store is the pixel array used to hold the image data.  It has nothing to do with the children of the <canvas> element.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, 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

Status: Did Not Understand Request
Change Description: no spec change
Rationale: concurred with comment 2

The backing store is not the traditional backing store for what you would see in say the X Windows System to handle offscreen bitmaps. It is a DOM based backing store for what you see in the GUI. Every GUI RTE has one: Office, Open Office, Chrome, FF, IE, etc. 

What is needed is a 1:1 mapping of the caret and selection information stored in the DOM to the GUI rendering. To do that we need to be able to track the caret and selection in the contenteditable areas. 

We are taking time to work this out.

(In reply to comment #4)
> The backing store is not the traditional backing store for what you would see
> in say the X Windows System to handle offscreen bitmaps. It is a DOM based
> backing store for what you see in the GUI. Every GUI RTE has one: Office, Open
> Office, Chrome, FF, IE, etc. 
> 
> What is needed is a 1:1 mapping of the caret and selection information stored
> in the DOM to the GUI rendering. To do that we need to be able to track the
> caret and selection in the contenteditable areas. 
> 
> We are taking time to work this out.

Ah, I see.  The term "backing store" already has a completely different meaning in reference to <canvas>, so I was pretty confused.

The latter two bugs in your bug (please file these as separate bugs instead), then, are actually completely about @contenteditable, and not at all about <canvas>, right?

Bug triage sub-team says this is A11Y TF priority, assigning to Rich to continue in the canvas group.

We have separated out caret and selection tracking into defects:
11239 and 11240. To clarify, yes canvas subtree is a shadow DOM for what is rendered on canvas. That said, canvas API must support the ability to drive screen reader while a user moves the caret and and selection point on the physical canvas. This must be a physical screen position. So, you are correct Tab, that this really belongs to the Canvas 2D API and it will also impact contenteditable areas. So that we can bind the caret and selection information to the visible rendering on canvas. 

Currently, the <canvas> spec. now provides for this subtree which is navigeable from the keyboard and this subtree can be mapped to the accessibility API. This is now implemented in IE 9. So, I believe this bug is fully resolved.

It appears from Rich's last comment that this bug no longer needs info, is dealt with by other bugs and is implemented. Taking the liberty to call that "fixed" and marking as verified.

+1