Fix role click shim

[NickColley]

When trying to implement the shim I found the page will scroll when pressing space, then you navigate to the page.

To fix this we need to instead listen for keydown and not keyup so we can prevent the unwanted scroll behaviour.

I've also added a commit to simplify the shim since there's not a clear need for this to be flexible.

[tvararu]

Can be rewritten as:

var userPressedSpace = event.which === 32
if (userPressedSpace) {

Wouldn't need the comment then.

[fofr]

Rather than the code comment I’d have written something like: var SPACEBAR = 32; and if (event.which === SPACEBAR) { etc.

[robinwhittleton]

Is this true? As I understand it this isn’t about assistive tech but about normalising the behaviour of real buttons and links-styled-to-look-like-buttons for standard browsers.

[NickColley]

I thought this was the reason we did this, since some AT are telling users to press space which at the moment does not work?

[robinwhittleton]

@cfq arbitration needed 🙂

[gemmaleigh]

I'm with @NickColley on this one.

Here's the the original thread.

@aduggin said:

This is quite a complex issue - requires a long blog post to explain it fully.

The short version
For links that have role="button" we need to add an event handler so that it can be activated with the space bar (https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role)

The medium version
We have links and buttons that look the same so there is a consistent call to action for sighted users.
Unfortunately this creates inconsistency for screen reader users and speech recognition users.
To progress through a transaction they have to sometimes interact with a link and sometimes with a button.

Adding role="button" to links provides consistency as it makes screen readers and speech recognition software treat it as a button. This only works in some screen reader browser combinations and the latest version of Dragon Naturally speaking (13) that support role="button".

Buttons can be activated with the space bar, links can't. This behaviour needs to be added with javascript to a link with role="button" as it is not automatically added by adding role="button"

So, adding role="button" and an event handler for the space bar will only provide the required consistency to some assistive technology users.

In an ideal world links look like links and buttons look like buttons

The long version
In a blog post that I need to find time to write - but includes information about how screen reader users and dragon users interact with links and buttons and the scenarios of when people will be confused by our links and buttons looking the same.

[NickColley]

I've added a link to Alistair's comment for context

[cfq]

Thanks @gemmaleigh, that's the whole answer. We started with AT users but our investigation has shown us that browser vendors haven't implemented the functionality on purpose and this was the recommended solution.

[cfq]

Here's a video of our test on buttons vs links on Dragon NaturallySpeaking 13: https://www.youtube.com/watch?v=NO7u2tEbFQY

[robinwhittleton]

I thought I remembered something about keydown being a bit weird in old IE, but I think I was actually thinking about keypress. I guess this has been tested in IE8+? If so I’ll merge.

[NickColley]

Okay after testing this again I realise keyup is the right behaviour for space.

So this PR needs to be changed to handle keydown to prevent scrolling of the page, and handle keyup to click the button...

[NickColley]

I can't find a place where that behaviour is defined in any spec, so I'm presuming it's down to the operating system.

I've tested this PR in IE8,IE9,IE10 and it works.

So this should be good to go as long as we can stomach the spacebar submitting on keydown and not keyup.