Should accesskey focus or click?

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Should accesskey focus or click?

Aaron Leventhal-3
Old discussion:

Right now accesskey acts like a click. However, this is potentially
dangerous because some buttons with an accesskey could trigger something
the user doesn't want and had not reviewed before accidentally
triggering the accesskey. For example this could cause an unwanted
online purchase.

On the other hand this is consistent with the desktop and what the web
does today?

The question comes up because of Javascript widgets made out of
divs/spans etc. It seems that Javascript widgets should support
accesskey as well.

What should we do?
1) Make all widgets focus on accesskey (change current behavior and be
inconsistent with IE and the desktop, but be safer)
2) Just make Javascript widgets focus and keep all old widgets the same
(inconsistent and doesn't support elements that are not focusable).
3) Forget the so-called safety issue and just make accesskey perform a
click as it does now, so that we're consistent.

Opinions?

- Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Marco Zehe-3
Hi Aaron,

oh yes, that's a much debated topic. here are my 2 cents:

Aaron Leventhal wrote:
> 1) Make all widgets focus on accesskey (change current behavior and be
> inconsistent with IE and the desktop, but be safer)

I'd vote for this option. For one, we already do things differently in
that we require the use of Alt and Shift keys for accesskeys. IE uses
the Alt modifier only, creating all sorts of conflicts between access
keys on web pages and their menu system.

Secondly, for screen reader users, the behavior is inconsistent anyway
as it is currently: On simple clickable items such as buttons or links,
the click is performed immediately, but when focusing textboxes, one has
to press ENTER to go into Forms Mode. Always focusing, but requiring the
user to explicitly invoking the element would introduce more consistency.

Third, I don't know about others, but on the desktop, I hardly use
dialogs often enough to remember those Alt shortcut mnemonics. I know
from past experience that this is being advertised to give keyboard
users the same speed as mouse users, press a single key combination, and
you activate an element far away from where the focus currently is. But
honestly, who remembers the keys for many dialogs to actually take
advantage of this?

And fourth, isn't Firefox the safer browser? Why shouldn't we be safer
in this regard as well by requiring the user to take explicit action
once the element is focused?

Marco
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Victor Tsaran
In reply to this post by Aaron Leventhal-3
Hi Aaron,

Aaron Leventhal wrote:
> Old discussion:
>
> Right now accesskey acts like a click. However, this is potentially
> dangerous because some buttons with an accesskey could trigger something
> the user doesn't want and had not reviewed before accidentally
> triggering the accesskey. For example this could cause an unwanted
> online purchase.

Good point, however, before users use an access key, they will have
discovered it by then and thus probably know the result of an action
that happens next. In other words, pressing an access key is most likely
not an accidental activity.

>
> On the other hand this is consistent with the desktop and what the web
> does today?

Well, desktop apps do not use hyperlinks, only buttons. IE, for example,
will place a cursor on a link, but will activate a button.


>
> The question comes up because of Javascript widgets made out of
> divs/spans etc. It seems that Javascript widgets should support
> accesskey as well.

Absolutely. An equivalent of an accesskey or, better yet, of an
accShortcutKey should be available. It would be great to have a
parameter that defines the behavior of such a shortcut key, similar to
how live regions work (override/do not override etc).

>
> What should we do?
> 1) Make all widgets focus on accesskey (change current behavior and be
> inconsistent with IE and the desktop, but be safer)

I would probably vote for simply placing a focus on an element. After
all, we are talking about access key. :)
> 2) Just make Javascript widgets focus and keep all old widgets the same
> (inconsistent and doesn't support elements that are not focusable).
> 3) Forget the so-called safety issue and just make accesskey perform a
> click as it does now, so that we're consistent.
>
> Opinions?
>
> - Aaron
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Al Gilman
In reply to this post by Marco Zehe-3

On 4 Mar 2008, at 4:14 PM, Marco Zehe wrote:

> Hi Aaron,
>
> oh yes, that's a much debated topic. here are my 2 cents:
>
> Aaron Leventhal wrote:
>> 1) Make all widgets focus on accesskey (change current behavior  
>> and be
>> inconsistent with IE and the desktop, but be safer)
>
> I'd vote for this option.

