Re: drawSystemFocusRing and drawCustomFocusRing names are confusing.

On Thu, Jan 9, 2014 at 3:57 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> Idea 1: How about if we just get rid of the logic that skips drawing if
> it's not focused? Then we could have 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.
>
> Idea 2: Create a single API called setElementFocusPath that only needs to
> be called once (if the path doesn't change), and the browser then takes
> over drawing the focused path around that element ever time that element
> gets focus, and clearing it when it loses focus. It would have to do that
> in a separate overlay. This is much closer to what Ryosuke was proposing on
> webkit-dev.
>

I really like idea 2 except that it's completely different from anything
we've discussed so far.
It accomplishes focus drawing by the browser and figuring out the
accessible region.


> 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"?
>>
>>
>> Rob
>> --
>> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
>> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
>> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
>> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
>> waanndt  wyeonut  thoo mken.o w
>>
>
>

Received on Friday, 10 January 2014 00:18:43 UTC