On Tue, Jan 7, 2014 at 11:12 PM, Dominic Mazzoni <[email protected]>wrote:
> On Tue, Jan 7, 2014 at 9:18 PM, Rik Cabanier <[email protected]> wrote: > >> >> On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <[email protected]> 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. > agreed. Note that the draw*FocusRing functions don't update the a11y of the canvas. Instead, they update the fallback element's region. This element is part of the HTML DOM and as such, is retained.
