Re: Issues the chairs overlooked in their review of the canvas accessibility API proposal for Issue 131

On 4/18/2011 2:03 PM, Sam Ruby wrote:
<snip>
> Additionally, the following was not found to make its case:
>
>> DrawFocusRing does not ensure that the focus ring, drawn, allows
>> the browser to follow focus ring conventions for the OS platform
>> that may also reflect user's preferences
>
> Can you clarify why the "Modify existing Canvas 2D API caret and focus 
> ring support proposal" makes it impossible to draw focus without driving
> magnification?

Current UA implementations of drawFocusRing canDrawCustom,
will -not- draw a focus ring, if canDrawCustom is true.

The w3c draft uses a single x/y coordinate to "inform the user that the 
focus is at the given (transformed) coordinate on the canvas".
The change proposal instead uses the current path, to expose information 
to the AT.

The single x/y coordinate used by the existing w3c draft is insufficient 
for driving a magnifier at high magnification levels.
That brings us back to where we are with drawFocusRing(element)

 From the current w3c draft:
"If the user has requested the use of particular focus rings (e.g. 
high-contrast focus rings), or if the canDrawCustom argument is absent 
or false, then draw a focus ring of the appropriate style along the 
path, following platform conventions, return false, and abort these steps."

The old semantics of canDrawCustom are intended to "return false" and use
system-based focus rings, if a setting is specified on the OS/UA level.

That intention is highlighted by Ian Hickson's objection:
"This proposal doesn't support having the user agent determine if the 
user prefers system rings vs custom rings"

This use was fundamentally altered by the change proposal -- the author is
no longer exposed to system preferences. Instead, it is handled by the UA.

However, that was not the objection noted in the decision.

The objections were, instead, about controlling a custom focus ring:
"by removing the canDrawCustom parameter of the focus ring API, forces 
authors
to take the built-in focus drawing if they want to report the focus to 
the accessibility layer"
-and-
"This proposal doesn't support having the user agent determine if the 
user prefers system rings vs custom rings"

These don't seem to reflect step 3 of drawFocusRing(element):
"If the user has configured the operating system to draw focus rings in 
a certain way (e.g. high-contrast focus rings), then the user agent 
should draw a focus ring of the appropriate style along the drawing path 
otherwise the user agent must draw the focus ring based on the canvas 
line drawing settings along the current drawing path"

For the first objection -- a user may simply use strokeStyle = 
'rgba(0,0,0,0)'.
A method similar to that is actually used to drive caret magnification 
in windows...
The caret is simply set to a transparent bitmap.

The second objection appears to be inaccurate. The proposal does have 
the UA determine ring preferences,
based on user settings. It does -hide- that information from the 
scripting environment; which is something
Ian Hickson pointed out as an objection. I don't see that as an issue, 
though.

This seems to be compliant use of the API per the change proposal:
ctx.strokeStyle = 'rgba(0,0,0,0)'; if(ctx.drawFocusRing(element)) { 
ctx.strokeStyle = 'blue'; drawCustomRing(); }

That particular use demonstrates magnification (via current path when 
drawFocusRing is called),
as well as the option for the UA to draw a ring based on user 
preferences, and the ability
of the author to draw a custom focus ring if the element is focused.


-Charles

Received on Tuesday, 19 April 2011 01:26:27 UTC