On Thu, Oct 10, 2013 at 6:56 PM, Rik Cabanier <caban...@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 6:08 PM, Ryosuke Niwa <rn...@webkit.org> wrote: > >> On Thu, Oct 10, 2013 at 1:35 PM, Rik Cabanier <caban...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
