Re: [whatwg] Outline style to use for drawSystemFocusRing

Thanks for taking this to the group!

Dominic's patch for Chrome is almost identical to the one I provided for
WebKit, including the synchronous drawing of the ring.
see: https://codereview.chromium.org/19786002/
The accessibility backed of chrome doesn't scroll like the one in WebKit
and FireFox which is why we're seeing a difference in behavior.


On Thu, Oct 17, 2013 at 9:55 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> On Oct 16, 2013, at 1:36 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:
>
> > On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> >> WCAG 2.0 claims that "many platforms allow the user to customize the
> >> rendering of this focus indicator", though I admit that I don't see any
> >> references for this claim:
> >>
> >>   http://www.w3.org/TR/WCAG-TECHS/G165.html
> >>
> >> IBM similarly claims "users may customize the default indicator in
> Windows
> >> to a brighter color":
> >>
> >>
> http://www-03.ibm.com/able/guidelines/web/webfocusvisible_aa.html#tech3
> >>
> >> I haven't been able to support those claims. However, Win32 in
> particular
> >> has some APIs for changing focus rings (see below for references).
> >>
> >
> > If the user changes the focus ring's color and/or width, then
> > drawSystemFocusRing should draw using that style.
> >
> > The issue is when the application wants to draw its own focus ring -
> should
> > the system sometimes override that and draw its own focus ring instead?
> > That's the argument I don't buy.
> >
> > Respecting the system focus ring color but ignoring the rest of the
> system
> > palette makes no sense. Suppose the user has chosen white-on-black text
> > with a yellow focus ring. The canvas normally draws a black-on-white GUI
> > with red focus rings that are really easy to see. If the canvas calls
> > drawCustomFocusRing and the system draws its yellow focus ring instead,
> it
> > will actually be worse. So drawing the custom focus ring, in the absence
> of
> > the rest of the information about the system palette, is not necessarily
> an
> > improvement at all.
> >
> > I think this feature was proposed with the best of intentions by people
> who
> > misinterpreted how Windows system colors and styles work, and didn't
> think
> > through all of the implications.
> >
> > I am totally in favor of trying to provide a better experience for users
> > who want a high-contrast theme and custom focus rings - I just don't
> think
> > this API is the way to achieve that goal, and I think it would actually
> > make things worse if user agents implemented it as specified.
> >
> > Perhaps this shouldn't even be solved as part of canvas. Maybe we should
> > add web apis to indicate that the user prefers a custom color scheme that
> > could be used for rendering the whole page, not just canvas.
> >
> > The name isn't ideal, it's true. I don't know what a better name should
> >> be, though. It's really "let me know if I should draw a focus ring, and
> if
> >> I should, then take the opportunity to also notify the accessibility
> >> tools", which doesn't make for a very pithy method name.
> >>
> >
> > What would you call it if it never draws, but just notifies the UI? I
> think
> > we could call it notifyFocusRingPath or something like that. Or we go
> with
> > the scrollPathIntoView idea.
>
> or something like defineFocusableRegion/defineFocusableArea.
>
> I'd much refer names that signify the fact these functions define
> focusable area/region than the fact
> it may draw the focus ring if the element is already focused since authors
> need to call this function
> on all focusable elements that are currently visible on the canvas.
>
> If we were to implement this API in WebKit, I don't think we'll draw the
> focus ring synchronously either
> (i.e. our implementation will be similar to what Dominic said Chrome does).
>
> - R. Niwa
>
>

Received on Friday, 18 October 2013 06:01:18 UTC