When designing a web interface the most obvious way to allow user to do something is providing him with a hyperlink:

 Click <a href="/Actions/DoSomething">here</a> to do something

when the user moves the cursor over the here word the cursor changes and their browser shows the target link somewhere near browser window bottom so that it's clear where it leads.

However the hyperlink causes a GET request when clicked and that's not always the best choice for cases where following a link causes any changes (such as making a purchase or initiating a money transfer) because the user might save the link and unintentionally reuse it later.

So a POST request might be a better choice (the server will reply with HTTP 302 Redirect if it wants the user's browser to move to another URI afterwards). This:

<form method="post" action="/Actions/DoSomething">
            style="text-decoration:underline; background:none;border:none;
            id="someid" type="submit" value="here" />
      to do something.

crafts an input element which makes a POST request when clicked. With this styling it looks like a link - it's underlined, cursor turns into arrow when placed above the element and when it's clicked something happens.

The only obvious difference is the browser doesn't show the Actions/DoSomething path as it did with a hyperlink.

Is there any problem with this minor difference? Will this "input as hyperlink link" be as good as ordinary hyperlink for users?

  • 1
    I'll go into it in an answer if no one else has by the time I'm off work. But screen reader users will not understand what is happening and crawlers will not follow that link for SEO purposes.
    – DasBeasto
    Commented Nov 14, 2016 at 14:20
  • @DasBeasto Screen readers are surely something to take into account.
    – sharptooth
    Commented Nov 14, 2016 at 14:23

3 Answers 3


Yes, it will probably be impossible to make the behavior of a button exactly like the behavior of a link

Trying to get your button to behave and appear exactly like a link on all the platforms you are interested in is likely to be a very deep rabbit hole.

For example, hovering over a link in many browsers makes the target appear, while hovering over a form button does not.

POST does not solve your bookmarking problem

Plus, it's not exactly good if the user bookmarks the target page of your form, either. Maybe you can differentiate between a get and post request, and display something better than an error page. But if the user bookmarks that URL, they are probably interested in referring back to the particular context where they bookmarked it, and you will be unable to provide it.

A JavaScript-initiated AJAX call is probably best practice here

Something like this will look look and act more like a link, because it is one.

<a href="/For/display/only" id="someid">here</a>

// jQuery AJAX example
$("#someid").on("click",function(e) {

    $.post("/Actions/DoSomething", function(e) {
        e.preventDefault(); // Do not load the href
        alert("Successfully sent");
        // disable the link and change the change display

It will appear as ordinary hyperlink for normal users, but for users with disabilities who use screen readers it will be a submit button. Screen readers read HTML not CSS (except a few: speak, display) so it doesn't matter how you style the element on screen the readers will read HTML eventually..


How Does Your Page Look To A Screen Reader?


I'm not sure the screen reader is the problem. Although we have had 'link buttons' for some time, I think the issue comes down to the primary action.

Buttons are the primary call to action, whereas link buttons often perform a secondary action, such as a password reminder. I would be concerned that your users wouldn't interpret the interface as you intend.

Perhaps some user testing or A/B testing would assist you?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.