[whatwg] Outline style to use for drawSystemFocusRing

[Dominic Mazzoni]

On Mon, Jan 6, 2014 at 9:43 PM, Ian Hickson <ian at hixie.ch> wrote:

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

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