Re: hit regions and a11y geometrics

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? 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)


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


> 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 and for
authors to implement. Most probably won't bother.
We can revisit hit regions later since we can define that having a hit
region means that drawFocusIfNeeded should not update the a11y region.

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