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

[Rik Cabanier]

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

> On Wed, Oct 9, 2013 at 9:08 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> I'd like to add for focus rings. They are currently specified in the w3c
>> and whatwg canvas specs:
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring
>> http://www.w3.org/TR/2dcontext/#dom-context-2d-drawsystemfocusring
>>
>
> Could you point us to the list of use cases or the whatwg/w3c thread where
> the discussion took place?
>

Rich should be able to point you to where those are posted since he was the
main contributor. (You can also do a search for "canvas focus rings" to
find many email threads on whatwg)


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


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


>
>  I created a patch (https://bugs.webkit.org/show_bug.cgi?id=122177) but
>> it needs more tests.
>> Also, should I implement it behind a runtime flags?
>>
>
> I definitely would like to see a build flag around it.
>

OK. I will do so.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131010/cc164fb6/attachment.html>