Is it bad accessibility practice to style a link like a button?

Question

In my case, add something like className: "btn btn-default" to a react-router Link .

Like so: <Link className="btn btn-default" to={linkUrl}>Go!</Link>

Would tha tripped people who use assistive technologies to view a site?

Answer 1

Some general tips on when to use an <a href> versus a <button> or <input type="submit"> :

• If the user is going to a new page (or anchor on the page), use a <a href> ( spec ).
• If the user is changing a state on the current page, use <button> ( spec ).
• If the user is submitting a form, use <input type="submit"> or <button type="submit"> ( spec ).

I caution against changing the default role of an element with the role attribute, as that can ultimately cause some confusion and potentially conflict for some assistive technology. These also violate the first and second rules of ARIA use.

Consider the keyboard experience as well. A hyperlink ( <a href> ) can be fired by pressing the enter key. But a true <button> can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. Users of some assistive technology will expect behavior based on the element used.

I think it's also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).

So start with the right element for the task using the list above, then style it to look however you want.

Answer 2

tl;dr best practice is to make things look like they act but you may not have the luxury, so now what role should the element have?

You should style and role your links and buttons so they communicate this to the user. This is general good usability practice.

However, that only works in a world in which branding and marketing people don't have any say. Have you ever heard the argument "we need to make that link more prominent so visitors click on it more..." This is where links start turning into these monsters that are no longer identifiable by how they look AND act.

So now you have stumbled on one of the great debates of accessibility: should something have the role that matches how it behaves or should it have the role that matches how it looks?

A link is an element that directs the browser to another location (either another page, or another location on the same page). This is how it was designed.

Buttons on the other hand are designed to interact with the page or submit data.

The complication is, when you have a link that looks like a button and a blind user phones support and the support person says "click the X button" and the screen reader announces Y link (because the text alternative for the button is wrong), then the blind user gets really frustrated because they can neither find a button nor something that matches the X.

However, if you are trying to do accessibility the right way and your link text matches the visible information for the element, then IMO you should always have a role on the element that matches the way it behaves.

In your specific example, someone using a speech recognition system like Dragon would have difficulty clicking the link because they might use a command like "buttons" to list all the buttons and not see the element they are expecting. This user would then have to guess that it is in fact a link, or use mouse targeting to interact with the element.

Answer 3

The points raised by aadrian and unobf above are accurate and well stated. There is still another reality which cannot be avoided that forces the developer's hand.

Designers frequently deemphasize one or more actionable element in a group , a delete button for example, because it is used less frequently or catastrophic if used in error. Research suggests catastrophic errors can be reduced using this strategy.

Since many seasoned professionals demand that the markup for the control matches the presentation , the developer's first instinct may be to mark up the delete control as a link.

Assistive technologies for the visually impaired such as Jaws rely on lists of controls of a single type. Surveys indicate this strategy is utilized by the visually impaired fairly frequently.

With these accessibility realities in mind, it is a very bad practice to mark up a list of actions as some buttons with one or more links for actions such as delete. The visually impaired user will likely not associate the link with the buttons and may miss the link entirely.

This reality essentially forces the developers hand. If the design calls for a delete link in a list of buttons, the developer must mark up the link as a button, even though the keyboard navigation will not align perfectly for the sighted user.