[webkit-dev] Proposal: Add support for focus rings in Canvas 2d

[Ryosuke Niwa]

On Thu, Oct 10, 2013 at 6:56 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>>
>>>  Support (behind runtime flags) has landed in:
>>>>> - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=540456
>>>>> - chrome: https://code.google.com/p/chromium/issues/detail?id=261998
>>>>>
>>>>> Focus rings associate elements that are in a canvas tag with areas of
>>>>> the canvas.
>>>>> If the user tabs into the hidden element or the accessibility software
>>>>> selects them, these methods will draw or let the author draw the focus
>>>>> rings.
>>>>>
>>>>
>>>> How does this API address this use case?  It seems like each Web app
>>>> needs to explicitly opt-in and manually draw focus ring?
>>>>
>>>
>>> That is correct. This is code that the canvas developer needs to
>>> implement.
>>>
>>>  I'm not sure if that's a good accessibility API given that many
>>>> authors don't even use most basic accessibility feature such as ARIA roles.
>>>>
>>>
>>> There's not much we can do about this. However, for authors that DO want
>>> to provide this, there's is currently no way to provide accessibility for
>>> canvas.
>>>
>>>
>>>>
>>>> e.g. why can't UA automatically draw focus ring on top of the canvas?
>>>>
>>>
>>> The problem is that the UA doesn't know what part of the canvas area
>>> corresponds with the hidden element. This API is designed to make that
>>> association
>>>
>>
>> Why can't authors provide that information by placing elements at the
>> area it should be displayed instead?
>>
>
>  Place invisible elements on top with absolute positioning? That seems
> error prone + you'd constantly have to change the DOM
> Also, the focus area is not always rectangular. For an example see
> http://dmazzoni-google.github.io/canvas-focus-ring-demo/
> (You will need chorme canary or latest firefox nightly with focusrings
> turned on)
>

I see. That's a good use case.

  Also, the spec seems to indicate that the physical (rendered) position of
>>>> an element can change dynamically without UA being notified.
>>>> How are ATs supposed to inform users of the ordering of those focusable
>>>> elements?
>>>>
>>>
>>> I'm unsure I follow. Can you elaborate?
>>>
>>
>> How are ATs supposed to know the visual ordering of elements if authors
>> are only updating elements' positions by calling drawSystemFocusRing when
>> they are focused is my question.  To put it another way, ATs need to know
>> where elements appear in order to let user move the focus onto those
>> elements.
>>
>
> What is an AT? :-)
> You don't call drawSystemFocusRing when an element is focused. You
> *always* call it and if it is focused, a ring will be drawn. In all cases,
> the accessibility software is notified of the area.
>

WAT. Why is this function called drawSystemFocusRing if it doesn't draw
anything?  I completely misunderstood the API because of its misleading
name.  Can we please rename the function?  e.g. defineSystemFocusableArea.

I strongly object to the proposed name.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131010/4e17fdb9/attachment.html>