New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove button role from start link #272

Merged
merged 1 commit into from Jul 13, 2016

Conversation

Projects
None yet
@colinrotherham
Contributor

colinrotherham commented Jul 12, 2016

By keeping role="button" on start-button links:

  1. JAWS announces "Continue. Button. To activate press space bar".
  2. VoiceOver (Mac) via Chrome announces "You are currently on a button. To click this button, press Control-Option-Space".

Unfortunately:

  • Pressing space does nothing in older versions of JAWS.
  • Pressing Control-Option-Space does nothing in Chrome.

Why? A keyup event listener is still required to handle the space key. This will prevent some assistive-device users from starting the service.

I'd advise removing the role as this is probably a mistake.

Thanks

Remove button role from start link
Regardless of their visual look, start links don’t have button behaviour
@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith commented Jul 12, 2016

Yep. This is listed in @aduggin's Accessibility fails example page too.

@gemmaleigh

This comment has been minimized.

Show comment
Hide comment
@gemmaleigh

gemmaleigh Jul 13, 2016

Contributor

You're absolutely right @colinrotherham, this was a copied example of a start button from another GOV.UK page: https://www.gov.uk/vehicle-tax, it's not right that links are announced as buttons.

Thanks for the PR.

Contributor

gemmaleigh commented Jul 13, 2016

You're absolutely right @colinrotherham, this was a copied example of a start button from another GOV.UK page: https://www.gov.uk/vehicle-tax, it's not right that links are announced as buttons.

Thanks for the PR.

@gemmaleigh gemmaleigh merged commit 574e87f into alphagov:master Jul 13, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 14, 2016

Hi @gemmaleigh we had the good fortune to have @aduggin in the room today. We mentioned this pull request in passing and it might be that this was not the way to go.

@aduggin Do you want to review this pull request and document a little about what you think is best here?

cc: @colinrotherham @robinwhittleton

paulmsmith commented Jul 14, 2016

Hi @gemmaleigh we had the good fortune to have @aduggin in the room today. We mentioned this pull request in passing and it might be that this was not the way to go.

@aduggin Do you want to review this pull request and document a little about what you think is best here?

cc: @colinrotherham @robinwhittleton

@jonhurrell

This comment has been minimized.

Show comment
Hide comment
@jonhurrell

jonhurrell Jul 14, 2016

If I recall the issue potentially lies with Dragon announcement. I do agree in principle with the removal as I've always adhered to:
If it navigates, it is a link. Use an anchor element.
If it triggers an action, it is a button. Use a button element.

If indeed the aria attribute was added for Dragon concerns, it may well excluding old versions anyway:
http://simplyaccessible.com/article/dragon-aria/

It's be great to have a Dragon licence to test some variants on. :(

jonhurrell commented Jul 14, 2016

If I recall the issue potentially lies with Dragon announcement. I do agree in principle with the removal as I've always adhered to:
If it navigates, it is a link. Use an anchor element.
If it triggers an action, it is a button. Use a button element.

If indeed the aria attribute was added for Dragon concerns, it may well excluding old versions anyway:
http://simplyaccessible.com/article/dragon-aria/

It's be great to have a Dragon licence to test some variants on. :(

@edwardhorsford

This comment has been minimized.

Show comment
Hide comment
@edwardhorsford

edwardhorsford Jul 15, 2016

Contributor

This is a tricky issue with no clear solution - I don't think it's as easy as not having things that look like buttons unless they trigger an explicit action.

We have elements on some pages that look like buttons to make them really clear to users that they represent the primary route forward. Not all pages post data to the server, but we want to be consistent with the display of our 'primary call to action'. role=button helps here, but also needs the space bar to be shimmed to work correctly.

As @jonhurrell this still presents an issue for older versions of Dragon, which don't understand the role=button.

Contributor

edwardhorsford commented Jul 15, 2016

This is a tricky issue with no clear solution - I don't think it's as easy as not having things that look like buttons unless they trigger an explicit action.

We have elements on some pages that look like buttons to make them really clear to users that they represent the primary route forward. Not all pages post data to the server, but we want to be consistent with the display of our 'primary call to action'. role=button helps here, but also needs the space bar to be shimmed to work correctly.

As @jonhurrell this still presents an issue for older versions of Dragon, which don't understand the role=button.

@edwardhorsford

This comment has been minimized.

Show comment
Hide comment
@edwardhorsford

edwardhorsford Jul 15, 2016

Contributor

In the short term, I think we should revert this change. role=button helps most screen readers and latest Dragon correctly access this element. I'm not aware of a downside of having it, apart from that not all screen readers benefit from it.

Contributor

edwardhorsford commented Jul 15, 2016

In the short term, I think we should revert this change. role=button helps most screen readers and latest Dragon correctly access this element. I'm not aware of a downside of having it, apart from that not all screen readers benefit from it.

@aduggin

This comment has been minimized.

Show comment
Hide comment
@aduggin

aduggin Jul 15, 2016

Contributor

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.

Contributor

aduggin commented Jul 15, 2016

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.

@colinrotherham

This comment has been minimized.

Show comment
Hide comment
@colinrotherham

colinrotherham Jul 15, 2016

Contributor

Hi @edwardhorsford,

Downside is mentioned above, i.e.

  • Older JAWS announcing "Press space bar" which does nothing
  • Key combo suggested by VoiceOver Mac also nothing in Chrome.

Whilst reverting may be great for Dragon (need to confirm) this is a regression for these two.

Please only revert if you're adding the keyup space key shim suggested by @aduggin. Whilst the obviousness of a button is great, do ensure you simulate its functionality too.

For reference, Bootstrap recently added commentary regarding role="button". They've now dropped this as a default and advise against using it for regular links to other pages/sections: http://v4-alpha.getbootstrap.com/components/buttons/#button-tags

Contributor

colinrotherham commented Jul 15, 2016

Hi @edwardhorsford,

Downside is mentioned above, i.e.

  • Older JAWS announcing "Press space bar" which does nothing
  • Key combo suggested by VoiceOver Mac also nothing in Chrome.

Whilst reverting may be great for Dragon (need to confirm) this is a regression for these two.

Please only revert if you're adding the keyup space key shim suggested by @aduggin. Whilst the obviousness of a button is great, do ensure you simulate its functionality too.

For reference, Bootstrap recently added commentary regarding role="button". They've now dropped this as a default and advise against using it for regular links to other pages/sections: http://v4-alpha.getbootstrap.com/components/buttons/#button-tags

@aduggin

This comment has been minimized.

Show comment
Hide comment
@aduggin

aduggin Jul 16, 2016

Contributor

Based on advice from @LJWatson and Chris Moore , all links on GOV.UK that look like buttons (i.e have a class="button") need to have a role="button" and a event handler for the spacebar.

We should see if we can add both of these with javascript - rather than hard coding the role in the HTML and just using js to add the event handler. This has a couple of advantages.

  1. The accessibility fix will be automatically added to all links across GOV.UK (on pages that pull in the javascript) - meaning we are not reliant on developers manually updating the HTML on every link that has class="button"
  2. If we decide to change the implementation details we can do it in a single place
  3. The two behaviours are tied together which means that if a screen reader user doesn't have javascript then they won't be in the position of it being announced as a button but the spacebar activation not working.