The 'access' module proposal about to come from the XHTML2 Working
Group has a binary { activate | don't activate } option embedded in
it as well as the suggested mnemonic key.  This puts both the event  
and the action in the DOM where a client can edit them, in effect re-
binding the
hotkey to another input event or softening a doIt action to a  
focusAndTellMe
action or vice versa.

The argument is more that the sighted but high-cost-of-input-symbol
user can see the effect of firing the hot-keyed element before doing
the shortcut action, while the screen reader user has to navigate there
to be told.

Maybe the mouth stick on the iPhone will make this all obsolete,
but there are some users who labor over each keystroke equivalent
and it matters to reduce them.

IIRC.

Chaals, that is to say Charles McCathieNevile feels that the
existing accesskey syntax in HTML can be re-semanticized to allow
for browser re-mapping of user actions and system actions.  I
haven't see an exact proposal.  But the scripted widgets could
(here I go again, Aaron...) consider firing-and-handling suitably
abstract events, such as an 'access' event, that gets handled
in the context of user preferences.

I don't know how much of this architecture today's scripted widgets
can emulate or anticipate.

But there is strong desire in the Mobile space still to be able
to re-bind user events, even on the fly during the middle of a
task, and varying between focus and fire is not out of the question
once we get that set up.

My votes would be for (a) focus, with a user preference allowed
to migrate the behavior to click or (b) just focus (for now).

Al

> For one, we already do things differently in
> that we require the use of Alt and Shift keys for accesskeys. IE uses
> the Alt modifier only, creating all sorts of conflicts between access
> keys on web pages and their menu system.
>
> Secondly, for screen reader users, the behavior is inconsistent anyway
> as it is currently: On simple clickable items such as buttons or  
> links,
> the click is performed immediately, but when focusing textboxes,  
> one has
> to press ENTER to go into Forms Mode. Always focusing, but  
> requiring the
> user to explicitly invoking the element would introduce more  
> consistency.
>
> Third, I don't know about others, but on the desktop, I hardly use
> dialogs often enough to remember those Alt shortcut mnemonics. I know
> from past experience that this is being advertised to give keyboard
> users the same speed as mouse users, press a single key  
> combination, and
> you activate an element far away from where the focus currently is.  
> But
> honestly, who remembers the keys for many dialogs to actually take
> advantage of this?
>
> And fourth, isn't Firefox the safer browser? Why shouldn't we be safer
> in this regard as well by requiring the user to take explicit action
> once the element is focused?
>
> Marco
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Michael Curran
Hi,

I totally agree. Its much two dangerous for something to happen when
pressing an access key. I also voat for a focus move. However, there are
many "accessibility" sites that use access keys to execute particular
functions such as speaking messages, or playing audio etc. I'd like to
be sure that this functionality wouldn't break... so meaning that in
javascript, the developer could explicitly specify that the key was to
perform a particular action, not just focus the widget. However, with
knowledge lacking in javascript, I have no idea if access keys and key
bindings to functions are separate from each other.

Mick

Al Gilman wrote:

> On 4 Mar 2008, at 4:14 PM, Marco Zehe wrote:
>
>> Hi Aaron,
>>
>> oh yes, that's a much debated topic. here are my 2 cents:
>>
>> Aaron Leventhal wrote:
>>> 1) Make all widgets focus on accesskey (change current behavior
>>> and be
>>> inconsistent with IE and the desktop, but be safer)
>> I'd vote for this option.
>
> The 'access' module proposal about to come from the XHTML2 Working
> Group has a binary { activate | don't activate } option embedded in
> it as well as the suggested mnemonic key.  This puts both the event
> and the action in the DOM where a client can edit them, in effect re-
> binding the
> hotkey to another input event or softening a doIt action to a
> focusAndTellMe
> action or vice versa.
>
> The argument is more that the sighted but high-cost-of-input-symbol
> user can see the effect of firing the hot-keyed element before doing
> the shortcut action, while the screen reader user has to navigate there
> to be told.
>
> Maybe the mouth stick on the iPhone will make this all obsolete,
> but there are some users who labor over each keystroke equivalent
> and it matters to reduce them.
>
> IIRC.
>
> Chaals, that is to say Charles McCathieNevile feels that the
> existing accesskey syntax in HTML can be re-semanticized to allow
> for browser re-mapping of user actions and system actions.  I
> haven't see an exact proposal.  But the scripted widgets could
> (here I go again, Aaron...) consider firing-and-handling suitably
> abstract events, such as an 'access' event, that gets handled
> in the context of user preferences.
>
> I don't know how much of this architecture today's scripted widgets
> can emulate or anticipate.
>
> But there is strong desire in the Mobile space still to be able
> to re-bind user events, even on the fly during the middle of a
> task, and varying between focus and fire is not out of the question
> once we get that set up.
>
> My votes would be for (a) focus, with a user preference allowed
> to migrate the behavior to click or (b) just focus (for now).
>
> Al
>
>> For one, we already do things differently in
>> that we require the use of Alt and Shift keys for accesskeys. IE uses
>> the Alt modifier only, creating all sorts of conflicts between access
>> keys on web pages and their menu system.
>>
>> Secondly, for screen reader users, the behavior is inconsistent anyway
>> as it is currently: On simple clickable items such as buttons or
>> links,
>> the click is performed immediately, but when focusing textboxes,
>> one has
>> to press ENTER to go into Forms Mode. Always focusing, but
>> requiring the
>> user to explicitly invoking the element would introduce more
>> consistency.
>>
>> Third, I don't know about others, but on the desktop, I hardly use
>> dialogs often enough to remember those Alt shortcut mnemonics. I know
>> from past experience that this is being advertised to give keyboard
>> users the same speed as mouse users, press a single key
>> combination, and
>> you activate an element far away from where the focus currently is.
>> But
>> honestly, who remembers the keys for many dialogs to actually take
>> advantage of this?
>>
>> And fourth, isn't Firefox the safer browser? Why shouldn't we be safer
>> in this regard as well by requiring the user to take explicit action
>> once the element is focused?
>>
>> Marco
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Charles McCathieNevile-2
In reply to this post by Victor Tsaran
On Wed, 05 Mar 2008 07:33:59 +0900, Victor Tsaran <[hidden email]>  
wrote:

> Hi Aaron,
>
> Aaron Leventhal wrote:
>> Old discussion:
>>
>> Right now accesskey acts like a click. However, this is potentially
>> dangerous because some buttons with an accesskey could trigger something
>> the user doesn't want and had not reviewed before accidentally
>> triggering the accesskey. For example this could cause an unwanted
>> online purchase.
>
> Good point, however, before users use an access key, they will have
> discovered it by then and thus probably know the result of an action
> that happens next. In other words, pressing an access key is most likely
> not an accidental activity.

Modulo the IE implementation, and similar patterns where accesskey  
overrides a standard UI action. Hopefully that will soon be a thing of the  
past.

>> On the other hand this is consistent with the desktop and what the web
>> does today?
>
> Well, desktop apps do not use hyperlinks, only buttons. IE, for example,
> will place a cursor on a link, but will activate a button.

Opera (which shows you the access keys before you activate them, and  
doesn't let them interfere with any other function) will activate things  
where possible. I suspect that is actually the optimum - but if you don't  
have the discovery mechanism, then you need to go back to focus. (This is  
a simple answer - there are complicating situations like what to do when  
two different controls in the page have been assigned the same access key).

>> The question comes up because of Javascript widgets made out of
>> divs/spans etc. It seems that Javascript widgets should support
>> accesskey as well.
>
> Absolutely. An equivalent of an accesskey or, better yet, of an
> accShortcutKey should be available. It would be great to have a
> parameter that defines the behavior of such a shortcut key, similar to
> how live regions work (override/do not override etc).
>
>>
>> What should we do?
>> 1) Make all widgets focus on accesskey (change current behavior and be
>> inconsistent with IE and the desktop, but be safer)
>
> I would probably vote for simply placing a focus on an element. After
> all, we are talking about access key. :)

