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

[Rik Cabanier]

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)


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