Re: hit regions and a11y geometrics

Hi, Rik. Answering inline.


On Wed, Jan 29, 2014 at 9:49 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Thanks for taking this to the list!
>
>
> On Wed, Jan 29, 2014 at 5:03 PM, Alexander Surkov <
> surkov.alexander@gmail.com> wrote:
>
>> Hi. We've got a discussion at Mozilla bug [1] about drawFocusIfNeeded
>> spec and implementation. I'll try to outline the outspoken concerns there
>> and sketch up the alternative approach.
>>
>> A first thesis I would make is the web author can do CSS to define
>> geometry of DOM elements underneath the canvas and in most cases it should
>> work well.
>>
>
> Do elements in the fallback content render?
>

yes


> Trying this out in Safari and Chrome using the accessible clock [1], it
> seems that CSS is not applied to the fallback content. (The elements aren't
> even laid out)
>

I just checked Firefox and it works perfectly fine.


>
>
>> Having said that I admit that it still may be useful to have special API
>> to define the boundaries since
>> 1) it may be just handy (if you drawn an element then reuse its path for
>> a11y needs)
>> 2) geometry of drawn thing may be different from geometry of associated
>> DOM element (like fancy triangle checkbox)
>>
>> As I understand a current approach adopted/implemented by Chrome is to
>> make drawFocusIfNeeded to define accessible boundaries for any element not
>> depending on whether the focus is drawn or whether the element is focused
>> or not.
>>
>> I see an advantage of the approach in its simplicity like the author can
>> "get accessibility for free" but imo the same time this advantage may be
>> considered rather confusing:
>>
>> 1) the method name doesn't make it evident that accessible object
>> boundaries are changed (especially when it's called on the element having
>> no focus), so the author theoretically can make wrong assumption about the
>> method behavior
>>
>
> Yes, we've gone over this before. Adding this extra info to the function
> call made it too verbose.
> Maybe we can revisit this?
>

I'd be happier a bit but if we had hit regions then it's not really
necessary and probably even bad since drawFocusIfNeeded won't be longer
elegant.


>
>
>>  2) A focus ring is not really the same as element boundaries, for
>> example, focus ring created by CSS outline style is drawn outside the
>> element boundaries. Having said that I agree it must be close and may
>> provide a good idea about object boundaries.
>>
>> On the other hand the spec provides hit regions concept that can be used
>> to define accessible boundaries. For the author it means he have to make
>> one extra call (drawFocusIfNeeded + addHitRegion).
>>
>> Besides boundaries definition the hit regions are useful to connect the
>> canvas representation with its DOM element. In other words, if canvas
>> representation gets clicked then DOM element gets clicked too so the
>> assistive technology gets working a11y for free. The converse is true.
>> If the assistive technology invokes an action on DOM element then its
>> canvas representation gets clicked too and all visual stuff just works.
>>
>> For me it seems like we have a piece of technology that provides a bunch
>> of good accessibility features including the setting of accessible
>> boundaries and it's quite tempting to prototype it. What concerns to
>> ability of drawFocusIfNeeded to define boundaries then having hit
>> regions this ability rather complicates the things.
>>
>
> The hit regions seem quite complex to implement for browsers
>

not at all, I bet it shouldn't take longer than few/several days to
implement that in Firefox.


> and for authors to implement.
>

I would disagree here too. Hit regions complexity is same as
drawFocusIfNeeded one but it brings bunch of automation stuff like having
no hit regions the author have to propagate events from canvas to element
and vise versa and it must harder than doing the hit regions.


> Most probably won't bother.
>

True but that's a different story. If we had a prototype in Firefox then
people would probably change their minds.

We can revisit hit regions later since we can define that having a hit
> region means that drawFocusIfNeeded should not update the a11y region.
>

yes, that's always an option, however that's not how backward compatibility
works: if something was implemented and adopted then it stays for years,
event if it was removed form the spec (or deprecated)


> Doing the trick with focus rings is a bit strange, but in the vast
> majority of cases, it will do what you expect.
>
> Chrome is on board with the current approach (since it is their
> implementation), as is IE.
>

I didn't hear back from IE. I'm quite curious to know what they think about
hit regions and drawFocusIfNeeded used to set accessible boundaries.


> If you accept our API, we will have interop between 3 browsers
> (It's on my to-do list to contact the webkit team but I didn't have the
> chance to do that yet)
>
> 1: http://www.w3.org/2013/09/accessible_canvas_clock.html
>
>
>