[whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson <ian at 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.

It's canvas-specific because in the non-canvas state, the browser already
> does this, in theory. The focus in the non-canvas case is drawn by the
> browser using the :focus rules, which, in principle, are set to the user's
> preferred state.
>

In practice this doesn't necessarily work for the same reason I gave above:
the system focus ring might look terrible in particular UIs.

> If we added a canvas fallback element as a parameter to
> > scrollPathIntoView, I don't think we'd need drawCustomFocusRing.
>
> I don't understand how this would work.
>
> Suppose you have a control that is floating around the screen. You need
> the keyboard-focus-driven magnification to follow this control while it's
> focused. You don't want to scroll to that control every time it moves, you
> only want to scroll to it when it's focused.
>
> So what you do is when it's focused, you scrollPathIntoView(), and then
> every 16 milliseconds you move the control and redraw its focus ring, by
> calling drawCustomFocusRing() (or drawSystemFocusRing() if you don't care
> exactly what it looks like), and that updates the AT.
>

Wait, so what's wrong with calling scrollPathIntoView on it every 16
milliseconds, only when it's focused?

drawCustomFocusRing() and drawSystemFocusRing() shouldn't cause anything
> to scroll. That would be very confusing, IMHO. (When would you scroll?
> Consider the case of the control originally being off-screen on purpose,
> and animating into position. You want the focus ring drawn the whole time,
> and the zoom to follow it maybe, but you only want to scroll once, at the
> start, to the location that it will have at the end.)
>

OK, that seems like a reasonable argument. Let's keep scrolling separate.

It would appear that on Win32, the SystemParametersInfo function has
> SPI_GETFOCUSBORDERHEIGHT, SPI_GETFOCUSBORDERWIDTH, and SPI_GETHIGHCONTRAST
> options that may be relevant here.
>

Agreed that those should change the appearance of the focus ring drawn by
drawSystemFocusRing.

I don't think it should override an app that wants to draw its own focus
ring for the reasons given above - if the canvas author doesn't have any
way to query the system foreground and background color, or if the user has
explicitly chosen a color palette specific to this web app, then using the
system focus ring could look much worse.


> > Windows has a system setting for high-contrast mode. When you turn on
> > high contrast mode, it changes the default color palette. There's no
> > other effect on the focus ring that I know of.
>
> This may be the high contrast theme, which is distinct from high contrast
> mode, according to the Remarks section here:
>

They are separate settings, but what I've seen most apps do is use system
colors when high contrast mode is on, and use their own colors when it's
off. That sounds fine - but only picking the focus ring color by itself
doesn't make sense.

> High contrast mode may affect the system focus ring color, it's true -
> > but there's no reason to believe that this system focus ring would look
> > better on a canvas when high contrast mode is on, and in fact it might
> > look much worse.
>
> But presumably if you're in high-contrast mode, you might want to render a
> more contrasty focus ring, even if it's not the system one.

...

> Cursors solve this problem by having a white border around a black border
> around a white arrow (or vice versa). I could see a high-contrast focus
> ring being done in a similar fashion.


Yeah, but this is nonstandard, no other apps do this. What other apps do,
if they respect high contrast at all, is to use all of the system colors,
or none of them.

> If the author wants to draw their own focus ring, it's probably for a
> > good reason. We should let them.
>
> Well we're never stopping them, are we? I mean, they can always do what
> they want...
>

Yes, we're preventing them from drawing their own focus ring and notifying
assistive technology.

drawCustomFocusRing, as specified now, tries to make judgement calls and
doesn't give the web developer any insight or flexibility. Plus it's
confusingly named, so the odds that the typical developer will use it
correctly are not good.

What we really want is for the web developer to know if high-contrast mode
is on, and a way to notify the browser of the focus ring location. That
sounds like two APIs to me, and the first one isn't canvas-specific.