We need to confirm that if the role="button" is added via javascript that screen readers and Dragon still treat it like a button. There is a chance that the WAI-ARIA needs to be hardcoded into HTML so that it is present as the page is loaded. The sandbox would be a good place to to this.

Contributor

aduggin commented Jul 16, 2016

Based on advice from @LJWatson and Chris Moore , all links on GOV.UK that look like buttons (i.e have a class="button") need to have a role="button" and a event handler for the spacebar.

We should see if we can add both of these with javascript - rather than hard coding the role in the HTML and just using js to add the event handler. This has a couple of advantages.

  1. The accessibility fix will be automatically added to all links across GOV.UK (on pages that pull in the javascript) - meaning we are not reliant on developers manually updating the HTML on every link that has class="button"
  2. If we decide to change the implementation details we can do it in a single place
  3. The two behaviours are tied together which means that if a screen reader user doesn't have javascript then they won't be in the position of it being announced as a button but the spacebar activation not working.

We need to confirm that if the role="button" is added via javascript that screen readers and Dragon still treat it like a button. There is a chance that the WAI-ARIA needs to be hardcoded into HTML so that it is present as the page is loaded. The sandbox would be a good place to to this.

@colinrotherham

This comment has been minimized.

Show comment
Hide comment
@colinrotherham

colinrotherham Jul 16, 2016

Contributor

@aduggin If you're considering scenarios with non-ARIA support you can instead start with an <a> link for non-JS and enhance to an actual <button> element with a click handler.

No role attribute needed.

No shims, just HTML as it was intended.

Contributor

colinrotherham commented Jul 16, 2016

@aduggin If you're considering scenarios with non-ARIA support you can instead start with an <a> link for non-JS and enhance to an actual <button> element with a click handler.

No role attribute needed.

No shims, just HTML as it was intended.

@aduggin

This comment has been minimized.

Show comment
Hide comment
@aduggin

aduggin Jul 16, 2016

Contributor

@colinrotherham Yup, that's another options to explore. This would avoid the issue of some assistive technologies not supporting role="button". There is a risk that changing the markup could result in breaking existing css/js. For example, we could break any google analytics that is tracking clicks on the link and could cause a visual issue.

As I said, this is a complex issue.

Contributor

aduggin commented Jul 16, 2016

@colinrotherham Yup, that's another options to explore. This would avoid the issue of some assistive technologies not supporting role="button". There is a risk that changing the markup could result in breaking existing css/js. For example, we could break any google analytics that is tracking clicks on the link and could cause a visual issue.

As I said, this is a complex issue.

@joelanman

This comment has been minimized.

Show comment
Hide comment
@joelanman

joelanman Jul 17, 2016

Member

The key issue is that in HTML, button elements are for submitting forms and links are for requesting another page - they're semantically different. However in terms of visual priority - a button normally looks more important than a link.

Visual priority is one of the most effective tools we have in making things easy to understand. So if we design a page to semantically correct, the visual priority might be wrong, and the same the other way round.

Member

joelanman commented Jul 17, 2016

The key issue is that in HTML, button elements are for submitting forms and links are for requesting another page - they're semantically different. However in terms of visual priority - a button normally looks more important than a link.

Visual priority is one of the most effective tools we have in making things easy to understand. So if we design a page to semantically correct, the visual priority might be wrong, and the same the other way round.

@chrismoorembe

This comment has been minimized.

Show comment
Hide comment
@chrismoorembe

chrismoorembe Jul 18, 2016

Which versions of JAWS were not enabling the role = button to proceed to the next step? Also, what browser and version was this tested with? Chrome is not officially supported by Voiceover, so you'll find those users choose to use Safari instead. Ensure future tests focus on that combination. If we are going to style links to look like abutton, then they should behave like one. This is not only for assistive technology users, but also keyboard only users. If a user was to telephone a call centre to get support to use their online service, it would be rather confusing if the agent tells the user to click on the 'Start now' or 'Continue' button. Whatever approach we take needs to be consistent across GOV.UK and tested in the accessibility sand box.

chrismoorembe commented Jul 18, 2016

Which versions of JAWS were not enabling the role = button to proceed to the next step? Also, what browser and version was this tested with? Chrome is not officially supported by Voiceover, so you'll find those users choose to use Safari instead. Ensure future tests focus on that combination. If we are going to style links to look like abutton, then they should behave like one. This is not only for assistive technology users, but also keyboard only users. If a user was to telephone a call centre to get support to use their online service, it would be rather confusing if the agent tells the user to click on the 'Start now' or 'Continue' button. Whatever approach we take needs to be consistent across GOV.UK and tested in the accessibility sand box.

@colinrotherham

This comment has been minimized.

Show comment
Hide comment
@colinrotherham

colinrotherham Jul 18, 2016

Contributor

Hi @chrismoorembe,

In Safari 9.1.1 the space key doesn't work either. Chrome testing was carried out by @vipickering so I can't confirm a version number.

Older versions of JAWS not following links (on space key press) was taken from this tweet: https://twitter.com/thebillygregory/status/532703182208921600

This implies that it's a workaround in newer JAWS added to avoid ARIA role misuse like this. I wasn't happy leaving these older versions broken, but I don't know a specific version.

I agree that this pull request does lose the priority and obviousness of a button element, but it leaves no browsers broken nor screen readers unable to activate the start link.

I'll leave it to @aduggin to coordinate the "space key shim" needed to fill any compatibility gaps so we can keep the button vs. link identity.

Thanks for the discussion!

Contributor

colinrotherham commented Jul 18, 2016

Hi @chrismoorembe,

In Safari 9.1.1 the space key doesn't work either. Chrome testing was carried out by @vipickering so I can't confirm a version number.

Older versions of JAWS not following links (on space key press) was taken from this tweet: https://twitter.com/thebillygregory/status/532703182208921600

This implies that it's a workaround in newer JAWS added to avoid ARIA role misuse like this. I wasn't happy leaving these older versions broken, but I don't know a specific version.

I agree that this pull request does lose the priority and obviousness of a button element, but it leaves no browsers broken nor screen readers unable to activate the start link.

I'll leave it to @aduggin to coordinate the "space key shim" needed to fill any compatibility gaps so we can keep the button vs. link identity.

Thanks for the discussion!

@chrismoorembe

This comment has been minimized.

Show comment
Hide comment
@chrismoorembe

chrismoorembe Jul 18, 2016

ios 9 still does not include rock solid keyboard support on an iPhone. The default way to trigger a button on the Mac is the enter key. See keyboard shortcuts:
https://support.apple.com/en-gb/HT204434

For Voiceover, the default to open a link or button is to use control + option + space bar, or up and down arrow simultaneously when quick nav is active.

Sadly that twitter conversation doesn’t shine anymore light. I’ve been able to use the spacebar on links and buttons since as far back as JAWS 12 when I became a JAWS user. We are on JAWS 17 now. Hopefully we’ll be able to capture all these issues inside the sand box.

On 18 Jul 2016, at 13:40, Colin Rotherham notifications@github.com wrote:

Hi @chrisholmes https://github.com/chrisholmes,

