W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] Outline style to use for drawSystemFocusRing

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Mon, 6 Jan 2014 23:42:06 -0800
Message-ID: <CAFz-FYxPswgb+37yfMDqj=jcp0bd55o4T+s0vqmSVt-dx5tHRg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Mon, Jan 6, 2014 at 10:54 PM, Ian Hickson <ian@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.

- Dominic
Received on Tuesday, 7 January 2014 07:42:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC