RE: FW: update to at risk features in Canvas

Hi Dominic,

Now that we both implemented it, we can see how the spec could be improved.
My biggest concerns are:
- the naming is very confusing
- the spec doesn't mention that accessibility features should be notified
- the hight contrast focus ring should be optional. I can't see anywhere in Firefox where uses anything but the default focus ring.

How about we rename it to: 
  boolean needsFocusRing(element)
  drawFocusRing(element)

Both APIs would notify the a11y software about the region.
needsFocusRing would tell the author that he needs to draw a focus ring. drawFocusRing would draw the browser's focus ring.
Since we're heading back to LC and these are not major changes, this should be OK. The a11y would have to tell me that this is an OK change.

If not, I see no choice but to keep the spec as-is and leave the feature as at-risk.

As for Path, the current spec text is simply wrong and not implementable. The API that WebKit implemented is not even in the spec but Dirk and I felt it was useful.
We can't really add that to the spec at this point though, even if we go back to LC since this is a big change.

________________________________________
From: dmazzoni@google.com [dmazzoni@google.com] On Behalf Of Dominic Mazzoni [dmazzoni@chromium.org]
Sent: Sunday, September 29, 2013 3:36 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

> 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, 30 September 2013 03:55:29 UTC