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

[Rik Cabanier]

On Thu, Oct 10, 2013 at 7:13 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Thu, Oct 10, 2013 at 7:09 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Thu, Oct 10, 2013 at 7:02 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>>> 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.
>>>
>>
>> No, the function will draw the ring, but only if the element is focused.
>> People have gone over the name multiple times and this seems to be the
>> one that's hated the least :-(
>>
>
> Only if it's focused right?  But the point of this function is that
> defining area for every focusable element upfront.  Then the name of the
> function should reflect that semantics.  The fact it draws the focus ring
> synchronously sometimes is almost a side-effect.
>

I agree. This is why the feature is still behind a flag in chrome and
firefox and on the at-risk list for Canvas.
Dominic and I want to clarify the text and possible come up with better
names. By implementing it, we can start to see the problems with the
current wording.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131010/f0918a71/attachment.html>