[whatwg] Outline style to use for drawSystemFocusRing
dmazzoni at google.com
Mon Jan 6 23:42:06 PST 2014
On Mon, Jan 6, 2014 at 10:54 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 6 Jan 2014, Dominic Mazzoni wrote:
> > I understand that the addHitRegion APIs are the intended way to specify
> > the permanent location of a fallback content element. But practically
> > speaking, it makes far more sense to "cache" the bounding box of each
> > element when you call draw*FocusRing, otherwise you end up with a timing
> > problem, because as soon as you focus the fallback element, the screen
> > magnifier immediately wants to know its bounding box - but
> > drawSystemFocusRing may not get called until sometime later, when the
> > app decides to repaint - and by then it's already drawn the bounding box
> > in the wrong location. Some magnifiers respond to a "location change"
> > event, but others don't, requiring an ugly hack like sending a second
> > focus event, or delaying the first one.
> The paint is going to come within 16ms (unless the app has high latency,
> in which case it'll be unusable anyway). That's when the magnifier should
> be updated, not when the focus moves in the HTML document.
We don't currently delay accessibility events until paint. It'd actually be
a lot of extra work to do this and I can't see any benefit outside of this
one corner case.
> The simplest implementation of the current spec to cache the bounding
> > box when you call drawSystemFocusRing and return whenever the assistive
> > technology requests the bounding box of that fallback element, whether
> > it's focused or not. I know it isn't exactly what was intended, and
> > addHitRegion will be a more powerful solution, but I don't see the harm
> > in implementing it this way.
> The harm is what I described in the earlier e-mails. You are likely to end
> up zooming on the wrong thing. For example, if the app only renders the
> focused element, and puts it in a random place when it's focused, you'll
> draw the bounding box wherever the control was last time it was rendered,
> which may have nothing to do with where it'll be this time. Similarly, if
> the control is moving, but you only update the bounding box when the
> control is first focused, then you'll leave the magnifier behind.
I think that's a good argument that we need to handle the case where the
app updates the focus ring after it's been focused, which I agree with.
There's no reason to assume the app would update the location before the
first paint - it could just as easily begin a transition on the element
once it's focused, so it doesn't reach its 'final' location until 1 second
later. We should handle this case as well as possible.
I don't see that as an argument against caching the last known location of
an object too.
More information about the whatwg