Re: [whatwg] Outline style to use for drawSystemFocusRing

On Wed, Oct 16, 2013 at 12:46 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 12 Sep 2013, Dominic Mazzoni wrote:
> > On Wed, Sep 11, 2013 at 5:54 PM, Ian Hickson <ian@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?
>

You would scroll when the hidden element gets focus.


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


Yes, there should only be 1 scroll. Not to the location of the hidden
element (which only exists in the dom) but to the location of the focus
ring.


> 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.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Wednesday, 16 October 2013 20:45:34 UTC