On Thu, Jan 9, 2014 at 3:24 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
> On Fri, Jan 10, 2014 at 11:53 AM, Jatinder Mann <jmann@microsoft.com>wrote:
>
>> Just to get other ideas out there, Dominic mentioned notifyFocus() as a
>> potential name? notifyFocusRegion may be a bit more clear. The API is
>> notifying the path that should be focused to the accessibility tools and
>> user agent. Drawing may be a side effect of the UA being informed of the
>> path.
>>
>
>>
>> That has the same problem as drawFocusIfNeeded: if the element can't
> ever be focused, an author who doesn't care about accessibility may decide
> not to call it. drawApplicableFocus has the same problem. In fact I don't
> think *any* name can solve that problem, because the method just doesn't do
> anything useful for such authors when applied to non-focusable elements.
>
> Then again, this only applies to authors who already care enough about
> accessibility to provide fallback content. Why would an author do that and
> then neglect to make it useful? So I don't think we should worry about
> non-accessibility-caring authors in this context. So drawFocusIfNeeded
> should be as good as anything. Otherwise, how about we put the
> accessibility function front and center and call it
> "setAccessibilityRegionAndDrawFocusIfNeeded"?
>
what's always been very confusing, is that this function combines drawing
focus, with setting the accessibility region.
Maybe we should rethink the function and split it up:
setAccessibilityRegion -> associates the current path and the element for
a11y
drawFocus -> draws a focus ring around the current path. It's trivial to
check if the element is focused.