Reassigning to Canvas 2D Context Level 2 since drawSystemFocusRing and drawCustomFocusRing are at risk for CR.

Like any error condition, if someone tries to draw focus ring on something that does not have focus then it should not draw the ring. I don't see the issue. That is how it should operate.


This statement makes no sense: 

"If the element is in focus, it won't be drawn if the user hasn't requested a particular focus ring (and the element doesn't usually have a focus ring for drawSystemFocusRing)" 

All the platforms I have used have a default focus ring style. It is also a WCAG requirement that the user draw visual focus. WCAG2 is also being applied to software in the new 508 refresh so if the OS does not provide for this then the OS platform will have problems.

I think the name is fine as it is consistent with platform accessibility APIs. A name change is also not justification for pushing low vision access to L2.

The spec says "or if the element would have a focus ring drawn around it", which implies that not all elements have a default focus ring.

My point related to the naming is that, at best, it is a quest to draw a focus ring but the specification doesn't guarantee that a focus ring will be drawn even if the element is in focus and a descendant of the context. At least, that's how I read the spec.

Given that, some are questioning the naming of the method.

I don't interpret it that way. At best we are talking about an editorial change.

You may not interpret that way but,as far as I can tell, my interpretation of the specification reflects what was implemented.

If you focus on a p element and then call drawSystemFocusRing on it, you won't get a focus ring:
 http://w3c-test.org/web-platform-tests/submissions/457/2dcontext/drawing-paths-to-the-canvas/drawSystemFocusRing_005.html
(this test fails on Firefox Nightly and Chrome Canary)

I jumped the gun on moving to L2, there are still ongoing discussions on the focus ring methods. Moving back to CR.

The focus ring is a hold over from platform accessibility apis that is something that people who work in accessibility are familiar with on Windows. This is why Microsoft and others who wrote the original proposal chose this name. I don't think the name should be something that holds us up. Perhaps simply calling the API drawSystemFocus() and drawCustomFocus()? This gets us away with being tied down to any particular path appearance.

I should note that Microsoft wanted to convert the path to a rectangle as it was consistent with how focus "rings" were drawn in Windows.

As a side comment, 
http://w3c-test.org/web-platform-tests/submissions/457/2dcontext/drawing-paths-to-the-canvas/drawSystemFocusRing_005.html
was incorrect since it didn't have a tabindex. It's now fixed and works properly.

Initial title: 
drawSystemFocusRing and drawCustomFocusRing are poorly named

Per A11y/Canvas group, we'll keep drawSystemFocusRing name the same. drawCustomFocusRing will be worked on in Canvas Context 2D Level 2. 

Changing title to:
drawCustomFocusRing is poorly named

I'm fine with the resolution btw and having this bug closed or moved to L2.

I would like to talk about this bug some more in next Monday's Canvas Accessibility Sub Group meeting. I think we should consider updating the name of drawSystemFocusRing in the L1 spec to make the feature more clear to web developers. I personally don't think fixing the name should mean that we need to push this API out to the L2 spec; its quite reasonable to update the name in the L1 spec, especially if we will likely be going to Last Call anyway. Just because some old Win32 API is using this sort of name doesn't mean we should confuse web developers and impact the adoption of this API.

I don't like the use of "System" because it sounds like we are using the OS focus, whereas we really mean User Agent focus. E.g., On Windows Chrome uses a orange focus which is different from the system dotted focus. I rather we just remove the word "System" for this method. The "Custom" version should keep the word "Custom" because it is a custom focus that the web developer draws.

I don't like the use of "Ring". You can use the Canvas API to draw any path, not just a ring. We can drop "Ring" and go with "Region", "Path", or nothing at all.  

I don't particularly like the use of "draw" as we only draw if the area is focused. Other draw calls like "drawImage" always draw once the call is made. I can see that "set" may be confusing as it may appear that we are setting the focus, not the user. Since it may be the least confusing, I think we should leave "draw" in.

How does "drawFocus" instead of "drawSystemFocusRing" and "drawCustomFocus" instead of "drawCustomFocusRing" sound? I know naming may sound like a minor thing, but if we are spending the time to fix the defects in this API, we might as well get the name right.

Bringing the bug back to HTML5 CR as there is an ongoing discussion on fixing this issue.

Proposed resolution is to change drawSystemFocusRing to drawFocusIfNeeded

drawSystemFocusRing has been renamed to drawFocusIfNeeded.

As per Canvas SubGroup discussion, we have agreed upon the drawFocusIfNeeded name, http://www.w3.org/2014/01/20-html-a11y-minutes.html. The spec has been updated to reflect that change.