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

Rik Cabanier cabanier at gmail.com
Mon Oct 14 12:43:00 PDT 2013


On Fri, Oct 11, 2013 at 12:14 AM, Chris Fleizach <cfleizach at apple.com>wrote:

> Hi
>
> The naming of these methods also made it a bit confusing for me.
>
> It appears that drawCustomFocusRing   just updates the accessibility
> rectangle -- while the system variant does that, and draws the normal focus
> ring.
> In the former case, it doesn't really draw anything, it just allows an AT
> to retrieve the bounding box of the focused item.
>
> It seems that for this to be useful for ATs, you'd have to iterate every
> object in your canvas and call at least drawCustomFocusRing once. Then when
> the item actually did become focused, you'd have to call
> drawSystemFocusRing.
>
> I don't know what others think, but I think accessibility work is best
> done on demand.
>
> In this case I could imagine something like a RectangleRequestEvent be
> dispatched that the canvas could intercept.
> The event would have the Element in question as a data member of the Event.
> The canvas could set the rectangle in the event for that element
>
> Then this work would only have to be done when requested
>

This doesn't seem very workable and forces the developer to do more work.

If you think about how a canvas application woks, during the drawing cycle,
there's an understanding that a control is drawn. At that point, it's
straightforward to call drawCustom/SystemFocusRing and draw the focus area.
I suspect that most UI implementations do the same (probably by checking
the focused attribute).

Also, how would your suggestion tell the UA about what areas are associated
with the elements? What happens if an element is no longer focused? The
ring is drawn into the canvas bitmap so those pixels have to be regenerated.

On Oct 10, 2013, at 7:32 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>
>
>
> On Thu, Oct 10, 2013 at 7:26 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Thu, Oct 10, 2013 at 7:21 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>>
>>> On Thu, Oct 10, 2013 at 7:19 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>>
>>>> On Thu, Oct 10, 2013 at 7:14 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>>>
>>>>> On Thu, Oct 10, 2013 at 7:07 PM, Ryosuke Niwa <rniwa at webkit.org>wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>>
>>>>> I think non-normative text or a note could be added to make this more
>>>>> clear. In general, the function should be called when the focus changes or
>>>>> the element is relocated and the canvas should be redrawn.
>>>>>
>>>> ...
>>>>
>>>>>  As is, the specification reads as if the author needs to repaint and
>>>>>> call drawSystemFocusRing upon focus change.
>>>>>>
>>>>>
>>>>> That is correct and what should happen.
>>>>>
>>>>>
>>>> That seems to contract what you've said earlier:
>>>>
>>>>> 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.
>>>>>
>>>> (AT stands for http://en.wikipedia.org/wiki/Assistive_technology).
>>>>
>>>> Am I correct in saying that the author needs to call this function each
>>>> and every time an element "inside" the canvas is focused?
>>>>
>>>
>>> No, he needs to ALWAYS call this function wether it's focused or not.
>>>
>>
>> I understand that. My point is that the author has to explicitly repaint
>> the canvas and call drawSystemFocusRing when the focus changed for the
>> focus ring to be drawn.  i.e. UA can't later decide to draw the focus ring
>> on its own.
>>
>
> That is correct. The accessibility software can though since it just draws
> on top of the browser windows (and so can the web inspector)
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20131014/a71327ae/attachment.html>


More information about the webkit-dev mailing list