Re: activating behaviours

Hey Steve
I think we are in agreement... concern is not with expected behaviour, but
with introducing behaviour in ARIA-enriched websites, which is not emulated
in a non-ARIA site. If for example I introduce Space as a standard way (in
an ARIA-enriched website) to activate a hyper-link, and this is not
standard behaviour in a conventional (non-ARIA) site, then I may end up
creating confusion for users who least needs it.

There's also a much larger group of users who are keyboard users, who do
not use JAWS (or other AT software), so they would not have the benefit of
being  provided with an instructional hint.

Care should be taken therefore, when specifying behaviour of keys, that it
does not interfere with the natural order of things as they are, or at
least not until use of ARIA has become ubiquitous.

Take care, Harry





On 10 July 2012 16:34, Steve Faulkner <faulkner.steve@gmail.com> wrote:

> Hi Harry,
>
> I am not advocating anything whacky or unexpected
>
> Keyboard users expect the spacebar to activate a button as well. It's a
> common cross OS, cross software interaction behaviour, that's why it is
> recommended for the button behaviour in the ARIA  button design pattern [1]
> same as for checkboxes [2] as you mentioned.
>
> Screen reading software such as JAWS provides a instructional hint for
> novice users, when a button receives focus
> "press spacebar to press" no mention of the enter key.
>
> So not providing expected behaviour for a custom custom widget that is
> identified as a button through the accessibility API may lead to what you
> describe:
>
>
> " If an onkeypress event leads to different functionality, then the entire
> keyboard user population are going to find their world turned upside down,
> and we have an unusable interface. (And, If the onkeypress event does the
> same thing, then the onkeypress is redundant.)"
>
>
> [1] http://www.w3.org/WAI/PF/aria-practices/#button
> [2] http://www.w3.org/WAI/PF/aria-practices/#checkbox
>
>
> regards
> SteveF
>
>
> On 10 July 2012 15:24, Harry Loots <harry.loots@ieee.org> wrote:
>
>> Hey Steve
>> Keyboard users expect the spacebar to toggle checkboxes (in forms). If an
>> onkeypress event leads to different functionality, then the entire keyboard
>> user population are going to find their world turned upside down, and we
>> have an unusable interface. (And, If the onkeypress event does the same
>> thing, then the onkeypress is redundant.)
>>
>> Shortcut keys are a great aid to keyboard users; but not if implemented
>> in a manner that interferes with conventional behaviour. Ctrl-S to me means
>> "Save". If Ctrl-S is used to initiate some other action, then I'm left
>> confused.
>>
>> Regards
>> Harry
>>
>>
>>
>> On 10 July 2012 16:03, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>>
>>> Hi Harry,
>>>
>>> "I wholeheartedly agree that interfering with the natural behaviour of
>>> buttons and keys on devices lead to unusable devices. (And for that matter,
>>> with other established conventions)"
>>>
>>> how does the addition of an onkeypress event handler that activates the
>>> button when the space key is pressed interfere with the natural behaviour
>>> of buttons?
>>>
>>> regards
>>> SteveF
>>>
>>>
>>>
>>> On 10 July 2012 14:36, Harry Loots <harry.loots@ieee.org> wrote:
>>>
>>>> I wholeheartedly agree that interfering with the natural behaviour of
>>>> buttons and keys on devices lead to unusable devices. (And for that matter,
>>>> with other established conventions)
>>>>
>>>> Take care, Harry
>>>>
>>>>
>>>>
>>>>
>>>> On 10 July 2012 15: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<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<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/<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/<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/<http://dev.w3.org/html5/alt-techniques/>
>>>>>>>>>
>>>>>>>>> Web Accessibility Toolbar - www.paciellogroup.com/**
>>>>>>>>> resources/wat-ie-about.html<http://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/<http://dev.w3.org/html5/alt-techniques/>
>>>>> Web Accessibility Toolbar -
>>>>> www.paciellogroup.com/**resources/wat-ie-about.html<http://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
>>>
>>>
>>>
>>
>
>
> --
> 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
>
>
>