Re: Working Group Decision on ISSUE-131 caret-location-api

On Thu, Apr 28, 2011 at 7:47 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> Hi again,
>
> Sending this as a separate note as this is of a different nature. This
> isn't new information regarding the decision, but a hope of reaching a
> proposal that is good for the web and that everyone is happy with.
> Also, a word of warning is that I still haven't had time to dig into
> this discussion to any great extent, so it's possible that i'm way off
> track or repeating things that have been previously raised. If that's
> the case, please let me know and I'll butt out.
>
> It appears that the main request for a change here is the ability to
> drive user focus separate from drawing the focus ring.
>
> My main concern (and I think the concern of some others) is that if we
> *force* people to use a separate API to drive user focus, many people
> will forget or will opt out out of lazyness or lack of time.
>
> But this doesn't have to be an either-or question. One solution that
> would satisfy both would be to add another boolean argument to the
> function which would indicate if drawing should drive focus or not. So
> the resulting API would be something like this:
>
> context.drawFocusRing(element, x, y, [ canDrawCustom ], [ driveUserSelection ]);
> context.setCaretSelectionRect(element, x, y, w, h);
>
> The most normal mode of operation would then be to simply write code like this:
> cx.beginPath();
> cx.moveTo(10, 10);
> cx.drawFocusRing(elem, 10, 20);
> cx.drawFocusRing(elem, 20, 20);
> cx.drawFocusRing(elem, 20, 10);
> cx.drawFocusRing(elem, 10, 10);
> cx.closePath();
>
> code like the above would focus the rectangle [10, 10]-[20,20], i.e.
> the bounding box of the coordinates included in the drawFocusRing
> calls.
>
> However, if the page wants, or needs, to drive focus separately, it
> can do that using the following calls
>
> cx.beginPath();
> cx.moveTo(10, 10);
> cx.drawFocusRing(elem, 10, 20, false, false);
> cx.drawFocusRing(elem, 20, 20, false, false);
> cx.drawFocusRing(elem, 20, 10, false, false);
> cx.drawFocusRing(elem, 10, 10, false, false);
> cx.setCaretSelectionRect(elem, x, y, w, h);
> cx.closePath();
>
>
> An alternative solution would be to not introduce a new argument, but
> simply say that a call to setCaretSelectionRect would replace the
> current focus box calculated using the calls to drawFocusRing, with
> the coordinates passed to setCaretSelectionRect. The more I think
> about it, the more I like this proposal even better.
>
>
> Further, I would call the function setFocusRect rather than
> setCaretSelectionRect. First off I think this will be used in
> situations other than driving focus towards a draw caret. Second, I
> think people tend to think of 'selection' in the context of
> copy-paste, rather than where the user is currently focusing
> attention. But given that this is a naming issue, I'm guessing it's
> been debated to death already! :)
>
>
> My experience is that all too few authors pay attention to
> accessibility concerns. Solutions that provide accessibility
> automatically without taking further action on the part of the author
> seems to work orders of magnitude better than ones that require the
> author to specifically take action. The above proposals were written
> in that spirit.

Hixie pointed out to me that my canvas code was totally wrong. Here is
a better description of what I mean:

The current (pre applying WG decision) syntax:

// Example A
cx.beginPath();
cx.rect(x,y,w,h);
cx.drawFocusRing(elem);

This would draw a OS-styled focus ring on the coordinates x,y,w,h as
well as tell AT that focus is currently located at those coordinates
as to enable it to magnify that part of the screen if desired.

What I'm proposing is that we enable the following syntax *as well*:

// Example B
cx.beginPath();
cx.rect(x,y,w,h);
cx.drawFocusRing(elem);
cx.setCaretSelectionRect(elem,x-10,y-10,w+20,h+20);

This would draw the focus ring on the coordinates x,y,w,h but tell AT
that a somewhat larger area is what needs to be magnified.

However, if someone just writes the code as in example A, it would
still inform AT that x,y,w,h is the area that should be magnified.
I.e. authors will *by default* get AT behavior that will work in most
cases, while still allowing advanced authors can opt in and override
that behavior using the more powerful feature set.

We could possibly also add an additional boolean argument to
drawFocusRing that tells the function to *just* draw the focus right,
but not inform AT of a new magnification area. But I'm less sure that
that is a feature that anyone has requested.

/ Jonas

Received on Friday, 29 April 2011 07:36:02 UTC