Re: Bug 11239

> On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
>> >
>> > In the agreed on change proposal getCaretBlinkPeriod should return a
>> > value less than zero if no operating system setting exists. Ian
>> > removed that from the chairs decision.
>>
>> Yes, I'm not sure of Ian's rationale here.
>
> The chairs asked me to apply the bullet points here:
>
>   http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection#Details
>
> ...except for bullets 2 and 6. None of these bullets mention anything
> about "no operating system setting" existing.

The bullet points are summary text to enumerate changes in the linked fork:

http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/att-0129/HTML_Canvas_2DContext20110415.html

Bullet point 5 is: "Added a function to get the caret blink rate to
reflect system settings set by users that may have been done to prevent
seizures."

In the linked fork we find:

"If the operating system does not support a caret blink rate setting the
user agent must return a long value less than zero."

> I have no idea what this would even mean. Is there an example of this somewhere?
>
>> Ian: could we perhaps specify to return -1 in this case?
>
> What case is this case, exactly? An example would be most helpful.

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.

Perhaps where you currently have:

<p>The <dfn title="dom-navigator-caretBlinkPeriod"><code>caretBlinkPeriod</code></dfn>
attribute should return the sum of the time, in milliseconds, that
such a caret spends visibile and invisible in a single blink cycle,
if the platform conventions are such that the caret blinks in a
manner similar to that described above. On platforms where a caret
does not blink or is otherwise not adequately described by a blink
period, the attribute should return zero.</p>

We could have:

<p>The <dfn title="dom-navigator-caretBlinkPeriod"><code>caretBlinkPeriod</code></dfn>
attribute should return the sum of the time, in milliseconds, that
such a caret spends visibile and invisible in a single blink cycle,
if the platform conventions are such that the caret blinks in a
manner similar to that described above. 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?

>>   * Ian's patch is less detailed in its suggestion of how focus notification
>>     should be approached, whereas your list suggests that a best fit
>>     rectangle on
>>     screen should be created and surfaced in the accessibility tree. I suppose
>>     vagueness provides for accessibility APIs that can understand
>>     non-rectangular
>>     areas. Ian, could we perhaps include the best fit rectangle approach as just
>>     as an example?
>
> The best-fit approach text in the proposed patch is completely
> meaningless. I have no idea what was even _intended_ by the text. If
> someone could explain what it means, I would be happy to make sure the
> spec fully defines whatever is appropriate.

I'll try, but I don't think I have the expertise to take us all the way
there!

The representation of a visible object in an accessibility tree tends
to include a bounding rectangle property:

UI Automation AutomationElement.BoundingRectangleProperty
http://msdn.microsoft.com/en-us/library/system.windows.automation.automationelement.boundingrectangleproperty.aspx

MSAA IAccessible::accLocation
http://msdn.microsoft.com/en-us/library/ms696118(v=vs.85).aspx

Apple Cocoa NSView::frame
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/NSView.html%23//apple_ref/doc/uid/TP40004149

Such bounding rectangles can be used by magnifiers to zoom the
appropriate part of the screen on change of focus.

A best-fit rectangle for a drawn path would be the smallest rectangle
that can contain all the points on the path.

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?

The same APIs tend to include hit testing that is /supposed/ to take
account of irregular areas. Here's documentation about how this is
supposed to work in the case of MSAA:

http://msdn.microsoft.com/en-us/library/ms695714(v=vs.85).aspx

I do not know whether canvas's design allows for more accurate
hit-testing than a best-fit rectangle. Olivier Hunt objected that
anything more would turn canvas into a retained mode API:

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

Richard's position, which I imagine informed the Change Proposal,
appears to be that a best-fit rectangle is sufficient for hit-testing:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0277.html

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

I seem to remember you've talked in the past about adding more of a
retained mode to canvas for enabling hit testing. Would it be viable to
start with hit testing based on best-fit rectangle and improve hit
testing for irregular shapes later?

It seems to be plausible that hit testing based on a best-fit rectangle
is sufficient for a magnifying API clients as zoom areas are themselves
rectangle, but I do not know if this is strictly the case. For example,
if an irregular shape is zoomed, and the user clicks on another shape
outside that shape but within the bounding rectangle of this first
shape, which object gets clicked and how is that decided?

>>   * Ian's patch tries to ensure notification about change of focus happens
>>     after drawing the focus ring (potentially in the next event loop), whereas
>>     in your list the notification happens *before* drawing the focus ring
>>     (presumably preventing progress to the next event loop). Is this a bad
>>     change?
>
> 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?

--
Benjamin Hawkes-Lewis

Received on Thursday, 28 April 2011 19:41:48 UTC