Remove button role from start link #272
Conversation
Regardless of their visual look, start links don’t have button behaviour
|
Yep. This is listed in @aduggin's Accessibility fails example page too. |
|
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. |
|
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? |
|
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 indeed the aria attribute was added for Dragon concerns, it may well excluding old versions anyway: It's be great to have a Dragon licence to test some variants on. :( |
|
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'. As @jonhurrell this still presents an issue for older versions of Dragon, which don't understand the |
|
In the short term, I think we should revert this change. |
|
This is quite a complex issue - requires a long blog post to explain it fully. The short version The medium version 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 |
|
Hi @edwardhorsford, Downside is mentioned above, i.e.
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 For reference, Bootstrap recently added commentary regarding |
|
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.
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. |
|
@aduggin If you're considering scenarios with non-ARIA support you can instead start with an No No shims, just HTML as it was intended. |
|
@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. |
|
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 be semantically correct, the visual priority might be wrong, and the same the other way round. |
|
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. |
|
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 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! |
|
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: 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.
|
|
Hi all, When I raised this initially, my thoughts were as follows.
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:
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. |
|
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. 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! |
|
Thanks @LJWatson, Just need a volunteer to add the space-bar shim! Then we pass the accessibility fail mentioned by @paulmsmith above: |
|
Where's the best place to start putting up some test examples (quickest)? |
|
@jonhurrell maybe just http://codepen.io / http://jsbin.com for now? Then maybe @aduggin can incorporate them into the sandbox for wider consumption later? |
|
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 |
|
I'm somewhat confused by this discussion. Why do links have role="button" On Wed, 20 Jul 2016, 18:50 Léonie Watson, [email protected] 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.
|
|
Thank you for the explanation however whilst I appreciate that visually On Wed, 20 Jul 2016, 21:44 chrismoorembe, [email protected] wrote:
|
|
We use code that (simplified) looks something like this: 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 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. 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 |
|
I wrote a little handler for this last night: Update: Moved to JSBin. |
|
@jonhurrell |
|
@LJWatson Great, that'll do. |
|
@paulmsmith 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: |
|
@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. |
|
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. |
|
Has anyone done any research around |
|
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. |
|
@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. |
|
@selfthinker you are correct that it is bad practice to mark-up However if we consider the general accepted paradigm for what a button is:
And what a link is:
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. |
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 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. |
|
@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. |
|
@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. |
|
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.
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. |
|
@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 |
@edwardhorsford absolutely this does matter and users do care often.
Many of the Gov services deal in sensitive information, users should always be crystal clear:
If we can't sensibly differentiate between submitting data and navigating to another page we are muddying the waters with privacy and data issues. |
# 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.
This means the accessibility shims for buttons are loaded correctly. Further details here: alphagov/govuk_elements#272 (comment)
By keeping
role="button"on start-button links:Unfortunately:
Why? A
keyupevent 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
roleas this is probably a mistake.Thanks