Re: [whatwg] Outline style to use for drawSystemFocusRing

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.


> 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.

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.


> 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.


> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 8 January 2014 05:46:56 UTC