[whatwg] Outline style to use for drawSystemFocusRing

[Rik Cabanier]

On Tue, Jan 7, 2014 at 9:45 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 7 Jan 2014, Rik Cabanier wrote:
> > On Tue, Jan 7, 2014 at 1:10 PM, Ian Hickson <ian at 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.