[whatwg] Outline style to use for drawSystemFocusRing

[Ian Hickson]

On Thu, 12 Sep 2013, Dominic Mazzoni wrote:
> On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 10 Sep 2013, Dominic Mazzoni wrote:
> > >
> > > We've finished implementing drawSystemFocusRing and 
> > > drawCustomFocusRing in Chrome. Try it in Chrome 31 or higher (either 
> > > canary or dev channel should work today). You'll need to go to 
> > > chrome://flags and enable *experimental canvas features*, then 
> > > restart the browser.
> > >
> > > Here's a demo I built that uses drawSystemFocusRing: 
> > > http://dmazzoni-google.github.io/canvas-focus-ring-demo/
> >
> > Looks good. Was your conclusion that the spec was ok as is, or did you 
> > deviate from the spec in some way that needs a spec change
> 
> I think drawSystemFocusRing is good to go. If you want, you can update 
> the spec to reflect that an implementation is available (behind a flag).

Anyone can update the spec's annotations, actually -- just 
alt+double-click on the annotation box or the relevant part of the spec, 
and it'll bring up an editor. (You may have to log in first; see the UI at 
the very top right of the spec.)


> Only one minor issue for clarification: if the current path is a line or 
> unclosed polygon, should it be closed (or otherwise outlined) when 
> drawing the focus ring? Currently we're not doing so in Chrome, but it 
> might help to clarify. For example, if the path is a line, what's drawn 
> is just an additional stroke on that line, not a "ring".

Done.


> I'm not as sure about drawCustomFocusRing. The spec says "If the user 
> has requested the use of particular focus rings", but I'm not aware of 
> any platform API we could use to query that.

It may be that on some platforms there is no such API.

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).


> So, what we implemented in Chrome for drawCustomFocusRing is basically 
> just a function that notifies assistive technology of the bounding rect 
> of the focused region within the canvas. It's still useful, but if 
> that's all it does, then drawCustomFocusRing is a poor name. Perhaps it 
> should be called something like notifyFocusLocation or something like 
> that.

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.


On Mon, 30 Sep 2013, Dominic Mazzoni wrote:
> 
> The correct thing to do for those users is to use accessibility APIs to 
> make the operating system aware of the focused object and its bounds. If 
> users have ZoomText or MAGic installed, or if they're using VoiceOver or 
> Orca, their assistive technology will draw its own focus ring *in 
> addition* to the application's focus ring.
> 
> No other application hides its focus ring just because, e.g., ZoomText 
> is drawing a focus ring. The rest of the web doesn't do it. Why do we 
> need it for canvas?

If it's the case that the OS ring can't be customised, and that what 
people refer to when they talk about customised rings is having the ring 
drawn again by ATs, then you're right -- drawCustomFocusRing() would never 
draw anything. However, it's not clear to me that that is the case.


> The problem is that there aren't existing operating system or browser 
> settings that specifies that the user wants better focus rings.

Are we sure? That isn't clear to me. If it was true, why would WCAG 2.0 
say that authors shouldn't fiddle with the focus ring style, for example?


> Finally, as a meta-argument, if we really want a preference for custom 
> focus rings, then wouldn't we want that for the rest of the web? If I'm 
> building a custom form control and I need to choose a drawing style when 
> focused, wouldn't I want to know if the user wanted custom focus rings, 
> too? In other words, what makes this need canvas-specific?

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.


On Mon, 30 Sep 2013, Dominic Mazzoni wrote:
> 
> scrollPathIntoView can't be used to notify accessibility software of the 
> focused object location as-is because it doesn't have an element to fire 
> on, and it doesn't know if the scrolling is because of focus or not.
> 
> 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.


On Wed, 2 Oct 2013, Rik Cabanier wrote:
> 
> I don't understand. If the path that is active during 
> drawCustom/SystemFocusRing is off screen and the element is focused, the 
> browser will scroll to that area.

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.)


On Fri, 4 Oct 2013, Dominic Mazzoni wrote:
> 
> What I don't understand is how a browser is supposed to implement the 
> high contrast focus ring support on a real operating system that exists 
> today. Are there other apps that do this? Are there published guidelines 
> anywhere?

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


> 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:

   http://msdn.microsoft.com/en-us/library/windows/desktop/ms724947(v=vs.85).aspx


> Windows also has settings for the focus ring width. I agree those should 
> affect the system focus ring, but I don't think users would expect that 
> to override a canvas author's focus ring.

Why not? If they've set their ring to be unusually wide, why wouldn't they 
want this to apply to canvas apps as well?


> 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.


> Or, here's another argument: a canvas can contain absolutely anything. 
> It might contain a wild and crazy color palette. Only the canvas author 
> knows what focus ring is going to be visible on top of that canvas. If 
> the canvas is white text on a black background, then a dark-colored 
> focus ring is going to be practically invisible, and vice versa.

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.


> It just doesn't make any sense to me that we're providing an API that 
> says, if you want to draw your own focus ring, use this - BUT, under 
> some circumstances we're going to tell you not to draw it and the 
> browser or operating system is going to draw it for you, even though the 
> browser has no idea what colors are on your canvas and what type of 
> focus ring would be visible against it.

Well, the browser can know what the colours are, and can draw rings that 
are colour-agnostic. But sure.


> 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...


I think if the user asked for a particular kind of focus ring, we should 
probably honour that. But if there's no real way to implement that, then 
drawCustomFocusRing() could indeed just never draw.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'