I think the safety position is to do this. If the user knows what will  
happen before they get through the process of activation, it is very  
helpful for some people not to have to go through the extra hoop of  
activation.

>> 2) Just make Javascript widgets focus and keep all old widgets the same
>> (inconsistent and doesn't support elements that are not focusable).

Across browsers it is going to be inconsistent anyway. If you don't have  
discovery, you have to go for safety and therefore not click, but ideally  
in most cases I think you would click. Which means implementing discovery  
(and ensuring the activation doesn't override an existing UI function).

>> 3) Forget the so-called safety issue and just make accesskey perform a
>> click as it does now, so that we're consistent.

By the way, there is a proposal from me for this in the HTML list archives  
 from a few months ago, although I am offline now and don't have a  
reference. It was meant to be a complete proposal for spec langauge, and  
is accompanied by a message about implementation techniques.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Al Gilman

On 4 Mar 2008, at 9:02 PM, Charles McCathieNevile wrote:


> By the way, there is a proposal from me for this in the HTML list  
> archives
>  from a few months ago,

.. as in
http://lists.w3.org/Archives/Public/public-html/2007Jul/ 
thread.html#msg185

> On Wed, 05 Mar 2008 07:33:59 +0900, Victor Tsaran <[hidden email]>
> wrote:
>
>> Hi Aaron,
>>
>> Aaron Leventhal wrote:
>>> Old discussion:
>>>
>>> Right now accesskey acts like a click. However, this is potentially
>>> dangerous because some buttons with an accesskey could trigger  
>>> something
>>> the user doesn't want and had not reviewed before accidentally
>>> triggering the accesskey. For example this could cause an unwanted
>>> online purchase.
>>
>> Good point, however, before users use an access key, they will have
>> discovered it by then and thus probably know the result of an action
>> that happens next. In other words, pressing an access key is most  
>> likely
>> not an accidental activity.
>
> Modulo the IE implementation, and similar patterns where accesskey
> overrides a standard UI action. Hopefully that will soon be a thing  
> of the
> past.
>
>>> On the other hand this is consistent with the desktop and what  
>>> the web
>>> does today?
>>
>> Well, desktop apps do not use hyperlinks, only buttons. IE, for  
>> example,
>> will place a cursor on a link, but will activate a button.
>
> Opera (which shows you the access keys before you activate them, and
> doesn't let them interfere with any other function) will activate  
> things
> where possible. I suspect that is actually the optimum - but if you  
> don't
> have the discovery mechanism, then you need to go back to focus.  
> (This is
> a simple answer - there are complicating situations like what to do  
> when
> two different controls in the page have been assigned the same  
> access key).
>
>>> The question comes up because of Javascript widgets made out of
>>> divs/spans etc. It seems that Javascript widgets should support
>>> accesskey as well.
>>
>> Absolutely. An equivalent of an accesskey or, better yet, of an
>> accShortcutKey should be available. It would be great to have a
>> parameter that defines the behavior of such a shortcut key,  
>> similar to
>> how live regions work (override/do not override etc).
>>
>>>
>>> What should we do?
>>> 1) Make all widgets focus on accesskey (change current behavior  
>>> and be
>>> inconsistent with IE and the desktop, but be safer)
>>
>> I would probably vote for simply placing a focus on an element. After
>> all, we are talking about access key. :)
>
> I think the safety position is to do this. If the user knows what will
> happen before they get through the process of activation, it is very
> helpful for some people not to have to go through the extra hoop of
> activation.
>
>>> 2) Just make Javascript widgets focus and keep all old widgets  
>>> the same
>>> (inconsistent and doesn't support elements that are not focusable).
>
> Across browsers it is going to be inconsistent anyway. If you don't  
> have
> discovery, you have to go for safety and therefore not click, but  
> ideally
> in most cases I think you would click. Which means implementing  
> discovery
> (and ensuring the activation doesn't override an existing UI  
> function).
>
>>> 3) Forget the so-called safety issue and just make accesskey  
>>> perform a
>>> click as it does now, so that we're consistent.
>
> By the way, there is a proposal from me for this in the HTML list  
> archives
>  from a few months ago, although I am offline now and don't have a
> reference. It was meant to be a complete proposal for spec  
> langauge, and
> is accompanied by a message about implementation techniques.
>
> cheers
>
> Chaals
>
> --
> Charles McCathieNevile  Opera Software, Standards Group
>      je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Jason White-14
In reply to this post by Charles McCathieNevile-2
On Wed, Mar 05, 2008 at 11:02:02AM +0900, Charles McCathieNevile wrote:
 
