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!