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:

• Use buttons when the user- action causes a change in either back-end or the front-end of the website. For example, submitting a form, opening a pop-up or a modal or a pannel on the same page.
• Use links when the user-action doesn’t affect the website at all. In this, the users are just readers or spectators of the site. For example, to navigate to the next page or an external source after viewing the content of the page.

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:

• Navigates to new pages
• Allows browser refresh
• Supports opening in new tab/window
• Provides with default tab focus with (href) attribute
• Supports in-page skips with internal href attributes
• Provides with implicit role (link role) to sscreen readers
• Shows active, visited, hover and focus.

Buttons <button>:

• Have default keyboard focus
• Are activatable by space key
• Provide with implicit role (button) to screen readers
• Can be disabled
• Submit and reset forms, open modals and expand/collapse panels.

At any point, native markups have much more to offer to the developers and the users than the custom controls.

Points to remember:

• Design with best usability and accessibility practices
• Complement the style with the appropriate and semantically correct code
• Ensure whatever element you use, the implicit role matches with the element’s look
• Use ARIA roles like (role=button” or (role=”link” to maintain the semantic role when all efforts to maintain native markup fail.

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!

About sathish kumar

I am a Senior Accessibility Consultant, working at Deque Software PVT LTD. My experience spans for seven years across domains such as travel, education, eCommerce Healthcare etc. bringing digital accessibility into websites, mobile web, Android and iOS native apps, PDFs, Word documents and PowerPoint presentations. I have presented papers at international conferences; spoken at different meet-ups and forums and mentored teams for a11y competitions.