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

[Ryosuke Niwa]

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?


>  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.

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