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.