In Safari 9.1.1 the space key doesn't work either. Chrome testing was carried out by @vipickering https://github.com/vipickering so I can't confirm a version number.

Older versions of JAWS not following links (on space key press) was taken from this tweet: https://twitter.com/thebillygregory/status/532703182208921600 https://twitter.com/thebillygregory/status/532703182208921600
This implies that it's a workaround in newer JAWS added to avoid ARIA role misuse like this. I wasn't happy leaving these older versions broken.

I agree that this pull request does lose the priority and obviousness of a button element, but it leaves no browsers broken nor screen readers unable to activate the start link.

I'll leave it to @aduggin https://github.com/aduggin to coordinate the "space key shim" needed to fill any compatibility gaps so we can keep the button vs. link identity.

Thanks for the discussion!


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #272 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATkM58meUiyPklCrAIs1-Ia7Nn3_R0uYks5qW3ROgaJpZM4JKhrn.

chrismoorembe commented Jul 18, 2016

ios 9 still does not include rock solid keyboard support on an iPhone. The default way to trigger a button on the Mac is the enter key. See keyboard shortcuts:
https://support.apple.com/en-gb/HT204434

For Voiceover, the default to open a link or button is to use control + option + space bar, or up and down arrow simultaneously when quick nav is active.

Sadly that twitter conversation doesn’t shine anymore light. I’ve been able to use the spacebar on links and buttons since as far back as JAWS 12 when I became a JAWS user. We are on JAWS 17 now. Hopefully we’ll be able to capture all these issues inside the sand box.

On 18 Jul 2016, at 13:40, Colin Rotherham notifications@github.com wrote:

Hi @chrisholmes https://github.com/chrisholmes,

In Safari 9.1.1 the space key doesn't work either. Chrome testing was carried out by @vipickering https://github.com/vipickering so I can't confirm a version number.

Older versions of JAWS not following links (on space key press) was taken from this tweet: https://twitter.com/thebillygregory/status/532703182208921600 https://twitter.com/thebillygregory/status/532703182208921600
This implies that it's a workaround in newer JAWS added to avoid ARIA role misuse like this. I wasn't happy leaving these older versions broken.

I agree that this pull request does lose the priority and obviousness of a button element, but it leaves no browsers broken nor screen readers unable to activate the start link.

I'll leave it to @aduggin https://github.com/aduggin to coordinate the "space key shim" needed to fill any compatibility gaps so we can keep the button vs. link identity.

Thanks for the discussion!


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #272 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATkM58meUiyPklCrAIs1-Ia7Nn3_R0uYks5qW3ROgaJpZM4JKhrn.

@vipickering

This comment has been minimized.

Show comment
Hide comment
@vipickering

vipickering Jul 19, 2016

Hi all,

When I raised this initially, my thoughts were as follows.

The markup is defining the incorrect behaviour. Which is because the visual styling is dictating a button, when semantically we need a link. I think there are ways we can solve this easily by changing the visual.

I agree with @joelanman that the current styling is adding weight to the start button and this is probably a good thing. But I feel that what we should be doing is pushing back to the UX and UI peeps to explore in greater detail:

  1. Are there any other ways to keep the visual importance and make it look less like a button? We are supposed to be about user testing and trying things out. This is something we should be doing and exploring as real way to solve this. If the data all comes back in favour of the button styling over everything else. Then we need to think again about things.
  2. I've heard from one team that they have good data suggesting the start page is hampering people using their service and removing it increased usage. It's a bit tangential but perhaps this is also worth investigating, since it would also remove the problem if it turns out to be true.

At the very least I think we need some A/B testing against different start link designs to prove that the design has to be a button, before we begin implementing workarounds, hacks and other solutions being discussed.

Real data is what we are lacking in this discussion.

vipickering commented Jul 19, 2016

Hi all,

When I raised this initially, my thoughts were as follows.

The markup is defining the incorrect behaviour. Which is because the visual styling is dictating a button, when semantically we need a link. I think there are ways we can solve this easily by changing the visual.

I agree with @joelanman that the current styling is adding weight to the start button and this is probably a good thing. But I feel that what we should be doing is pushing back to the UX and UI peeps to explore in greater detail:

  1. Are there any other ways to keep the visual importance and make it look less like a button? We are supposed to be about user testing and trying things out. This is something we should be doing and exploring as real way to solve this. If the data all comes back in favour of the button styling over everything else. Then we need to think again about things.
  2. I've heard from one team that they have good data suggesting the start page is hampering people using their service and removing it increased usage. It's a bit tangential but perhaps this is also worth investigating, since it would also remove the problem if it turns out to be true.

At the very least I think we need some A/B testing against different start link designs to prove that the design has to be a button, before we begin implementing workarounds, hacks and other solutions being discussed.

Real data is what we are lacking in this discussion.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 19, 2016

Some thoughts on different points raised here (sorry, quite long - maybe grab a cup of tea first)...

Jaws simulates a mouse click when either enter or space is used to activate a link. The presence of role="button" doesn't affect this, though the setting itself can be toggled on/off in the Jaws settings. Billy's tweet not withstanding, Jaws has done this for many years now.

This aside, browsers fire different events in response to standard keyboard interactions, and those events change when there is a screen reader involved.

<a href="http://tink.uk">tink.uk</a>

When this link is activated using the enter key in Safari on MacOS, the event sequence is keydown, keyup, click. If VoiceOver is enabled, the sequence remains the same when the enter key is used.

It is worth noting that the expected command for activating a link/button in MacOS with VoiceOver enabled is control option space (as VoiceOver indicates when focus moves to the link/button). But when this command is used, the event sequence becomes mousedown, mouseup, click instead.

Things are broadly similar on Windows. When the enter key is used to activate the link in Firefox, the event sequence is keydown, keypress, keyup, click. When NVDA or Jaws is enabled it becomes mousedown, mouseup, click.

Regardless of the browser or whether there is a screen reader enabled, these events do not change when role="button" is applied to the link. What does change is the expectation that the space key can also be used to activate it.

Browsers on touch devices fire simple mouse events in response to touch gestures. AFAIK keyboard events do not enter the equation whether an AT is enabled or not.

The Dragon NS command for activating a link is the same as for activating a button. Use the "Click" command, followed by the accessible name of the link/button. If there is more than one link/button with the same accessible name, Dragon will display a number next to each and this can be used to target the right one.

So if you use many ATs, it is likely the pseudo-button will work with space (or the VO equivalent) or enter, without any additional JavaScript.

That said, it is still necessary to handle space key interaction for people using the keyboard without an AT, and for those AT/browser combinations that do not handle it for themselves (Narrator with Edge for example).

Whatever happens, we need to do some testing!

LJWatson commented Jul 19, 2016

Some thoughts on different points raised here (sorry, quite long - maybe grab a cup of tea first)...

Jaws simulates a mouse click when either enter or space is used to activate a link. The presence of role="button" doesn't affect this, though the setting itself can be toggled on/off in the Jaws settings. Billy's tweet not withstanding, Jaws has done this for many years now.

This aside, browsers fire different events in response to standard keyboard interactions, and those events change when there is a screen reader involved.

<a href="http://tink.uk">tink.uk</a>

