[whatwg] Outline style to use for drawSystemFocusRing

[Ian Hickson]

On Mon, 6 Jan 2014, Rik Cabanier wrote:
> > >
> > > Yes, the browser backend remembers the update region of the fallback 
> > > content. Otherwise, screen readers would not be able to access it.
> >
> > Why would screen readers need to access it?
> 
> I'm not an expert on the subject, but the way Dominic implemented this, 
> once you call drawSystemFocusRing, you can hover over a region and the 
> a11y software will know the fallback element (and its aria rules).

That's not what draw*FocusRing() are for. If you want that to be possible, 
you should use the addHitRegion API. Using draw*FocusRing() for this 
doesn't work, since there's no way to set the label or role for 
non-controls, and there's no way to remove regions.


> > If the control is anywhere on the canvas. It might not be. If it isn't 
> > on the canvas anymore, what you propose would randomly scroll to where 
> > it was last seen.
> 
> That would only happen if the author didn't call drawFocusRing again 
> (which he is supposed to do to update the region of the fallback 
> content)

You can't call draw*FocusRing() if there's no focus ring to draw because 
the control isn't on the page in the first place.


> > But even if the control _is_ on the canvas, that's no guarantee that 
> > the location it's at is where the author wants to scroll to, as 
> > described in the examples above. There are (as described above) simple 
> > legitimate cases where scrolling to the focus position when the 
> > control is first focused is unambiguously the _wrong_ thing to do. A 
> > more elaborate one which I've described before would be where all the 
> > controls are initially just off-screen, visible just on the edge, but 
> > when focused, the control moves to the center of the screen. No 
> > scrolling should ever happen, because the author's script is taking 
> > care of making the controls visible. But all the controls, when 
> > initially focused, would have their focus ring first drawn on the edge 
> > of the canvas, and if we scrolled there, it would be very jarring and 
> > would be terrible UI.
> >
> > Forcing such behaviour on the author is bad API design.
> 
> But once again, it would be consistent.

There's no value to having consistency if the result is simply wrong, as 
it is here.


> If you were to do this in HTML, the window would scroll to the initial 
> location of the control.

As I noted in my previous e-mail, this is irrelevant since we're not 
talking about HTML controls, we're talking about custom controls where 
the entire point of the API is to allow the author to design everything 
from scratch. This includes scroll behaviour.


> I'm unsure what happens when you manually move a focused element 
> offscreen. Is the browser supposed to scroll so it stays visible? If so, 
> maybe drawSystemFocusRing should scroll as well.

This is comparing apples to oranges.


> If an author didn't want this behavior, he could locate the controls 
> off-canvas which would disable the focus ring (or not draw the control 
> at all and not call drawSystemFocusRing). Then when the fallback content 
> gets the focus, he can animate the control in place and call 
> scrollPathIntoView once the animation is done.

That doesn't help for the examples I've already given in this very 
thread, where the controls are only semi-visible.

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