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

[Ryosuke Niwa]

The spec. text is also misleading in saying that

The drawSystemFocusRing(element) method, when invoked, must run the
following steps:

If I understood your reply correctly, these are steps that need to be ran
continuously?  Or is it that steps 2 & 3 must run upon the currently
focused element being changed.  The specification needs to revised to
clarify this.

As is, the specification reads as if the author needs to repaint and call
drawSystemFocusRing upon focus change.

- R. Niwa


- R. Niwa


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.
>
> - R. Niwa
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131010/dcbb9689/attachment-0001.html>