When this link is activated using the enter key in Safari on MacOS, the event sequence is keydown, keyup, click. If VoiceOver is enabled, the sequence remains the same when the enter key is used.

It is worth noting that the expected command for activating a link/button in MacOS with VoiceOver enabled is control option space (as VoiceOver indicates when focus moves to the link/button). But when this command is used, the event sequence becomes mousedown, mouseup, click instead.

Things are broadly similar on Windows. When the enter key is used to activate the link in Firefox, the event sequence is keydown, keypress, keyup, click. When NVDA or Jaws is enabled it becomes mousedown, mouseup, click.

Regardless of the browser or whether there is a screen reader enabled, these events do not change when role="button" is applied to the link. What does change is the expectation that the space key can also be used to activate it.

Browsers on touch devices fire simple mouse events in response to touch gestures. AFAIK keyboard events do not enter the equation whether an AT is enabled or not.

The Dragon NS command for activating a link is the same as for activating a button. Use the "Click" command, followed by the accessible name of the link/button. If there is more than one link/button with the same accessible name, Dragon will display a number next to each and this can be used to target the right one.

So if you use many ATs, it is likely the pseudo-button will work with space (or the VO equivalent) or enter, without any additional JavaScript.

That said, it is still necessary to handle space key interaction for people using the keyboard without an AT, and for those AT/browser combinations that do not handle it for themselves (Narrator with Edge for example).

Whatever happens, we need to do some testing!

@colinrotherham

This comment has been minimized.

Show comment
Hide comment
@colinrotherham

colinrotherham Jul 20, 2016

Contributor

Thanks @LJWatson,

Just need a volunteer to add the space-bar shim!

Then we pass the accessibility fail mentioned by @paulmsmith above:
aduggin/accessibility-fails@78b5e79#diff-eacf331f0ffc35d4b482f1d15a887d3bR780

Contributor

colinrotherham commented Jul 20, 2016

Thanks @LJWatson,

Just need a volunteer to add the space-bar shim!

Then we pass the accessibility fail mentioned by @paulmsmith above:
aduggin/accessibility-fails@78b5e79#diff-eacf331f0ffc35d4b482f1d15a887d3bR780

@jonhurrell

This comment has been minimized.

Show comment
Hide comment
@jonhurrell

jonhurrell Jul 20, 2016

Where's the best place to start putting up some test examples (quickest)?

jonhurrell commented Jul 20, 2016

Where's the best place to start putting up some test examples (quickest)?

@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 20, 2016

@jonhurrell maybe just http://codepen.io / http://jsbin.com for now? Then maybe @aduggin can incorporate them into the sandbox for wider consumption later?

paulmsmith commented Jul 20, 2016

@jonhurrell maybe just http://codepen.io / http://jsbin.com for now? Then maybe @aduggin can incorporate them into the sandbox for wider consumption later?

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 20, 2016

If it helps, there are three button test cases available below. They are all toggle buttons (so do nothing except change in appearance and state), but have all the interaction needed to test this little lot I think.

The script attached to the <a role="button"> test case uses keydown instead of keyup, but in practice this shouldn't make any material difference.

LJWatson commented Jul 20, 2016

If it helps, there are three button test cases available below. They are all toggle buttons (so do nothing except change in appearance and state), but have all the interaction needed to test this little lot I think.

The script attached to the <a role="button"> test case uses keydown instead of keyup, but in practice this shouldn't make any material difference.

@nubz

This comment has been minimized.

Show comment
Hide comment
@nubz

nubz Jul 20, 2016

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com wrote:

