On Thu, Oct 10, 2013 at 7:13 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Thu, Oct 10, 2013 at 7:09 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> On Thu, Oct 10, 2013 at 7:02 PM, Ryosuke Niwa <rn...@webkit.org> wrote: >> >>> 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. >>> >> >> No, the function will draw the ring, but only if the element is focused. >> People have gone over the name multiple times and this seems to be the >> one that's hated the least :-( >> > > Only if it's focused right? But the point of this function is that > defining area for every focusable element upfront. Then the name of the > function should reflect that semantics. The fact it draws the focus ring > synchronously sometimes is almost a side-effect. > I agree. This is why the feature is still behind a flag in chrome and firefox and on the at-risk list for Canvas. Dominic and I want to clarify the text and possible come up with better names. By implementing it, we can start to see the problems with the current wording.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
