- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Thu, 29 Jul 2010 09:07:02 +0100
- To: Richard Schwerdtfeger <schwer@us.ibm.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, public-canvas-api@w3.org
- Message-ID: <AANLkTinTjdccVQw4WpmuQWXA4nriGBDhDbJwhLKY+qQ8@mail.gmail.com>
This [http://lists.w3.org/Archives/Public/public-html/2010Jul/0219.html ] is a counter proposal to: Provide accessibility information for driving screen magnifier tracking of focus rectangle and caret selection and to prevent blink rate seizures http://www.w3.org/html/wg/wiki/ChangeProposals/canvasaccessibility regards Stevef ---------- Forwarded message ---------- From: Ian Hickson <ian@hixie.ch> Date: 29 July 2010 08:30 Subject: Change proposal for ISSUE-74 and ISSUE-105 To: public-html@w3.org (Chairs: It's not clear to me what problems issues 74 and 105 have been raised to deal with; I hope this is an appropriate change proposal for them. If it is not, please let me know what the actual topic of those issues is so that I can reconsider them.) SUMMARY Explain how to avoid the performance problem of redrawing the focus ring with each movement of the text entry caret. RATIONALE The spec, as written, does not explain how to use the drawFocusRing() API to provide accessible tools with information regarding the current caret position without causing the whole focus ring to be repainted with each movement of the caret. A naive use of this API would therefore result in the entire control being repainted for every edit or caret movement. This is a performance nightmare -- you might end up having to repaint everything behind the control as well as the control itself. To avoid this problem, the specification should recommend the use of a clip region and an opaque text field background. By clipping out everything but the inside of the text field, the focus ring will not need to actually be painted. This allows browsers to optimise away the graphics calls to render the focus ring, while still allowing authors to use a simple API to make their tools accessible, even if they do not realise that that is what they are doing. The specification should probably also discourage the use of <canvas> for text editing. DETAILS Add a note such as the following after the domintro box for drawFocusRing: Note: It is generally ill-advised to use canvas to implement text fields -- authors are encouraged to use input elements or, in highly graphical situations, interactive SVG. However, if canvas is indeed used to render a text field, then authors are encouraged to make use of the clip() method to create a clipping region representing the inside of the text field while updating the text field's text and the caret position. This allows user agents to optimise the rendering of these updates to only include the actual text field, rather than having to repaint the entire focus ring with each move of the caret. IMPACT POSITIVE EFFECTS Improves performance of authors using drawFocusRing() for text fields, which in turn increases the likelihood that authors will use it rather than avoid it for performance reasons, which in turn improves real-world accessibility of the Web. NEGATIVE EFFECTS Might encourage the use of <canvas> for text fields, which would be a step backwards for the Web as a whole, in terms of usability and accessibility. CONFORMANCE CLASS CHANGES None. RISKS See Negative Effects. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Thursday, 29 July 2010 08:07:57 UTC