Re: FW: update to at risk features in Canvas

>
> > Is that exactly what the current spec says it should do?
> Yes, come to think of it, the "high contrast focus ring" is probably the
> rectangle that is drawn by the operating system's accessibility's
> subsystem. Can someone from the a11y team confirm that that is the intent?
>

Practically speaking, though, in every configuration I'm aware of,
assistive technology that draws a focus ring always draws an additional
focus ring that's over top of, or around, the application's focus ring.
It's used for two purposes: to draw attention to the focused object for
users with low vision, and to make it possible to place accessible focus on
objects that aren't normally focusable (like static text). But I'm not
aware of any scenario in which the application doesn't draw its focus ring
because the operating system or assistive technology is going to.

Yes, Windows has options for high contrast mode and for focus ring width,
but those both seem like flags that should affect drawSystemFocusRing, not
flags that should affect drawCustomFocusRing.

Anyway, I don't really understand the argument that we should stick with
drawCustomFocusRing because it's been in the spec for a long time and
consensus has been built up around it. From my perspective, no browser has
implemented it yet (until now, and Chrome has only implemented it behind a
flag), and there are plenty of concerns. Even Rich agrees that it wasn't
what he really wanted, it was just a compromise.

This is the perfect time to fix it - before anyone has shipped it.

Finally, just to be clear, just because we implemented it in Chrome doesn't
mean we're necessarily going to ship it. I'd really like to ship
drawSystemFocusRing but I'm not really inclined to recommend shipping
drawCustomFocusRing as-is, whether it makes the spec or not. I think it
should be changed or renamed.

Can anyone tell me more about the status of the Path object? I really liked
the idea of associating a Path object with an element in fallback content.
That would provide both hit testing and accessible bounds at the same time,
completely eliminating the need for drawCustomFocusRing. I understand it's
at-risk now, but I'd like to better understand why, and how far off we
might be from making progress there.

- Dominic