>> I meant, what if the control is right at the edge of the canvas. Maybe the default focus ring doesn't extend beyond it, but a thicker, higher-contrast focus ring would extend outside the bounds of the canvas - so it'd be clipped.
As a side note, the spec does say that focus rings ”should be subject to the clipping region.” I’d read that to be that if the focus ring goes out of the clipping region it’s clipped.
From: Dominic Mazzoni [mailto:dmazzoni@google.com]
Sent: Thursday, January 9, 2014 11:56 PM
To: Rik Cabanier
Cc: Robert O'Callahan; Jatinder Mann; Richard Schwerdtfeger; Rik Cabanier (cabanier@adobe.com); Jay Munro; Philippe Le Hegaret (plh@w3.org); Canvas; Alexander Surkov
Subject: Re: drawSystemFocusRing and drawCustomFocusRing names are confusing.
On Thu, Jan 9, 2014 at 11:45 PM, Rik Cabanier <cabanier@gmail.com<mailto:cabanier@gmail.com>> wrote:
I wonder if there aren't just as many plausible use cases where the focus ring would naturally extend outside of the canvas bounds, and it'd be unnatural and annoying for the author to enlarge the canvas just for focus rings.
Why would you need to enlarge the canvas? The a11y region for the focus ring can fall outside the canvas but nothing needs to be drawn there.
If the author has a control that's outside the canvas, he probably is "faking" the scrollbars too so you can scroll it into view
I meant, what if the control is right at the edge of the canvas. Maybe the default focus ring doesn't extend beyond it, but a thicker, higher-contrast focus ring would extend outside the bounds of the canvas - so it'd be clipped.
Oh well, I can see the concerns with this approach. If we stick with the idea that it has to be painted within the canvas. Back to my idea #1:
* drawFocus that's clear and does exactly what it says, but it wouldn't improve accessibility of controls when they're not focused. We could also have setFocusPath that never draws anything but notifies the system what path is highlighted when an element has focus, to complement it.
To clarify, whenever a control is focused, calling drawFocus would update its accessible focus path and notify screen magnifiers appropriately. This would handle most common cases just fine - it'd be far better for accessibility than nothing. The only thing it wouldn't do is expose the accessible focus path for elements that aren't currently focused.