- From: Rik Cabanier <cabanier@gmail.com>
- Date: Tue, 7 Jan 2014 23:06:57 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Dominic Mazzoni <dmazzoni@google.com>, Ryosuke Niwa <rniwa@apple.com>
On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 7 Jan 2014, Rik Cabanier wrote: > > On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <ian@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*. > > Right. They're not really APIs for accessibility at all. They're about > drawing focus rings. > No. The only reason for this API is accessibility. An author could just check the focused state and draw the ring himself; there's no need for an API to do this. > > 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 is non-conforming behaviour that is incompatible with the API design. > Doing this will cause harm, because the API is incapable, as designed, of > being used in this manner correctly without causing bugs. For example, if, > when an element is not focused, it's split into four parts, there's no way > to draw a single focus ring around it. Thus the data about that control's > position _will be incorrect_ if the UA relies on this method for this data. > I don't understand. The path for the focus ring can be anything, including multiple closed paths. The data for the a11y software won't be wrong, it will be the boundingbox of those paths. > > This is why addHitRegion() exists; it provides this data in a usable > manner. > > > > 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. > > The paths provided by the draw*FocusRing() methods aren't useful for this > purpose. Using them for this purpose is bogus. The paths provided to those > methods are only useful for direct-mode painting and direct-mode > notification to an AT API if such an API accepts direct-mode > notifications. If it doesn't, then the addHitRegion() API is what should > be used to send the notifications. No, the AT API is not direct mode. > > For the blink and firefox implementations (and the webkit patch) > > "informing the user" [1] means telling the DOM about the region of the > > fallback element so the a11y software can query it later. > > That's not conformant, and will lead to accessibility problems. > > Informing the user is an imperative action, not an indirect action > involving caching state over multiple frames. If that is the case, we should drop focus ring support. There's no point to just draw rings. > > Because of this, there also needs to be a way to disassociate the region > > from the fallback element (ie by having no current path when you call > > draw*FocusRing) > > Yes, if draw*FocusRing() were the API you describe, we would need such a > thing. The API you describe, however, is not draw*FocusRing(), it's > addHitRegion(), and it already has such a thing. addHitRegion is a much bigger implementation burden for authors and browser vendors. My fear is that given their complexity, authors will not provide a11y support.
Received on Wednesday, 8 January 2014 07:07:23 UTC