Add example for links styled as buttons.

[edwardhorsford]

The design system / button macro supports links styled as buttons - but this isn't documented as an example. The start now example is one such case, but unless a team knew it was a link, they are unlikely to find it.

For content only pages with a 'continue' button, I'd normally expect teams to use a link - but there's no example of how to do this. The page makes no mention of links.

I've seen multiple teams try to reinvent the wheel by making this happen, or trying to shim the correct behaviour - all things the design system supports.

[hannalaakso]

@edwardhorsford Thanks for raising this. Would you be able to point us to an example of such a content page on a service? This would help us to understand the use cases.

[edwardhorsford]

Sure! Some examples:

GOV.UK Verify

GOV.UK cookie notice

The first button is a button, the second an anchor

Product safety database (my service)

Passport renewals

(these are technically buttons wrapped in a form - but it's a similar use case of having a page of guidance with a button linking to a page. Possibly they've done it like this because they wanted to use the macros and didn't realise you could do links styled as buttons?

Carer's allowance

Again, this is a button wrapped in a form - but similar use case.

[edwardhorsford]

Visas

Apprenticeships

[joelanman]

Technically a single GET button wrapped in a form is valid, but it's very weird. Conceptually forms are for submitting data and a single button with no kind of input is not doing this.

[edwardhorsford]

Childcare service

Vehicle enquiry service

[edwardhorsford]

GOV.UK again

[edwardhorsford]

I'll stop adding examples now - at least 50% of services I've checked have a link-button within the first 4-5 pages of the service. It's really common.

[hannalaakso]

Thanks @edwardhorsford this is really helpful 👍

[terrysimpson99]

I'd welcome explicit guidance on this. I'd heard people talk about this from time to time but didn't grok it. Now I've started investigating, I see that our service uses [looks like a button 'Print this page'] on 'Check your answers' then two pages later on the confirmation page uses [looks like a link 'Download a copy']. They both open a pdf viewer.

[edwardhorsford]

@terrysimpson99 could you share a screenshot? thanks!

[terrysimpson99]

Example of [looks like a button: 'Print this page]

Example of [looks like a link: 'Download a copy of this form']

[peteryates]

Has any research been done on how people use links?

From a material honesty point of view, links and buttons are very different. I might middle click a link to open it in a new tab, right click it to bookmark it or copy its location, drag it to my desktop for later perusal. None of these will work if it's a button, and I won't know which options are available to me if it's a link disguised as a button.

[joelanman]

just to say I've come across this in a codebase - someone has just added the button class to links. It looks like it works but its inaccessible. So I think we need explicit guidance on this

[edwardhorsford]

This continues to get asked about on the cross government slack - users ask how to achieve this, thinking the design system doesn't support it.

[CharlotteDowns]

@edwardhorsford I'll pick this up with the team again and see if we can get something in the guidance to either show users how it can be supported or provide reasons why we suggest not to do this :).

[CharlotteDowns]

I think this is one where the Design System want to currently edge on the side of caution. Accessibility experts within our wider organisation differ in opinion on whether displaying links visually as buttons is an accessibility concern for users. I think this is due to a difference in the behaviour of links, buttons and what the user expects.

I'll update this thread accordingly if anything changes or if I gather any new information.

[edwardhorsford]

@CharlotteDowns does that mean the team is reconsidering start buttons too?

For the examples documented in this thread, does the team have recommendations for alternate markup? Possibly a button inside a form, doing a GET request as @joelanman suggested above?

I should note that nearly all services have examples of this - it's a very common thing. If it's an accessibility issue, then it would be great for the DS to offer suggestions for how to have buttons where you aren't actually submitting any data.

--

FWIW whilst they do behave differently, I'm not aware of any user research that has found the usages documented in this thread to be a any issue - they look (and behave!) like buttons because that's what makes the most sense for the journey.

[joelanman]

This seems similar to 'disabled' state - we caution people about the risks but it is available and documented. As Ed says, if the decision is to never use links styled as buttons thats a big change and we'd need to remove start buttons. The current situation is they are not documented so people implement them in a way that is not accessible (just adding the govuk-button class).

[edwardhorsford]

Agree that it would be a big change! One that I don't think is warranted - start buttons have been like this on GOV.UK for 10+ years now. I'm not aware of us ever finding issues with them in this regard, nor links-as-buttons in the usage described here. So unlike 'disabled' buttons, that have known downsides, I don't think there are any known downsides or actual risks in having these.

[selfthinker]

FYI, discussion from 2016 about the same subject.

[querkmachine]

I still question whether it's something we'd want to encourage in documentation. Whilst it's not something that seems to have troubled many users, we know that the two are not equivalent in function, and it's not really in our interests (or arguably the interests of user's mental models, assistive technologies) to conflate the two.

If we really wanted to close off the exception that is the Start link-button, there are definitely link treatments that convey similar call-to-action vibes; publishing's action link component comes to mind.

[joelanman]

in terms of mental models, the use of something that looks like a button for main calls to action is extremely widespread across the web, and its hard to point to actual problems this causes for users

As Leonie says in the other thread:

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).

[joelanman]

I think we should document the design system as it exists, which is that it has accessible links-styled-as-buttons, covering any concerns we may have in documentation, as we do other elements. People currently do it, but in an inaccessible way as it is not documented, this is a bad outcome for users.

Separately we can investigate removing links styled as buttons going forward, if people want to do that. But the current situation is halfway between the two.

[edwardhorsford]

I don't think it's a case of not troubling many users - I don't think it's troubled any users.

In the examples I shared above, they are equivalent in function - both in terms of how they work, and in how they present to assistive technologies. For a user of a screen reader, it'll present exactly as it looks - which is a good thing!

About the only actual difference is you can command click the link buttons to force new tabs, where you cannot on real buttons. But having this undocumented extra thing does not cause issues. Indeed, for the usages above (often interstitial pages), it would be odd for users to attempt to open them in new tabs.

[selfthinker]

Actual (albeit small) problems that I can think of:

• Users who change the styles would see a link instead of a button. Although I can imagine that might not be a big problem as these buttons are fine as links. It would only be confusing if they saw it in both versions (like in two different browsers with different settings) or are talking to people about this link while others see a button.
• Users who are confused because the component doesn't behave as this type of component usually does. For example, you can right-click on that button link and do lots of things with it, like opening it in a new window, copying the URL or copying the text. I suspect that is much more of a problem the other way around, though. Because a button that looks like a link loses expected functionality, while a link looking like a button gains some.

[querkmachine]

By mental models, I was indeed foremost thinking of links being openable in new tabs, whereas buttons are not. That is a thing that's tripped me up many a time, on websites that liberally mix the two metaphors.

However, there are a few other ways that they are functionally different:

• If I see something resembling a button in the context of a form, I'm going to assume clicking it is going to submit data to a server, because that's what buttons in forms tend to do.
• Buttons can be activated by pressing space, whereas links cannot. We actively polyfill for this scenario in JS, I presume because this did cause issues at some point.
• Some ATs use alternative keyboard shortcuts to activate buttons, which we haven't polyfilled and won't work for links styled as buttons.
• Anecdotally, I'm curious whether voice control will correctly recognise a command to click a "button" that is actually a link.

This is probably just rehashing the points from years ago, though.

[edwardhorsford]

@querkmachine

For 3 & 4, my expectation would be that role=button will mean the AT do treat them as buttons. And if not, I believe that would be a bug with the AT. We've definitely tested start buttons with voice control before, etc.

[jimbali]

It works if you remember to add govuk-button as well as govuk-button--inverse, as I just found out 😅