Fwd: Change proposal for ISSUE-74 and ISSUE-105

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