• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Logo for DigitalA11Y

Digital A11Y

Your Accessibility Partner

  • About
    • Bio
      • Conference Speaking
      • Videos
      • mentions
  • Articles
  • Resources
    • WAI-ARIA
    • WCAG
    • Cheat Sheets
    • A11Y Blogs
    • A11Y Toolkit
  • Contact
You are here: Home / Design / Links VS Buttons: A Perennial Problem

Links VS Buttons: A Perennial Problem

Last Modified: May 17, 2018 by sathish kumar 2 Comments

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!

Share A11Y Love

  • Twitter
  • LinkedIn
  • Facebook
  • Reddit

More Accessibility Articles

Filed Under: Design Tagged With: A11Y, accessibility, buttons, design, linnks

Reader Interactions

Comments

  1. Roman says

    June 6, 2018 at 11:38 am

    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?

    Reply
    • sathish kumar says

      June 22, 2018 at 5:53 pm

      Thank you for the question. That’s correct. Hover is used only on desktop screens.

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Get Digital A11Y in Your Inbox

Recent A11Y Articles

  • WCAG 2.1 Checklist
  • A Sneak peek into WCAG 3.0 First Public Draft
  • Understanding SC 4.1.3 Status messages
  • Understanding SC 2.5.4 Motion Actuation
  • Understanding SC 2.5.3 Label in Name

Recent Comments

  • Isaac Williams on Digital Accessibility Companies Roundup
  • Vaibhav Mishra on Understanding SC 3.3.1 Error Identification
  • Vaibhav Mishra on Understanding SC 1.3.2 Meaningful Sequence
  • Donal Rice on Digital Accessibility Companies Roundup
  • Rajath on A Sneak peek into WCAG 3.0 First Public Draft

A11Y Categories

  • Design
  • Events
  • HTML
  • IOS
  • Mobile Accessibility
  • News
  • Tools
  • WAI-ARIA
  • WCAG
  • Web Accessibility

  • Privacy Policy
  • Sitemap
© 2021 Digital A11Y