Re: Bug 11239

On Thu, Apr 28, 2011 at 8:55 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
>>
>> One example would be that the system has no caret. For example, a system
>> with no visual output presumably does not have a caret blink rate.
>
> Could you provide an example of such a system where the author would
> nonetheless be using this value and where a return value of 0 would not
> be more likely to be handled correctly by the author?
>
>
>> Perhaps where you currently have:
>>
>> On platforms where a caret does not blink or is otherwise not adequately
>> described by a blink period, the attribute should return zero.
>>
>> We could have:
>>
>> If the caret does not blink, the attribute should return 0. On platforms
>> that do not have a caret or where the caret is not adequately described
>> by a blink period, the attribute should return -1.</p>
>>
>> Would that be acceptable?
>
> That seems like terrible API design. You do not want rare cases in Web
> APIs, because authors will never test for them.
>
> Or to put it another way: what problem does this solve?

The problem is if the author wants to use a default blink rate
in the absence of better information. Consider two scenarios:

   1. The user has set his caret to not blink. When drawing a custom
      canvas caret, the author wants to draw a caret that does not blink.

   2. The UA cannot provide a blink rate (for whatever reason). When
      drawing a canvas caret, the author wants to draw a caret with a
      default blink rate (apparently this is usually 500ms).

0 vs -1 allows authors to distinguish these two scenarios.

I have argued previously that, if we are expecting authors to use 500ms
in the second scenario, it would be best to simply return 500 by
default:

http://lists.w3.org/Archives/Public/public-canvas-api/2011JanMar/0049.html

500ms is consistent with WCAG2's stipulations on seizures:

http://www.w3.org/TR/WCAG20/#seizure

It would also give us a value that could be used to protect privacy.

This suggestion was apparently discussed but not adopted by the TF.

Another author option in scenario 2 is to default to a blink rate of
zero, on the basis that this won't ever cause seizures. If that's our
expectation of authors, then returning 0 in both cases would make sense
(to me).

On the other hand, if some authors want to default to 500, and some
authors want to default to 0, and we want to give authors the *choice*,
then returning a special value for the second scenario is the only way
to do that, hence -1.

This final position (leave it up to authors) seems to the one taken in
the draft text endorsed by Decision: "For a blink rate less than zero
the author, when drawing a blinking caret, must determine the blink
rate."

So ultimately I guess that's what the patch should say. We can of
course review this going forward.

>> So one clear goal here is that when user agents exposing content to
>> such APIs update the accessible tree, they populate properties like
>> BoundingRectangleProperty with the coordinates of the best-fit
>> rectangle.
>>
>> Does this much seem workable?
>
> Sure, but what's that got to do with what the spec says? We definitely
> do not want to be specifying UI, and this seems to be doing exactly
> that. The UA should be entirely at liberty to do what is best for the
> user

The language in Rich's steps and in your patch uses "may" so whatever we
say here we're not really enforcing any particular implementation, or
are we?

> if the UA notices that the path consists of a single point off the
> screen and a rectangle on the screen, it seems like the UA should be
> entirely at liberty to ignore the point off the screen, for example.

I honestly don't know, but I'd naively expect those sort of
optimizations to be undertaken in accessibility API client code that
knows what it is trying to do on behalf of the user and which has
retained knowledge about visible elements within multiple applications,
rather than in accessibility API server code that neither knows what the
user is doing nor what other applications are doing around it.

(Given automation and testing tools also make use of accessibility APIs,
I can imagine applications that lie about where things are could be
particularly irksome however good the intention.)

> Hit-testing has nothing to do with drawing the focus area as far as I
> can tell. That's what isPointInPath() is for.

[snip]

> I don't understand the relevance of this to this WG decision.

If hit testing is a red herring here I'm sorry to have brought it up;
please ignore. :)

>> > It's a required change; the alternative is that every time the UA
>> > draws the focus ring and then the caret the magnifier would blink
>> > around creating exactly the kind of situation that might lead to
>> > seizures, which is what a big part of this patch is about avoiding.
>>
>> Sorry, this /sounds/ good I'm not sure I actually follow. Is the idea
>> to only send accessibility events if the method results in the
>> focused element changing or visible focus ring moving from where it
>> was previously drawn? Or are you talking about repainting that
>> doesn't arise directly from a call to this method?
>
> The idea is to allow UAs to only inform the user once per event loop
> rendering step.

This goal sounds okay to me, but Rich may have a subtle objection I do
not follow. Could you perhaps elaborate, Rich?

--
Benjamin Hawkes-Lewis

Received on Thursday, 28 April 2011 20:46:13 UTC