On Thu, Jan 14, 2010 at 8:37 AM, Dominic Mazzoni <dmazz...@google.com> wrote:
> On Thu, Jan 14, 2010 at 8:19 AM, Nico Weber <tha...@google.com> wrote:
>> It probably depends if you want to use this for text input or "action"
>> inputs. A text-to-speech extension would probably want to set unicode
>> characters, while something that (say) hits cmd-f to open the find bar
>> probably wants to use keycodes.
>
> Text-to-speech is a different problem; this is for actions.
>
>> For example, on OS X hitting cmd-"f" with a hiragana keyboard layout
>> opens the findbar, while just pressing "f" opens an IME.
>>
>> If you want to use this for actons, I would find it more useful to
>> have a "performUiAction()" function instead though, since keyboard
>> shortcuts are different across platforms (all mac shortcuts use cmd
>> instead of ctrl for example, and the letters for a few shortcuts are
>> different on OS X too for various reasons).
>
> I completely agree; I would like to add many functions along the lines
> of performUiAction. However, there are a few actions for which typing
> a key really is the right thing to do - for example pressing Tab to
> move to the next control.

Maybe performUiAction('focusNextViewInKeyLoop')?

(By the way, OS X has a system-level setting that configures if tab
should focus only text fields or all controls such as buttons etc. I
don't think Chrome/Mac honors it, but I think there are plans to
support it. Stuff like this is surprising for a caller that sends
"tab" characters, while an explicit "focus next element" function
could have clearly defined semantics).

>
> There's also testing. This function will allow you to use only
> javascript to test that a particular capability can be accessed using
> only the keyboard. I'm already using this for testing this API, by
> simulating pressing Ctrl+L to focus the location bar and then checking
> to see that the proper focus event is generated.

Some (most?) accessibility shortcuts will vary by platform too. For
example, "focus toolbar" is ctrl-f5 on OS X, but only if full keyboard
access has been enabled (ctrl-f1). Cocoa the OS X framework don't
always trigger with synthetic keyboard events. (I'm not an a11y expert
– Avi, comments?)

>
> So the way I look at it is: there are some great uses for this
> function. There are also things that this function could be used for
> but there'd be a better way. It could also be abused to do things that
> make no sense.
>
> I don't think that's an argument not to allow the function; I think it
> just means we should make sure it's defined properly for the intended
> use, and over time try to provide better alternatives for other
> possible uses.
>
> - Dominic
>
>> Nico
>>
>> On Thu, Jan 14, 2010 at 7:26 AM, Dominic Mazzoni <dmazz...@google.com> wrote:
>>> Hi Darin,
>>>
>>> Erik suggested you might have some thoughts. In my proposed extension
>>> api for accessibility (http://codereview.chromium.org/402099) one of
>>> the functions is to simulate a key press. How should the client
>>> express the key they would like to press?  The current proposed
>>> function prototype is:
>>>
>>>      {
>>>        "name": "simulateKeyPress",
>>>        "type": "function",
>>>        "description": "Simulate pressing a key.",
>>>        "parameters": [
>>>          {
>>>            "type": "object",
>>>            "name": "keyInfo",
>>>            "properties": {
>>>              "key": {"type": "integer", "description": "The code of
>>> the key to press, corresponding to event.keyCode."},
>>>              "control": {"type": "boolean", "optional": true,
>>> "description": "True if the control key is down."},
>>>              "shift": {"type": "boolean", "optional": true,
>>> "description": "True if the shift key is down."},
>>>              "alt": {"type": "boolean", "optional": true,
>>> "description": "True if the alt key is down."}
>>>            }
>>>          }
>>>        ]
>>>      }
>>>
>>> What do you think?  Should the key be a keyCode? A charCode?
>>>
>>> Should it be cross-platform, or should it match what would be returned
>>> by an onKeyDown handler? Are those even mutually exclusive?
>>>
>>> My current thinking is: the symmetry of using the same key codes
>>> returned by onKeyDown is appealing. Also, even though there are some
>>> differences, the most common keys needed to automate the UI (tab,
>>> enter, arrows, alphanumerics) are already consistent across platforms.
>>>
>>> Thanks,
>>> - Dominic
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>    http://groups.google.com/group/chromium-dev
>>>
>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev

Reply via email to