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

I understand your points. If we put these in one call we need to convey
that the ring is used for a caret vs. a focus ring so that the appropriate
accessibility services api are fulfilled. Keep in mind we also have to do
something for selected text as well. Macs work a little differently under
the hood.

Let me send you what I have and lets see if we can do this in one API
method. If we can I am all for it.

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:	Ian Hickson <ian@hixie.ch>
To:	Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc:	public-html@w3.org
Date:	07/29/2010 12:54 PM
Subject:	Re: Change proposal for ISSUE-74 and ISSUE-105



On Thu, 29 Jul 2010, Richard Schwerdtfeger wrote:
>
> 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.

That isn't a reason to have them split out. The browser can easily drive
two accessibility features from one API call.

The problem is that if we split them out, the caret one will be unused,
because it doesn't do anything of a non-accessibility nature.

The idea behind drawFocusRing() is that we are essentially "tricking"
authors into writing accessible code by giving them a tool that does
something useful for them (automatically drawing focus rings but only when
the element is focused), and taking advantage of this to provide
accessibility features (magnification around the caret, drawing accessible
focus rings, etc).

I think if we must split them (and I'm not sure we must), we'd have to
provide an API that draws the caret in some way, maybe with a callback
that the UA can invoke when it's time to make the caret blink. I started
trying to specify something to do this, but the problem is that there
doesn't appear to be any point -- my research suggests that on Windows the
accessibility APIs for caret painting aren't actually used by ATs;
instead, ATs perform heuristic analysis of the screen to detect the
blinking caret; and on both Mac and Windows, when there's a selection
there's no drawn caret, so the authors wouldn't invoke the API. This makes
providing a caret API somewhat of a lost cause for the intended purpose.

The key point though is that we can't rely on authors to call
accessibility-specific APIs. The number of authors who are willing to go
out of their way to make pages accessible is miniscule. Just as with
elements like <progress>, which provide a way to get accessible dynamic
progress bars by tricking authors into doing something that they feel is
less work (than lots of <div>s), we have to come up with APIs here that
lazy programmers will gravitate towards in order to improve accessibility.


> 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 suggests we really don't want to have two APIs -- we just want one,
to give the x,y coordinate of the magnification position (which we can
then trick authors into using by providing them with the focus ring
drawing as a stalking horse).


> 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.

If we can do this via the bug system rather than the issue tracking system
that would certainly be preferable. I provided my change proposal because
the deadline for the issue was coming up. If we can drop the issue and
instead do it via bugs that is certainly my preference, as it is far less
time consuming.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'