> Opera (which shows you the access keys before you activate them, and  
> doesn't let them interfere with any other function) will activate things  
> where possible. I suspect that is actually the optimum - but if you don't  
> have the discovery mechanism, then you need to go back to focus. (This is  
> a simple answer - there are complicating situations like what to do when  
> two different controls in the page have been assigned the same access key).

I concur with Charles. Not providing a discovery mechanism would also be a
major design error, since without it, the presence of the access keys cannot
be unintrusively discovered without reading the source.
 
> I think the safety position is to do this. If the user knows what will  
> happen before they get through the process of activation, it is very  
> helpful for some people not to have to go through the extra hoop of  
> activation.

Correct. For those of us who are fast typists this is largely a matter of
efficiency, although the annoyance factor of having to give confirmation each
time shouldn't be underestimated; but for those who are not using a keyboard,
or for whom typing is slow and awkward, the extra keystrokes can surely be
more than a minor inconvenience.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Jason White-14
In reply to this post by Charles McCathieNevile-2
I forgot to add that there also needs to be agreement on the handling of
special cases, such as duplicate access key definitions in a document as
Charles mentioned.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

mozilla accessibility
In reply to this post by Marco Zehe-3
Ie (with Jaws anyhow) will focus if the target is a link, and click if the
target is a button.

It would be nice to be able to configure this on the fly.

It would also be extremely nice to be able to discover access keys without
having to stumble on them; one keystroke to bring up a list of keys and
element text (or possibly text from a specific help or description specified
with the access key).

Just my two cents.
-- Rich

"Al Gilman" <[hidden email]> wrote in message
news:[hidden email]...

>
> On 4 Mar 2008, at 4:14 PM, Marco Zehe wrote:
>
>> Hi Aaron,
>>
>> oh yes, that's a much debated topic. here are my 2 cents:
>>
>> Aaron Leventhal wrote:
>>> 1) Make all widgets focus on accesskey (change current behavior  and be
>>> inconsistent with IE and the desktop, but be safer)
>>
>> I'd vote for this option.
>
> The 'access' module proposal about to come from the XHTML2 Working
> Group has a binary { activate | don't activate } option embedded in
> it as well as the suggested mnemonic key.  This puts both the event  and
> the action in the DOM where a client can edit them, in effect re- binding
> the
> hotkey to another input event or softening a doIt action to a
> focusAndTellMe
> action or vice versa.
>
> The argument is more that the sighted but high-cost-of-input-symbol
> user can see the effect of firing the hot-keyed element before doing
> the shortcut action, while the screen reader user has to navigate there
> to be told.
>
> Maybe the mouth stick on the iPhone will make this all obsolete,
> but there are some users who labor over each keystroke equivalent
> and it matters to reduce them.
>
> IIRC.
>
> Chaals, that is to say Charles McCathieNevile feels that the
> existing accesskey syntax in HTML can be re-semanticized to allow
> for browser re-mapping of user actions and system actions.  I
> haven't see an exact proposal.  But the scripted widgets could
> (here I go again, Aaron...) consider firing-and-handling suitably
> abstract events, such as an 'access' event, that gets handled
> in the context of user preferences.
>
> I don't know how much of this architecture today's scripted widgets
> can emulate or anticipate.
>
> But there is strong desire in the Mobile space still to be able
> to re-bind user events, even on the fly during the middle of a
> task, and varying between focus and fire is not out of the question
> once we get that set up.
>
> My votes would be for (a) focus, with a user preference allowed
> to migrate the behavior to click or (b) just focus (for now).
>
> Al
>
>> For one, we already do things differently in
>> that we require the use of Alt and Shift keys for accesskeys. IE uses
>> the Alt modifier only, creating all sorts of conflicts between access
>> keys on web pages and their menu system.
>>
>> Secondly, for screen reader users, the behavior is inconsistent anyway
>> as it is currently: On simple clickable items such as buttons or  links,
>> the click is performed immediately, but when focusing textboxes,  one has
>> to press ENTER to go into Forms Mode. Always focusing, but  requiring the
>> user to explicitly invoking the element would introduce more
>> consistency.
>>
>> Third, I don't know about others, but on the desktop, I hardly use
>> dialogs often enough to remember those Alt shortcut mnemonics. I know
>> from past experience that this is being advertised to give keyboard
>> users the same speed as mouse users, press a single key  combination, and
>> you activate an element far away from where the focus currently is.  But
>> honestly, who remembers the keys for many dialogs to actually take
>> advantage of this?
>>
>> And fourth, isn't Firefox the safer browser? Why shouldn't we be safer
>> in this regard as well by requiring the user to take explicit action
>> once the element is focused?
>>
>> Marco
>> _______________________________________________
>> dev-accessibility mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-accessibility
>


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Steve Lee-3
If we go for the 'safer' focus option then we need a standard way to
perform activation (or the default action) of a widget. Otherwise
users have to discover 2 things (also OSKs that generate synthetic key
events). Is that already covered with space or enter (say)?

I do think that the doubling of required key presses will be an real
annoyance for some, but not a necessarily a 'deal breaker'.

--
Steve Lee
--
Open Source Assistive Technology
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Gregory J. Rosmaita
aloha!

for what it is worth, the User Agent Accessibility Guidelines working
group at the W3C (http://www.w3.org/WAI/UA) believes that the choice
between onFocus when an access key is activated and onActivate when
an access key is activated should be the individual consumer's decision;
therefore, the onus is on UA developers to provide BOTH functionalities,
to clearly and prominently document which is the default, and to provide
a mechanism for toggling between "focus" or "activate" as well as a
re-binding mechanism for accelerator key modifiers...

like most UI options, the decision to move "focus" or to "activate"
an object with an accesskey on key-press, MUST remain the user's
decision, and not that of the implementor...

gregry.
--------------------------------------------------------------
CRITIC, n.  A person who boasts himself hard to please because
nobody tries to please him.
                     -- Ambrose Bierce, The Devil's Dictionary
--------------------------------------------------------------
Gregory J. Rosmaita: [hidden email]
   Oedipus' Online Complex: http://my.opera.com/oedipus/
      Camera Obscura: http://www.hicom.net/~oedipus/index.html
--------------------------------------------------------------


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

David hilbert Poehlman
Let's see if I've this right:
"author proposes? User disposes?"

----- Original Message -----
From: "Gregory J. Rosmaita" <[hidden email]>
To: <[hidden email]>
Sent: Thursday, March 06, 2008 10:57 AM
Subject: Re: Should accesskey focus or click?


aloha!

for what it is worth, the User Agent Accessibility Guidelines working
group at the W3C (http://www.w3.org/WAI/UA) believes that the choice
between onFocus when an access key is activated and onActivate when
an access key is activated should be the individual consumer's decision;
therefore, the onus is on UA developers to provide BOTH functionalities,
to clearly and prominently document which is the default, and to provide
a mechanism for toggling between "focus" or "activate" as well as a
re-binding mechanism for accelerator key modifiers...

like most UI options, the decision to move "focus" or to "activate"
an object with an accesskey on key-press, MUST remain the user's
decision, and not that of the implementor...

gregry.
--------------------------------------------------------------
CRITIC, n.  A person who boasts himself hard to please because
nobody tries to please him.
                     -- Ambrose Bierce, The Devil's Dictionary
--------------------------------------------------------------
Gregory J. Rosmaita: [hidden email]
   Oedipus' Online Complex: http://my.opera.com/oedipus/
      Camera Obscura: http://www.hicom.net/~oedipus/index.html
--------------------------------------------------------------


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Willie Walker
In reply to this post by Steve Lee-3
Hi All:

I've been following this topic mostly with the thought that end users
should be the ones to define the behavior, and was happy that end users
were engaged in the discussion.  Their word trumps most other things,
IMO.  :-)

My knowledge of accesskeys is somewhat limited, but I think about
accesskeys in the sense that they may be like mnemonics.  If this is the
case, I think the answer of "focus" or "click" (or "activate" instead of
"click") might depend upon the type of control in question and how many
things use the same mnemonic.

In the GTK+ toolkit world, I see this behavior:

* For things that are labelled by something and the mnemonic is in the
label -- the mnemonic gives focus to the object.  Typical examples
include editable text areas with labels, combo boxes, etc. If there is
more than one object with the same mnemonic, repeated presses of the
mnemonic cycle through the objects.

* For things that have a mnemonic on them, the mnemonic invokes the
default action of the object.  Typical examples include checkboxes,
buttons, etc.  In the event that there is more than one object with the
same mnemonic, giving focus is used instead of invoking the default
action and repeated presses of the mnemonic cycle through the objects.

Will

Steve Lee wrote:
> If we go for the 'safer' focus option then we need a standard way to
> perform activation (or the default action) of a widget. Otherwise
> users have to discover 2 things (also OSKs that generate synthetic key
> events). Is that already covered with space or enter (say)?
>
> I do think that the doubling of required key presses will be an real
> annoyance for some, but not a necessarily a 'deal breaker'.
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Tom Brunet
In reply to this post by Steve Lee-3
> a mechanism for toggling between "focus" or "activate" as well as a
> re-binding mechanism for accelerator key modifiers...

Just to throw an idea out there.  If you can control the binding of the
modifiers, you don't really need to support toggling, and it gives you
even more flexibility.  For example, I might bind Alt+Shift to the focus
behavior and Alt+Ctrl to the activate behavior.  If I only want the
focus behavior, I leave that unbound.  Now, how to build the settings in
such a way that it's easy for the user to discover and change...  that's
another discussion :)

Tom
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

mozilla accessibility
In reply to this post by Steve Lee-3
>Is that already covered with space or enter (say)?

Well, I sure hope so. That's rather standard behavior which most users have
come to expect.

-- Rich

----- Original Message -----
From: "Steve Lee" <[hidden email]>
To: "mozilla accessibility" <[hidden email]>
Cc: <[hidden email]>
Sent: Thursday, March 06, 2008 2:22 AM
Subject: Re: Should accesskey focus or click?


If we go for the 'safer' focus option then we need a standard way to
perform activation (or the default action) of a widget. Otherwise
users have to discover 2 things (also OSKs that generate synthetic key
events). Is that already covered with space or enter (say)?

I do think that the doubling of required key presses will be an real
annoyance for some, but not a necessarily a 'deal breaker'.

--
Steve Lee
--
Open Source Assistive Technology
www.fullmeasure.co.uk
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

mozilla accessibility
In reply to this post by Tom Brunet
Ya, user-definable key bindings is probably not in the plans for the near
future (someone correct me if I'm wrong). Seems like a lot of work.

Maybe the ability to bind keys from about:config would be useful, but most
users will not (or probably shouldn't) deal with about:config since you
could really hose things pretty badly.

-- Rich

----- Original Message -----
From: "Tom Brunet" <[hidden email]>
Newsgroups: mozilla.dev.accessibility
To: <[hidden email]>
Sent: Thursday, March 06, 2008 12:24 PM
Subject: Re: Should accesskey focus or click?


> a mechanism for toggling between "focus" or "activate" as well as a
> re-binding mechanism for accelerator key modifiers...

Just to throw an idea out there.  If you can control the binding of the
modifiers, you don't really need to support toggling, and it gives you
even more flexibility.  For example, I might bind Alt+Shift to the focus
behavior and Alt+Ctrl to the activate behavior.  If I only want the
focus behavior, I leave that unbound.  Now, how to build the settings in
such a way that it's easy for the user to discover and change...  that's
another discussion :)

Tom
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

mozilla accessibility
In reply to this post by Willie Walker
This makes a lot of sense.  In general, access keys are usually unique on a
page, but there is no reason they should have to be.  You might want to
create a navigation cycle and following these rules makes it pretty easy to
do, and seems to me very logical.

From: "Willie Walker" <[hidden email]>
... SNip Snip...
>, I think the answer of "focus" or "click" (or "activate" instead of
"click") might depend upon the type of control in question and how many
things use the same mnemonic.

In the GTK+ toolkit world, I see this behavior:

* For things that are labelled by something and the mnemonic is in the
label -- the mnemonic gives focus to the object.  Typical examples
include editable text areas with labels, combo boxes, etc. If there is
more than one object with the same mnemonic, repeated presses of the
mnemonic cycle through the objects.

* For things that have a mnemonic on them, the mnemonic invokes the
default action of the object.  Typical examples include checkboxes,
buttons, etc.  In the event that there is more than one object with the
same mnemonic, giving focus is used instead of invoking the default
action and repeated presses of the mnemonic cycle through the objects.

Will

Steve Lee wrote:
> If we go for the 'safer' focus option then we need a standard way to
> perform activation (or the default action) of a widget. Otherwise
> users have to discover 2 things (also OSKs that generate synthetic key
> events). Is that already covered with space or enter (say)?
>
> I do think that the doubling of required key presses will be an real
> annoyance for some, but not a necessarily a 'deal breaker'.
>

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

Gregory J. Rosmaita
In reply to this post by Tom Brunet
aloha, tom!

you are, of course, correct in pointing out that the user shouldn't
have a strictly binary choice (on/off) -- the one element that
complicates matters, of course, is keyboard real estate (especially
on mobile platforms) and key-conflicts -- if a user agent or an
embedded widget uses an operating system's default key bindings, they
should still be interpreted by the user agent as input intended for the
UA, which, in turn, means that the user agent must provide a pass-through
mechanism, so that CONTROL   ALT   M won't be misinterpreted as an
OS-level call, unless the user specifically specifies that it is
intended for the operating system...  an example of the problem is what
currently occurs whenever a hard-coded key-binding conflicts with/is
synonymous with an OS-level key-binding, whether that key-binding is
hard-coded into the chrome or in a widget, such as the aria menu example
at mozilla.org, which uses the key combination CONTROL   ALT   M to
activate the menu widget, but which (on a windows machine) causes
whatever desktop program has M defined as a "shortcut key" to launch,
rather than activating the widget (the only workaround is NOT to define
a shortcut key for the letter M)

such a pass-through mechanism could work on the same principle as
other prompts that offer a choice of actions and a "do not ask me
again" option, such as cookie prompts when set to prompt-for-all, or
could simply provide a pass-through mechanism, or perhaps i've been
relying on screen readers for too long that pass-throughs and keyboard
overlays have become part of my everyday experience...

thanks, though, for raising a very important point,
gregory
-------------------------------------------------------------------
It is difficult to say what is impossible, for yesterday's dream is
today's hope and tomorrow's reality.           -- Robert P. Goddard
-------------------------------------------------------------------
Gregory J. Rosmaita, [hidden email]
      Camera Obscura: http://www.hicom.net/~oedipus/
             Oedipus' Online Complexes: http://my.opera.com/oedipus
-------------------------------------------------------------------

---------- Original Message -----------
From: Tom Brunet <[hidden email]>
To: [hidden email]
Sent: Thu, 06 Mar 2008 11:24:28 -0600
Subject: Re: Should accesskey focus or click?

> > a mechanism for toggling between "focus" or "activate" as well as a
> > re-binding mechanism for accelerator key modifiers...
>
> Just to throw an idea out there.  If you can control the binding
> of the modifiers, you don't really need to support toggling, and
> it gives you even more flexibility.  For example, I might bind
> Alt Shift to the focus behavior and Alt Ctrl to the activate
> behavior.  If I only want the focus behavior, I leave that
> unbound.  Now, how to build the settings in such a way that it's
> easy for the user to discover and change...  that's another
> discussion :)
>
> Tom
------- End of Original Message -------

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: Should accesskey focus or click?

T.V Raman
In reply to this post by Marco Zehe-3
Agree on all counts.


Marco Zehe writes:
 > Hi Aaron,
 >
 > oh yes, that's a much debated topic. here are my 2 cents:
 >
 > Aaron Leventhal wrote:
 > > 1) Make all widgets focus on accesskey (change current behavior and be
 > > inconsistent with IE and the desktop, but be safer)
 >
 > I'd vote for this option. For one, we already do things differently in
 > that we require the use of Alt and Shift keys for accesskeys. IE uses
 > the Alt modifier only, creating all sorts of conflicts between access
 > keys on web pages and their menu system.
 >
 > Secondly, for screen reader users, the behavior is inconsistent anyway
 > as it is currently: On simple clickable items such as buttons or links,
 > the click is performed immediately, but when focusing textboxes, one has
 > to press ENTER to go into Forms Mode. Always focusing, but requiring the
 > user to explicitly invoking the element would introduce more consistency.
 >
 > Third, I don't know about others, but on the desktop, I hardly use
 > dialogs often enough to remember those Alt shortcut mnemonics. I know
 > from past experience that this is being advertised to give keyboard
 > users the same speed as mouse users, press a single key combination, and
 > you activate an element far away from where the focus currently is. But
 > honestly, who remembers the keys for many dialogs to actually take
 > advantage of this?
 >
 > And fourth, isn't Firefox the safer browser? Why shouldn't we be safer
 > in this regard as well by requiring the user to take explicit action
 > once the element is focused?
 >
 > Marco
 > _______________________________________________
 > dev-accessibility mailing list
 > [hidden email]
 > https://lists.mozilla.org/listinfo/dev-accessibility

--
Best Regards,
--raman

Title:  Research Scientist      
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
Google: tv+raman
GTalk:  [hidden email], [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility