- From: Jonathan Avila <jon.avila@ssbbartgroup.com>
- Date: Tue, 17 Jul 2012 13:00:57 -0400
- To: WAI Interest Group <w3c-wai-ig@w3.org>
- Message-ID: <b53357e7bf179acd05f08bb6bf14a618@mail.gmail.com>
Ø If you have a custom button with a role=button and don't listen for the
space key (when the button has focus) the common behviour in desktop
browsers is for the space key to scroll the page, definitely not what one
would want if they are trying to activate a focused button.
What you are describing happens if the events are listened for at the
document level not the element level right? adding it on a button does not
do what you describe as far as I can tell.
I have two comments for the list about adding events for key watching:
1. Screen readers such as JAWS in virtual cursor mode call the onclick
event. Removing the onclick event will break their support in virtual
cursor mode even if you watch for enter or space.
2. In the past – there were issues with some technology combinations
when onclick and onkeypress where used as the onclick event and keypress
event were both fired and actions occurred twice. Thus, this is something
to consider when using both types of events.
Jonathan
*From:* Steve Faulkner [mailto:faulkner.steve@gmail.com]
*Sent:* Tuesday, July 10, 2012 9:33 AM
*To:* Chaals McCathieNevile
*Cc:* Bryan Garaventa; Emmanuelle Gutiérrez y Restrepo; WAI Interest Group;
Ramón Corominas
*Subject:* Re: activating behaviours
Hi chaals
Understand where you are coming from, but I hink you are blowing the issue
out of proportion.
Currently developers do not have the facility to use generic mechanisms,
thats what the Indie UI [1] work is about. So its is best to provide
expected interactions for users where possible.
you wrote:
"Sometimes. For probably 100 million users (TV browsers and mobile phone
browsers), the 'ok' button in the joystick control activates buttons. For a
handful more, it's a special-purpose key - for example used to mirror half
a keyboard for one-handed users, or to swap input methods, or various other
important functionalities."
And how would listening for the space key in addition to the native event
handler, on a focused button, negatively impact them?
you wrote:
"Indeed. It makes a browser less usable if it is expected to behave that
way. On the other hand, if the browser is expected to use space for
something else, and the author has trapped it for their page only, you're
creating a new usability problem by interfering with the existing UI the
user knows."
If you have a custom button with a role=button and don't listen for the
space key (when the button has focus) the common behviour in desktop
browsers is for the space key to scroll the page, definitely not what one
would want if they are trying to activate a focused button.
What you are describing happens if the events are listened for at the
document level not the element level right? adding it on a button does not
do what you describe as far as I can tell.
you wrote:
"Having the page content determine the particular activation for UI is
generally a terrible idea - as recognised for more than a decade when
accessibility guidelines first said "make sure you enable access for all
users to all controls". Javascript keyboard traps are a terrible way of
trying to do that, and if at all possible should be avoided for the massive
range of problems they introduce. Not recommended as a solution, because
then we go from one problem to two problems..."
So are you suggesting that no event handlers should be used? I think this
would demolish any capacity to make scripted widgets accessible to keyboard
users.
[1] http://www.w3.org/WAI/IndieUI/
regards
SteveF
On 10 July 2012 14:04, Chaals McCathieNevile <w3b@chaals.com> wrote:
On Tue, 10 Jul 2012 11:04:04 +0200, Steve Faulkner
<faulkner.steve@gmail.com> wrote:
Hi Chaals,
you wrote:
"Why? The specific mechanism for activation should be able to varybetween
browsers*. Authors trying to guess which keys I have available on whatever
device is in front of me cause massive problems in general.It is true that
not all users know how to use their browser, but actively making it not
work isn't a very good solution and should only be done as a last resort."
There are standard keys for activating standard controls, which should work
pretty much everywhere.
No, there are common conventions, which should generally work on systems
that can offer them sensibly.
a button has 2 common keys assigned, enter and space.
Sometimes. For probably 100 million users (TV browsers and mobile phone
browsers), the 'ok' button in the joystick control activates buttons. For a
handful more, it's a special-purpose key - for example used to mirror half
a keyboard for one-handed users, or to swap input methods, or various other
important functionalities.
Some AT provide hints on how to use controls they recognise:I detailed
examples here, a while ago for a range of ARIA roles (which map onto
standard accessibility API roles:
http://www.paciellogroup.com/blog/aria-tests/user-input-widgets.html
design patterns for a range of controls are documented in the wai-aria
authoring guide: http://www.w3.org/WAI/PF/aria-practices/#aria_ex
Comments to come...
So the effect of having a button that cannot be activated using the space
key as expected, may be a problem.
Indeed. It makes a browser less usable if it is expected to behave that
way. On the other hand, if the browser is expected to use space for
something else, and the author has trapped it for their page only, you're
creating a new usability problem by interfering with the existing UI the
user knows.
This is exactly the same as the problem that was created by bad
implementations of accesskey (in fact if there had been better ones from
the get-go people probably wouldn't have come up with this "solution" in
the first place).
Having the page content determine the particular activation for UI is
generally a terrible idea - as recognised for more than a decade when
accessibility guidelines first said "make sure you enable access for all
users to all controls". Javascript keyboard traps are a terrible way of
trying to do that, and if at all possible should be avoided for the massive
range of problems they introduce. Not recommended as a solution, because
then we go from one problem to two problems...
cheers
On 9 July 2012 18:20, Chaals McCathieNevile <w3b@chaals.com> wrote:
On Mon, 09 Jul 2012 16:31:03 +0200, Emmanuelle Gutiérrez y Restrepo
<coordina@sidar.org> wrote:
Good point Bryan,
"Proper scripting is always necessary toensure functionality for users that
cannot benefit from ARIA."
It is important to note that, for all developers.
Indeed.
2012/7/9 Bryan Garaventa <bryan.garaventa@whatsock.com>
Actually I ran across this not too long ago, where I had a Span tag with
tabindex=0 and role=link, and tried using just a click event to handle
>>>the keypress.
This worked fine for screen reader users, but failed completely for
keyboard only users not using a screenreader.
On what browser(s)? Did you file bugs, or do you know of them for the
relevant browsers? Maybe you could add them to the a11ybugs list of things
to >annoy browser makers about...
----- Original Message -----
From: Steve Faulkner
I think pretty much all browsers allow
activating click events with the keyboard, and will add things if you give
them a tabindex. So adding specific keyboard >handling is probably
>>>>>redundant if you're just using click (mouseover, focus, and various
other things are still not so good).
I think you are right, but need to take into account keyboard behaviour for
things like buttons, which require activation on space key press as
>>>>well as enter key
Why? The specific mechanism for activation should be able to vary between
browsers*. Authors trying to guess which keys I have available on whatever
>device is in front of me cause massive problems in general. It is true
that not all users know how to use their browser, but actively making it
not >work isn't a very good solution and should only be done as a last
resort.
*for usability the basics should be the same where possible - e.g. Opera
should fix the fact that they use the tab key for form-only navigation and
>ctrl-arrows for "tabbing" through all active things, because although
their overall keyboard navigation implementation was light years more
advanced >than anyone else, when there is a convention as strong as the tab
key it is unhelpful not to follow it)
cheers
Chaals
see
http://www.paciellogroup.com/blog/2011/04/html5-accessibility-chops-just-use-a-button/for
more details.
regards
Steve
On 9 July 2012 11:47, Chaals McCathieNevile <w3b@chaals.com> wrote:
On Sun, 08 Jul 2012 22:29:30 +0200, Ramón Corominas <
listas@ramoncorominas.com> wrote:
Hi all, and apologies for cross-posting.
Last Saturday I gave a presentation in the SpainJS event about creating
accessible apps using WAI-ARIA. The idea was to show JS
>>>>>>developers that accessibility is an essential component to
achieve quality coding, and the potential of ARIA to create more
>>>>>>accessible apps.
I've uploaded the slides here:
http://ramoncorominas.com/spainjs/
Nice :)
Comments, suggestions or corrections are welcome (smile)
I think pretty much all browsers allow activating click events with the
keyboard, and will add things if you give them a tabindex. So >>>>>adding
specific keyboard handling is probably redundant if you're just using
click (mouseover, focus, and various other things are still >>>>>not so
good).
I'd be interested in learning if that is not the case...
cheers
Chaals
--Chaals - standards declaimer
-- with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
--
Chaals - standards declaimer
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar -
www.paciellogroup.com/resources/wat-ie-about.html
--
Chaals - standards declaimer
--
with regards
Steve Faulkner
Technical Director - TPG
www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 17 July 2012 17:01:27 UTC