- From: Dominic Mazzoni <dmazzoni@google.com>
- Date: Mon, 6 Jan 2014 22:20:33 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Mon, Jan 6, 2014 at 9:43 PM, Ian Hickson <ian@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.
Received on Tuesday, 7 January 2014 06:20:58 UTC