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.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 29 July 2010 17:54:42 UTC