On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier <caban...@gmail.com> wrote:
> > On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <i...@hixie.ch> wrote: > >> >> > I don't see that as an argument against caching the last known location >> > of an object too. >> >> If you want to store state, that's what addHitRegion() is for. It's the >> retained mode API for canvas. The draw*FocusRing() methods are direct-mode >> APIs. There's no expiry logic, there's no API contract that implies that >> the calls will be made, or made correctly, if the element isn't focused. >> > > I believe this is where part of our confusion/disagreements come from. > The draw*FocusRing methods are NOT direct-mode APIs for *a11y*. > > By calling draw*FocusRing on a fallback element, the a11y software will > now associate that element (and its aria rules) with the path that was in > the canvas' state. > This HAS to be stateful because the a11y software queries the browser for > the bounds of the fallback element to draw its own focus rectangle. > Yes. A11y APIs on every platform I'm familiar with (Windows, Mac, Linux/ATK, Android, iOS) are essentially retained-mode. When focus changes, the application notifies the system and gives it an ID or reference that identifies the focused object. Assistive technology may query the bounds of this object immediately, or at any time in the future. If you restart or load a magnifier while the browser is already running, it will explore the tree, discover the object that has focus, and zoom the screen and/or draw its own ring around it at that time.