On Fri, Jan 10, 2014 at 9:24 AM, Jay Munro <jaymunro@microsoft.com> wrote:
> >> 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.
>
that's correct; the drawing of the ring is subject to clipping. The region
for a11y is NOT clipped though.
>
>
> *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> 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.
>
>
>