10964 2010-10-02 00:16:35 +0000 Canvas needs to support a backing store in the DOM subtree capable of supporting screen reading 2012-01-24 17:24:26 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All VERIFIED FIXED a11y, a11ytf, a11y_canvas P2 normal --- 11239 11240 11241 11242 1 schwer schwer cooper ian jackalmage laura.lee.carlson mike public-html-a11y public-html-admin public-html-wg-issue-tracking shelleyp public-html-bugzilla oldest_to_newest 40470 0 schwer 2010-10-02 00:16:35 +0000 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 - 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 Given the deadline tonight and the early stages of our addressing building a backing store for <canvas> I was asked to put what may be needed in the backing store. 40471 1 schwer 2010-10-02 00:17:31 +0000 I should clarify that this is for rich text editing. 40472 2 jackalmage 2010-10-02 00:53:34 +0000 (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. 40813 3 ian 2010-10-07 21:35:47 +0000 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 40843 4 schwer 2010-10-08 12:47:38 +0000 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. 40847 5 jackalmage 2010-10-08 15:54:22 +0000 (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? 41760 6 cooper 2010-10-26 15:30:02 +0000 Bug triage sub-team says this is A11Y TF priority, assigning to Rich to continue in the canvas group. 42991 7 schwer 2010-12-02 14:41:37 +0000 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. 63060 8 cooper 2012-01-24 16:43:34 +0000 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. 63062 9 schwer 2012-01-24 17:24:26 +0000 +1