Quick update on focus rings (was: update to at risk features in Canvas)

All,

Dominic and I have been discussing this some more. As you might know, focus rings are implemented behind a flag in Chrome and are about to land behind a flag in Firefox.
At this point, we have 2 issues:
1. high contrast focus rings. The spec calls these out but according to Dominic, this is not needed (see below). Chrome and Firefox don't have these high contrast rings under other circumstance so why does canvas have this text?
2. scrolling the page to the focus ring region. For 'regular' elements, the browser will scroll the page so the focused element is in the view. The canvas spec doesn't call this out, so if a canvas region gets the focus, the page isn't scrolled. You can try this with Dominic example. I think this was an oversight in the spec...

Rich is still on vacation so we have to wait for his guidance (unless someone else remembers the decisions?)

Rik
________________________________________
From: Dominic Mazzoni [dmazzoni@google.com]
Sent: Sunday, September 29, 2013 4:17 PM
To: Rik Cabanier
Cc: Michael[tm] Smith; mark@w3.org; schwer@us.ibm.com; dbolter@mozilla.com; franko@microsoft.com; public-html-a11y@w3.org; janina@rednote.net
Subject: Re: FW: update to at risk features in Canvas

On Sun, Sep 29, 2013 at 12:23 PM, Rik Cabanier <cabanier@adobe.com<mailto:cabanier@adobe.com>> wrote:
> 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

Received on Monday, 7 October 2013 03:16:59 UTC