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

I can see the performance advantage but caret and focus selection need to
be separated out. Entirely different accessibility services are driven by
caret and focus rings. I sent a revision to the last proposal I put in to
James Graham for feedback before sending it to the wider group.

Focus rings: screen magnifiers will track focus rings by assessing going
directly to the object with focus, grabbing the bounding rectangle and
based on they type of object position the magnifier as appropriate for that
object. This is very important. At very large magnification levels (say
20X) the magnifier may position the magnifier at the center of the control
or to the left edge. This may change based on the magnification level. So,
passing the x, y coordinate assumes the author is making the decision as to
where the magnification point should be when that decision needs to be left
up the screen magnifier based on the magnification level and control type
being rendered. The control type would be determined from the fallback
content.

Carets and Selection Positions: On Windows, a magnifier will track a global
caret position notification or a position from the caret location in the
accessible text services layer (depending on which accessibility API you
are using). Also, IE supports caret tracking, so whenever you select text
they are moving the caret. This is what screen magnifier will track.

On the Mac magnification focus position (point around which you are
zooming) is driven by a caret position and a selection position. When you
are selecting text on a Mac the caret does not move so you have to track
where you are pointing to select text. Once you move the caret you then
track the caret.

This is why we have two entirely different APIs in the proposal for Issue
74.

My new proposal I am vetting with James actually only passes the focused
element.

I should also add that I created two defects, as you requested, to have a
caret and selection drawing API that would manage the caret and selection
accessibility services support under the covers. The accessibility services
could be handled under the covers without the author having to manage
accessibility support separately.

Would you like me to send the proposal I sent to James to you so that we
can develop it further?

Rich


Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Ian Hickson <ian@hixie.ch>
To:	public-html@w3.org
Date:	07/29/2010 02:31 AM
Subject:	Change proposal for ISSUE-74 and ISSUE-105
Sent by:	public-html-request@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.   `._.-(,_..'--(,_..'`-.;.'