Links VS Buttons: A Perennial Problem
Once a friend told me about a site and asked me to sign up to do some course. He told me that “Sign up” was a link that I needed to click to register myself on the site and do the course. I pulled the links list in my screen reader and searched for some time. Alas! I found nothing. Out of frustration and desperation, I tried for buttons and there it was – “Register button”.
Now, was my friend wrong in guiding me? Or was the screen reader wrong? Or was I wrong in understanding his instruction? Well, it could be either one of them; all of them or none of them at all.
My friend is visually right as he sees the element that looks like a link. The screen reader is technically right as somewhere the code says that it is a button. The only problem is that a button is styled as a link but coded as a button.
A link or a button: Does it really matter?
When an element is operable, it doesn’t matter in a normal circumstance. But certainly it matters to assistive technologies and the people who use them.
When and where do we use a link or a button?
Usability experts offer the following explanation in this regard:
This is just usability. When it comes to accessibility, when an element looks like a button or link, use the respective markup to mark its role. That would help the assistive technologies like screen readers and speech recognition software like “Naturally Dragon” to expose appropriate roles to the users.
Use native markup
An anchor <a> gives the following advantages:
Buttons <button>:
At any point, native markups have much more to offer to the developers and the users than the custom controls.
Points to remember:
Link or button, let that be inclusive and convey the same meaning to everyone.
This is just an attempt to put things to perspective. If you have comments, suggestions and/or opinions, we welcome with open hands!
Hello, Sathish Kumar! I highly familiar with HTML and CSS but sometimes have questions about link and button – How states could i use in mobile screens? Using states :active and :focus for link it’s enough? And :hover using only desktop screen.
What is your opinion?
Thank you for the question. That’s correct. Hover is used only on desktop screens.
Hi! It would be great to provide an updated article that includes native mobile in your example and not just web – the premise is still correct, but should include the caveat that selecting the native app button may navigate the user within the app, but a link takes the user to an external site. Would you agree?
Hello Jamie,
I agree, will get the article updated. Thanks!
Hi,
I have one question regarding the tertiary button which appears as a link but operate as a button where button tags are used but visually it seems link. Other than SR user for everyone it seems to be link which sets incorrect expectation, so what can be do in that case.
Hi Vaibhav,
Thanks for the comment. As mentioned in the blog post, we need to prioritize functionality and the design team needs to design buttons and links appropriately.
If something appears to be a link but functions as a button, it may confuse users who rely on visual assistance from screen readers. I recommend speaking with the design team and educating them on this issue.
As a developer you would code to the function. As an accessibility professional you would have a conversation first with the designer or better, more widely with the design team, about the pattern of using blue text to indicate a button or modal. Other items like a tooltip/more information icon could be used, not just a big button, for example if the action is to open a modal. As a designer you’d think about the various ways someone might access the content that the button goes to, and consider whether blue text is the best indicator. As a PO, there’s the question of why this “linking” of information is needed. What is the requirement? Why is it there? Is it necessary to take the user somewhere else?
Lastly, in a web vs mobile app space, there are times when a webpage makes sense as a functional link whereas in the app for the same function you might link to the same webpage in a browser. But if the action opens a modal or goes to a different section of the same app, many a11y SME’s follow the idea that any navigation action that keeps the user in-app is functionally a button; I’ve seen some variation on this though, which is maybe why this issue comes up regularly in apps.
Thank you for bringing up the importance of considering accessibility in the design and development process. It’s crucial to have conversations with the design team, question the requirements, and consider different ways users might access the content. It’s also important to consider the difference between web and mobile app approaches. Your insights are much appreciated.