If it helps, there are three button test cases available below. They are
all toggle buttons (so do nothing except change in appearance and state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn
.

nubz commented Jul 20, 2016

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com wrote:

If it helps, there are three button test cases available below. They are
all toggle buttons (so do nothing except change in appearance and state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn
.

@chrismoorembe

This comment has been minimized.

Show comment
Hide comment
@chrismoorembe

chrismoorembe Jul 20, 2016

Q: Why do we style links to look like buttons in the first place?

A: Because that visually makes them stand out and easy to find.

The same applies to screen readers, as setting the role to button means you can use the quick key ‘B’ if using JAWS to locate the button instead of working your way through a series of links. Control + option + J on a Mac with VoiceoVer performs a similar function.

If keyboard users see a button, then they will attempt to activate it by pressing the spacebar if on Windows., which won’t work without a handler.

Some people on this thread have stated that a link takes you somewhere and that buttons perform an action.

A’ Start now’ button performs an action, it starts the transaction.

A ‘Continue and Save’ button performs an action by saving the data that has been submitted so far.

Also, as I mentioned earlier, if a user was to call to get support with the transaction, the call operator would tell the user to click on what they could see, which would be a button and not a link.

So unless we are going to remove the button styling, which will make GOV.UK look visually bland and make it harder for users to quickly scan the page to locate a button, then I think we should continue to do the hard work to make things easier for the user.

On 20 Jul 2016, at 20:34, Alistair Macdonald notifications@github.com wrote:

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com wrote:

If it helps, there are three button test cases available below. They are
all toggle buttons (so do nothing except change in appearance and state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #272 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATkM55m13mov-qbn-BILm4MVTE6i9qFpks5qXnhdgaJpZM4JKhrn.

chrismoorembe commented Jul 20, 2016

Q: Why do we style links to look like buttons in the first place?

A: Because that visually makes them stand out and easy to find.

The same applies to screen readers, as setting the role to button means you can use the quick key ‘B’ if using JAWS to locate the button instead of working your way through a series of links. Control + option + J on a Mac with VoiceoVer performs a similar function.

If keyboard users see a button, then they will attempt to activate it by pressing the spacebar if on Windows., which won’t work without a handler.

Some people on this thread have stated that a link takes you somewhere and that buttons perform an action.

A’ Start now’ button performs an action, it starts the transaction.

A ‘Continue and Save’ button performs an action by saving the data that has been submitted so far.

Also, as I mentioned earlier, if a user was to call to get support with the transaction, the call operator would tell the user to click on what they could see, which would be a button and not a link.

So unless we are going to remove the button styling, which will make GOV.UK look visually bland and make it harder for users to quickly scan the page to locate a button, then I think we should continue to do the hard work to make things easier for the user.

On 20 Jul 2016, at 20:34, Alistair Macdonald notifications@github.com wrote:

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com wrote:

If it helps, there are three button test cases available below. They are
all toggle buttons (so do nothing except change in appearance and state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn
.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #272 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/ATkM55m13mov-qbn-BILm4MVTE6i9qFpks5qXnhdgaJpZM4JKhrn.

@nubz

This comment has been minimized.

Show comment
Hide comment
@nubz

nubz Jul 21, 2016

Thank you for the explanation however whilst I appreciate that visually
styling a link to look like a button has the desired effect I do not see
how the non-semantic attribute role="button" on a hyperlink is the AT
solution. Given that JS is required to bind keystrokes, is it not the case
that these can be bound to a CTA link equally as well without the
non-semantic role="button" attribute and non-JS enabled users will enjoy
the normal tab + enter behaviour on an aptly titled link afforded by all
browsers?

On Wed, 20 Jul 2016, 21:44 chrismoorembe, notifications@github.com wrote:

Q: Why do we style links to look like buttons in the first place?

A: Because that visually makes them stand out and easy to find.

The same applies to screen readers, as setting the role to button means
you can use the quick key ‘B’ if using JAWS to locate the button instead of
working your way through a series of links. Control + option + J on a Mac
with VoiceoVer performs a similar function.

If keyboard users see a button, then they will attempt to activate it by
pressing the spacebar if on Windows., which won’t work without a handler.

Some people on this thread have stated that a link takes you somewhere and
that buttons perform an action.

A’ Start now’ button performs an action, it starts the transaction.

A ‘Continue and Save’ button performs an action by saving the data that
has been submitted so far.

Also, as I mentioned earlier, if a user was to call to get support with
the transaction, the call operator would tell the user to click on what
they could see, which would be a button and not a link.

So unless we are going to remove the button styling, which will make
GOV.UK look visually bland and make it harder for users to quickly scan
the page to locate a button, then I think we should continue to do the hard
work to make things easier for the user.

On 20 Jul 2016, at 20:34, Alistair Macdonald notifications@github.com
wrote:

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com
wrote:

If it helps, there are three button test cases available below. They
are
all toggle buttons (so do nothing except change in appearance and
state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
#272 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/alphagov/govuk_elements/pull/272#issuecomment-234057424>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/ATkM55m13mov-qbn-BILm4MVTE6i9qFpks5qXnhdgaJpZM4JKhrn
.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61Kgs28P2bZrXzxC2e1pS0qDK5RRks5qXoihgaJpZM4JKhrn
.

nubz commented Jul 21, 2016

Thank you for the explanation however whilst I appreciate that visually
styling a link to look like a button has the desired effect I do not see
how the non-semantic attribute role="button" on a hyperlink is the AT
solution. Given that JS is required to bind keystrokes, is it not the case
that these can be bound to a CTA link equally as well without the
non-semantic role="button" attribute and non-JS enabled users will enjoy
the normal tab + enter behaviour on an aptly titled link afforded by all
browsers?

On Wed, 20 Jul 2016, 21:44 chrismoorembe, notifications@github.com wrote:

Q: Why do we style links to look like buttons in the first place?

A: Because that visually makes them stand out and easy to find.

The same applies to screen readers, as setting the role to button means
you can use the quick key ‘B’ if using JAWS to locate the button instead of
working your way through a series of links. Control + option + J on a Mac
with VoiceoVer performs a similar function.

If keyboard users see a button, then they will attempt to activate it by
pressing the spacebar if on Windows., which won’t work without a handler.

Some people on this thread have stated that a link takes you somewhere and
that buttons perform an action.

A’ Start now’ button performs an action, it starts the transaction.

A ‘Continue and Save’ button performs an action by saving the data that
has been submitted so far.

Also, as I mentioned earlier, if a user was to call to get support with
the transaction, the call operator would tell the user to click on what
they could see, which would be a button and not a link.

So unless we are going to remove the button styling, which will make
GOV.UK look visually bland and make it harder for users to quickly scan
the page to locate a button, then I think we should continue to do the hard
work to make things easier for the user.

On 20 Jul 2016, at 20:34, Alistair Macdonald notifications@github.com
wrote:

I'm somewhat confused by this discussion. Why do links have role="button"
when they are not a button? Remove it and all will be well non?

On Wed, 20 Jul 2016, 18:50 Léonie Watson, notifications@github.com
wrote:

If it helps, there are three button test cases available below. They
are
all toggle buttons (so do nothing except change in appearance and
state),
but have all the interaction needed to test this little lot I think.

The script attached to the test case uses keydown
instead of keyup, but in practice this shouldn't make any material
difference.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
#272 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ABZK61A9vmppiESIw3DuJHtc2f3zI1Prks5qXl_rgaJpZM4JKhrn

.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <
https://github.com/alphagov/govuk_elements/pull/272#issuecomment-234057424>,
or mute the thread <
https://github.com/notifications/unsubscribe-auth/ATkM55m13mov-qbn-BILm4MVTE6i9qFpks5qXnhdgaJpZM4JKhrn
.


You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#272 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZK61Kgs28P2bZrXzxC2e1pS0qDK5RRks5qXoihgaJpZM4JKhrn
.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 21, 2016

@nubz

We use code that (simplified) looks something like this:

<a href="start.html" class="button">Start now</a>

We use styling to make the link look like a button. Semantically it is still a link however, so there is a mismatch between what it is and what it appears to be.

The <a href> element has an implicit role of "link". When an AT queries the browser/accessibility tree for information about it, that is the role that is returned - and conveyed to the user. For example, a screen reader will announce "link".

The role attribute is used to add or change the semantics of an element. It does not change the characteristics of the element in the DOM, only in the accessibility tree.

<a href="start.html" class="button" role="button">Start now</a>

Now when an AT queries the browser it will be informed that this thing is a button. In the DOM it remains a link though, and so the browser does what it always does with links - makes it keyboard focusable, and actionable with the enter key.

So now the thing looks like a button, and is treated as a button in the accessibility tree and by ATs. The only mismatch now is that it doesn't quite behave like a button.

The expectation is that a button can be activated using enter or space keys. The browser (still thinking this thing is a link) provides the enter key behaviour, but the space key has to be provided with script. When we do this, the upshot is that the thing looks like a button, is treated as a button by ATs, and now behaves like a button.

If we didn't style this thing to look like a button, and providing it clearly looked like a link, we could dispense with the role and the additional scripting (as you suggest).

The catch is the visual affordance. Buttons are used to progress through most services, and our assumption is that the "Start now" button sets up this expectation with the user. It's also easier to call attention to a button than a link (visually and otherwise).

We could use the <button> element, which has an implicit role of "button", and the browser would provide the expected space/enter behaviour. The <button> element is JavaScript dependent though, so we would need to do something like start with a link and progressively enhance it to a <button> - which to some extent brings us back full circle to our link.

LJWatson commented Jul 21, 2016

@nubz

We use code that (simplified) looks something like this:

<a href="start.html" class="button">Start now</a>

We use styling to make the link look like a button. Semantically it is still a link however, so there is a mismatch between what it is and what it appears to be.

The <a href> element has an implicit role of "link". When an AT queries the browser/accessibility tree for information about it, that is the role that is returned - and conveyed to the user. For example, a screen reader will announce "link".

The role attribute is used to add or change the semantics of an element. It does not change the characteristics of the element in the DOM, only in the accessibility tree.

<a href="start.html" class="button" role="button">Start now</a>

Now when an AT queries the browser it will be informed that this thing is a button. In the DOM it remains a link though, and so the browser does what it always does with links - makes it keyboard focusable, and actionable with the enter key.

So now the thing looks like a button, and is treated as a button in the accessibility tree and by ATs. The only mismatch now is that it doesn't quite behave like a button.

The expectation is that a button can be activated using enter or space keys. The browser (still thinking this thing is a link) provides the enter key behaviour, but the space key has to be provided with script. When we do this, the upshot is that the thing looks like a button, is treated as a button by ATs, and now behaves like a button.

If we didn't style this thing to look like a button, and providing it clearly looked like a link, we could dispense with the role and the additional scripting (as you suggest).

The catch is the visual affordance. Buttons are used to progress through most services, and our assumption is that the "Start now" button sets up this expectation with the user. It's also easier to call attention to a button than a link (visually and otherwise).

We could use the <button> element, which has an implicit role of "button", and the browser would provide the expected space/enter behaviour. The <button> element is JavaScript dependent though, so we would need to do something like start with a link and progressively enhance it to a <button> - which to some extent brings us back full circle to our link.

@jonhurrell

This comment has been minimized.

Show comment
Hide comment
@jonhurrell

jonhurrell Jul 21, 2016

I wrote a little handler for this last night:
JSBin:a11y link click handler

Update: Moved to JSBin.

jonhurrell commented Jul 21, 2016

I wrote a little handler for this last night:
JSBin:a11y link click handler

Update: Moved to JSBin.

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 21, 2016

@jonhurrell
FWIW JSBin is an accessible alternative.

LJWatson commented Jul 21, 2016

@jonhurrell
FWIW JSBin is an accessible alternative.

@vipickering

This comment has been minimized.

Show comment
Hide comment
@vipickering

vipickering Jul 21, 2016

2 Seems the general consensus. So happy to go with the majority~~, providing we can fix the below bug~~.

When testing the code @jonhurrell Safari on Mac (Version 9.1.1 ) I can't tab to the buttons at all in the demo. I can click fine, but I can't tab to the button and press space to fire the action. I think it's to do with the keyup action.

Additionally, turning on an AT tech such as Voiceover allows me to focus on the button, and announces the spacebar option, but it does not except spacebar to fire the action only enter, behaving as a link.

vipickering commented Jul 21, 2016

2 Seems the general consensus. So happy to go with the majority~~, providing we can fix the below bug~~.

When testing the code @jonhurrell Safari on Mac (Version 9.1.1 ) I can't tab to the buttons at all in the demo. I can click fine, but I can't tab to the button and press space to fire the action. I think it's to do with the keyup action.

Additionally, turning on an AT tech such as Voiceover allows me to focus on the button, and announces the spacebar option, but it does not except spacebar to fire the action only enter, behaving as a link.

@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 21, 2016

@vipickering Is that not just because tabbing in safari is just for form controls by default? If you try ALT+TAB you should be able to tab links as well I believe.

paulmsmith commented Jul 21, 2016

@vipickering Is that not just because tabbing in safari is just for form controls by default? If you try ALT+TAB you should be able to tab links as well I believe.

@vipickering

This comment has been minimized.

Show comment
Hide comment
@vipickering

vipickering Jul 21, 2016

@paulmsmith @jonhurrell I've solved it. But it's a weird one.

Safari -> Preferences -> "press tab to highlight each item on a webpage".

That isn't turned on by default.
If you turn it on. It works. without it, you can only navigate using ALT+TAB as @paulmsmith has pointed out. Doesn't seem like an issue an AT tech user wouldn't already have solved.

vipickering commented Jul 21, 2016

@paulmsmith @jonhurrell I've solved it. But it's a weird one.

Safari -> Preferences -> "press tab to highlight each item on a webpage".

That isn't turned on by default.
If you turn it on. It works. without it, you can only navigate using ALT+TAB as @paulmsmith has pointed out. Doesn't seem like an issue an AT tech user wouldn't already have solved.

@jonhurrell

This comment has been minimized.

Show comment
Hide comment
@jonhurrell

jonhurrell Jul 21, 2016

@vipickering it is. You can change the system wide preferences to have the OS tab to all controls. It's very handy.

jonhurrell commented Jul 21, 2016

@vipickering it is. You can change the system wide preferences to have the OS tab to all controls. It's very handy.

@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 21, 2016

@joelanman My vote would be for option 2 as well.

This thread is full of gold and I'd like to give a big high five to all involved. On the surface a trivial issue but it's actually a prime demonstration of the complexities building accessible services presents us, it can be impacted by design, implementation and end-client (browser/AT) capability (or a combination of all).

@vipickering Thanks for the tip, that said, (and this is perhaps for another thread) as a developer I tend not to adjust defaults (such as the Safari/Mac OS tab controls) because my assumption is that the majority of users won't have done so either.. I'm sure @LJWatson and @aduggin could enlighten us more on that? or add it to the list of things we'd want to research as @joelanman alluded to.

paulmsmith commented Jul 21, 2016

@joelanman My vote would be for option 2 as well.

This thread is full of gold and I'd like to give a big high five to all involved. On the surface a trivial issue but it's actually a prime demonstration of the complexities building accessible services presents us, it can be impacted by design, implementation and end-client (browser/AT) capability (or a combination of all).

@vipickering Thanks for the tip, that said, (and this is perhaps for another thread) as a developer I tend not to adjust defaults (such as the Safari/Mac OS tab controls) because my assumption is that the majority of users won't have done so either.. I'm sure @LJWatson and @aduggin could enlighten us more on that? or add it to the list of things we'd want to research as @joelanman alluded to.

@aduggin

This comment has been minimized.

Show comment
Hide comment
@aduggin

aduggin Jul 21, 2016

Contributor

@joelanman option 2 - it will fix accessibility issues for some users and will not have a negative impact on any

Contributor

aduggin commented Jul 21, 2016

@joelanman option 2 - it will fix accessibility issues for some users and will not have a negative impact on any

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 22, 2016

If we choose option 1 from @joelanman
we end up with a link that behaves like a link but looks like a button. If we go with option 2 we get a button that looks like a button and behaves like a button for most people - so option 2 seems like the best choice to me.

LJWatson commented Jul 22, 2016

If we choose option 1 from @joelanman
we end up with a link that behaves like a link but looks like a button. If we go with option 2 we get a button that looks like a button and behaves like a button for most people - so option 2 seems like the best choice to me.

@gemmaleigh

This comment has been minimized.

Show comment
Hide comment
@gemmaleigh

gemmaleigh Jul 22, 2016

Contributor

Hi @jonhurrell,

Could you please open a PR to add your shim to the GOV.UK front-end toolkit.

That's the easiest way for it to be made available for everyone to use.

Ta!

Contributor

gemmaleigh commented Jul 22, 2016

Hi @jonhurrell,

Could you please open a PR to add your shim to the GOV.UK front-end toolkit.

That's the easiest way for it to be made available for everyone to use.

Ta!

@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 25, 2016

@LJWatson So for a Javascript shim, we don't need to trigger a click for a user pressing the 'enter'/'return' key? Just for user a without assistive technology pressing the 'space' key on an <a href="start.html" role="button">Start</a> ?

paulmsmith commented Jul 25, 2016

@LJWatson So for a Javascript shim, we don't need to trigger a click for a user pressing the 'enter'/'return' key? Just for user a without assistive technology pressing the 'space' key on an <a href="start.html" role="button">Start</a> ?

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 25, 2016

@paulmsmith
" So for a Javascript shim, we don't need to trigger a click for a user pressing the 'enter'/'return' key? Just for user a without assistive technology
pressing the 'space' key on an Start ?"

Right. The browser handles the enter key automatically because it recognises the link. We just need to add handling for the space key. Something like:


    obj.addEventListener('keydown', function(event) {
        if (event.keyCode ==13) {
            doThis();
        }
    });
    ```

LJWatson commented Jul 25, 2016

@paulmsmith
" So for a Javascript shim, we don't need to trigger a click for a user pressing the 'enter'/'return' key? Just for user a without assistive technology
pressing the 'space' key on an Start ?"

Right. The browser handles the enter key automatically because it recognises the link. We just need to add handling for the space key. Something like:


    obj.addEventListener('keydown', function(event) {
        if (event.keyCode ==13) {
            doThis();
        }
    });
    ```
@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 25, 2016

@LJWatson Thanks for the swift reply. :) I thought as much, was just double checking, I was seeing the event fired twice on 'enter' and wanted to check if I needed to do some handling of that.

paulmsmith commented Jul 25, 2016

@LJWatson Thanks for the swift reply. :) I thought as much, was just double checking, I was seeing the event fired twice on 'enter' and wanted to check if I needed to do some handling of that.

@paulmsmith

This comment has been minimized.

Show comment
Hide comment
@paulmsmith

paulmsmith Jul 25, 2016

With some input from @jonhurrell I've written a module. I'll do a Pull Request in the correct place and post a link here.

paulmsmith commented Jul 25, 2016

With some input from @jonhurrell I've written a module. I'll do a Pull Request in the correct place and post a link here.

@paulmsmith paulmsmith referenced this pull request Jul 26, 2016

Merged

Feature/anchor buttons #297

@robinwhittleton

This comment has been minimized.

Show comment
Hide comment
@robinwhittleton

robinwhittleton Jul 27, 2016

Contributor

Has anyone done any research around role="link" on buttons styled to look like links? There are a couple of them on Verify for example. Potentially we’d want to also add that to @paulmsmith’s shim?

Contributor

robinwhittleton commented Jul 27, 2016

Has anyone done any research around role="link" on buttons styled to look like links? There are a couple of them on Verify for example. Potentially we’d want to also add that to @paulmsmith’s shim?

@selfthinker

This comment has been minimized.

Show comment
Hide comment
@selfthinker

selfthinker Jul 27, 2016

Member

I thought it was acceptedly bad UX to use "button links" at all (i.e. links which are styled as buttons)? We're trying to emulate a browser behaviour for something we're pretending is something else for no good reason. That a button link sticks out more is not an argument because you only need to make a special design for an "action link" which can stick out in the same way while not being confused for a button.
(I know something to that affect has been said above, but I haven't read all the comments completely and wanted to give my 2 cents.)

Member

selfthinker commented Jul 27, 2016

I thought it was acceptedly bad UX to use "button links" at all (i.e. links which are styled as buttons)? We're trying to emulate a browser behaviour for something we're pretending is something else for no good reason. That a button link sticks out more is not an argument because you only need to make a special design for an "action link" which can stick out in the same way while not being confused for a button.
(I know something to that affect has been said above, but I haven't read all the comments completely and wanted to give my 2 cents.)

@joelanman

This comment has been minimized.

Show comment
Hide comment
@joelanman

joelanman Jul 27, 2016

Member

@selfthinker buttons are generally going to be more visually important than links. Visual priority is one of the most effective tools we have in making the site as easy to use as possible. We can investigate trying to make links more prominent, but I would not assume it's definitely possible. For now we have the situation where links are styled like buttons and we need to address the accessibility of that situation. To make such a large style change across gov without significant user research is not something we can do.

Member

joelanman commented Jul 27, 2016

@selfthinker buttons are generally going to be more visually important than links. Visual priority is one of the most effective tools we have in making the site as easy to use as possible. We can investigate trying to make links more prominent, but I would not assume it's definitely possible. For now we have the situation where links are styled like buttons and we need to address the accessibility of that situation. To make such a large style change across gov without significant user research is not something we can do.

@vipickering

This comment has been minimized.

Show comment
Hide comment
@vipickering

vipickering Jul 28, 2016

@selfthinker you are correct that it is bad practice to mark-up <a> tags as buttons.

However if we consider the general accepted paradigm for what a button is:

A button initiates an immediate action, such as form submission.

And what a link is:

A link triggers navigation to a different resource.

You can see the issue we have gotten in to. The start page is effectively performing both these actions as far as the user is concerned, despite the fact that technically it is only performing the link action.

It will take time for design and UX to process this new information and suggest a way forward in the future.

In the meantime (as a stop gap) @jonhurrell and @paulmsmith have put together a JS polyfill to patch the behaviour by instead capturing the space button keypress and pretending its a button. People are aware changing default browser behaviours via JS is bad and this solution isn't a long term solution, but mitigating existing broken behaviour while a new way is formulated.

vipickering commented Jul 28, 2016

@selfthinker you are correct that it is bad practice to mark-up <a> tags as buttons.

However if we consider the general accepted paradigm for what a button is:

A button initiates an immediate action, such as form submission.

And what a link is:

A link triggers navigation to a different resource.

You can see the issue we have gotten in to. The start page is effectively performing both these actions as far as the user is concerned, despite the fact that technically it is only performing the link action.

It will take time for design and UX to process this new information and suggest a way forward in the future.

In the meantime (as a stop gap) @jonhurrell and @paulmsmith have put together a JS polyfill to patch the behaviour by instead capturing the space button keypress and pretending its a button. People are aware changing default browser behaviours via JS is bad and this solution isn't a long term solution, but mitigating existing broken behaviour while a new way is formulated.

@selfthinker

This comment has been minimized.

Show comment
Hide comment
@selfthinker

selfthinker Jul 28, 2016

Member

buttons are generally going to be more visually important than links.

Buttons look as prominent as we make them. And links look as prominent as we make them. Neither looks prominent just by itself, styling make them that. Our buttons don't even look like buttons. (Although they have that in common with most other buttons on the vast majority of websites.)
I tried to come up with a visual definition of a button but couldn't because they are all styled so differently and don't have anything in common.

I appreciate that things are more complex due to the amount of (internal and external) apps involved. But it doesn't necessarily need to cost a lot of time to change things. If you concentrate on changing things iteratively, you could start changing the styling of "button links" just a little bit instead of coming up with a completely new type of "action link". And then you iterate on it and slowly change it more based on user testing etc. That would also make it easier to wean users off the old look without confusing them.

Member

selfthinker commented Jul 28, 2016

buttons are generally going to be more visually important than links.

Buttons look as prominent as we make them. And links look as prominent as we make them. Neither looks prominent just by itself, styling make them that. Our buttons don't even look like buttons. (Although they have that in common with most other buttons on the vast majority of websites.)
I tried to come up with a visual definition of a button but couldn't because they are all styled so differently and don't have anything in common.

I appreciate that things are more complex due to the amount of (internal and external) apps involved. But it doesn't necessarily need to cost a lot of time to change things. If you concentrate on changing things iteratively, you could start changing the styling of "button links" just a little bit instead of coming up with a completely new type of "action link". And then you iterate on it and slowly change it more based on user testing etc. That would also make it easier to wean users off the old look without confusing them.

@edwardhorsford

This comment has been minimized.

Show comment
Hide comment
@edwardhorsford

edwardhorsford Jul 29, 2016

Contributor

@selfthinker something else to consider - we want to have a consistent way for users to move from page to page. We do that by having a consistent primary call to action. It's important that the action looks the same on each page. We don't want it to change from being a button to being a link just because the internal html is different.

In the real world buttons can do anything. I personally find it odd that html seems to mandate that the metaphor of button can only mean one specific thing. Users don't care about the semantic meaning behind these two elements.

Contributor

edwardhorsford commented Jul 29, 2016

@selfthinker something else to consider - we want to have a consistent way for users to move from page to page. We do that by having a consistent primary call to action. It's important that the action looks the same on each page. We don't want it to change from being a button to being a link just because the internal html is different.

In the real world buttons can do anything. I personally find it odd that html seems to mandate that the metaphor of button can only mean one specific thing. Users don't care about the semantic meaning behind these two elements.

@jonhurrell

This comment has been minimized.

Show comment
Hide comment
@jonhurrell

jonhurrell Jul 29, 2016

@edwardhorsford I've seen evidence first hand that the GOV start pages confuse users, primarily due to styling the start link like a button, people believe they are already in the service/application process, when they aren’t. So although the call-to-action is clear, the context behaviour isn’t.
Further, sighted people using a service may not care about the meaning behind two elements, but those HTML elements are also interpreted by machines (assistive tech)—as I'm sure you’re aware, so I don't agree with the statement that users don't care. A choice of an element to describe an action or thing greatly impacts on this set of users.

jonhurrell commented Jul 29, 2016

@edwardhorsford I've seen evidence first hand that the GOV start pages confuse users, primarily due to styling the start link like a button, people believe they are already in the service/application process, when they aren’t. So although the call-to-action is clear, the context behaviour isn’t.
Further, sighted people using a service may not care about the meaning behind two elements, but those HTML elements are also interpreted by machines (assistive tech)—as I'm sure you’re aware, so I don't agree with the statement that users don't care. A choice of an element to describe an action or thing greatly impacts on this set of users.

@cjforms

This comment has been minimized.

Show comment
Hide comment
@cjforms

cjforms Jul 29, 2016

Start pages are complex thing anyway. Technologically, we have a view that the start page takes the user from the content-focused world of GOV.UK into the transaction. From a user point of view, the distinction isn't at all clear-cut.
We've got lots of evidence that users may need to:

  • check things before they start (see Harry Trimble's blog post about the check before start pattern) for more thoughts and links to other aspects of this problem),
  • make decisions before they start
  • begin the transaction and then set it aside to do other things
  • and so on.
    We've seen lots of evidence of user need for a call-to-action thing, exactly as @edwardhorsford pointed out.
    As @jonhurrell points out, users consider themselves 'started' at various points in their journey. Sometimes that's before our start page. Sometimes that's after our start page; they may elect to 'have a look at it' before they truly intend to start.

All of this points to the need for us to continue work like Harry's (creating and researching patterns) and Jon's (what start means, what users understand by it).

Meanwhile, it seems to me that we need to make the things we're currently using as well as they can at least for the moment.

So I'm voting for Option 2 as a stop-gap solution.

cjforms commented Jul 29, 2016

Start pages are complex thing anyway. Technologically, we have a view that the start page takes the user from the content-focused world of GOV.UK into the transaction. From a user point of view, the distinction isn't at all clear-cut.
We've got lots of evidence that users may need to:

  • check things before they start (see Harry Trimble's blog post about the check before start pattern) for more thoughts and links to other aspects of this problem),
  • make decisions before they start
  • begin the transaction and then set it aside to do other things
  • and so on.
    We've seen lots of evidence of user need for a call-to-action thing, exactly as @edwardhorsford pointed out.
    As @jonhurrell points out, users consider themselves 'started' at various points in their journey. Sometimes that's before our start page. Sometimes that's after our start page; they may elect to 'have a look at it' before they truly intend to start.

All of this points to the need for us to continue work like Harry's (creating and researching patterns) and Jon's (what start means, what users understand by it).

Meanwhile, it seems to me that we need to make the things we're currently using as well as they can at least for the moment.

So I'm voting for Option 2 as a stop-gap solution.

@edwardhorsford

This comment has been minimized.

Show comment
Hide comment
@edwardhorsford

edwardhorsford Jul 29, 2016

Contributor

@jonhurrell that sounds like more an issue with start pages than the whether it's a button or link. Note - we also use the links-as-buttons within services where form data isn't being collected, so it's not just a start page issue.

On users not caring - I'm not suggesting it's not important! If they see a button they should be able to action it as a button. I'm saying from their point it doesn't matter if a button is submitting data or not - it should act like it looks - it looks like this shim (and the role=button) gives us that.

Contributor

edwardhorsford commented Jul 29, 2016

@jonhurrell that sounds like more an issue with start pages than the whether it's a button or link. Note - we also use the links-as-buttons within services where form data isn't being collected, so it's not just a start page issue.

On users not caring - I'm not suggesting it's not important! If they see a button they should be able to action it as a button. I'm saying from their point it doesn't matter if a button is submitting data or not - it should act like it looks - it looks like this shim (and the role=button) gives us that.

@vipickering

This comment has been minimized.

Show comment
Hide comment
@vipickering

vipickering Jul 29, 2016

I'm saying from their point it doesn't matter if a button is submitting data or not

@edwardhorsford absolutely this does matter and users do care often.

  • What personal data did I just send by clicking that button?
  • Did I give consent to send it?

Many of the Gov services deal in sensitive information, users should always be crystal clear:

  • When they are handing data to a service.
  • What data that is.
  • Who is consuming that data.
  • The implications of submitting it.

If we can't sensibly differentiate between submitting data and navigating to another page we are muddying the waters with privacy and data issues.

vipickering commented Jul 29, 2016

I'm saying from their point it doesn't matter if a button is submitting data or not

@edwardhorsford absolutely this does matter and users do care often.

  • What personal data did I just send by clicking that button?
  • Did I give consent to send it?

Many of the Gov services deal in sensitive information, users should always be crystal clear:

  • When they are handing data to a service.
  • What data that is.
  • Who is consuming that data.
  • The implications of submitting it.

If we can't sensibly differentiate between submitting data and navigating to another page we are muddying the waters with privacy and data issues.

gemmaleigh added a commit that referenced this pull request Oct 11, 2016

Bump govuk frontend toolkit to 4.11.0
# 4.11.0

- Remove the GDS-Logo font-face definition (PR #272)
- Move the @Viewport statements to govuk_template (PR #272). If you
upgrade to this version of govuk_frontend_toolkit and you’re also using
govuk_template you’ll need to upgrade that to at least 0.17.2 to
maintain compatibility with desktop IE10 in snap mode.

@gemmaleigh gemmaleigh referenced this pull request Nov 7, 2016

Merged

Fix role click shim #347

@kylegach kylegach referenced this pull request Aug 2, 2017

Merged

WIP: [Link] component #211

5 of 5 tasks complete

@alex-ju alex-ju referenced this pull request Mar 5, 2018

Merged

Add button shim and setup Puppeteer #572

11 of 11 tasks complete

@36degrees 36degrees referenced this pull request Sep 11, 2018

Open

'Link' buttons #159

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment