By: Kim Wee

Part of my job as webmaster and accessibility coordinator for Minnesota IT Services (MNIT) partnering with the Minnesota Department of Education includes testing websites and applications for accessibility. An ongoing issue that I continue to see is styling links, spans, or div tags as buttons.

From the designer perspective, this seems innocent enough, but is it? With Accessible Rich Internet Application (ARIA), the developer can change a link’s behavior by adding the role aria=button so the element displays in a list of form elements when using screen reading software. If using role=button instead of the semantic button element, you will also need to make the element focusable and define event handlers for click and keypress events, including the Enter and Space keys.

Even if you do all this, how does this affect other assistive technology (AT) users? Will this last the test of time? Let’s take a closer look.

Reference from Marcy Sutton

Buttons natively:

• Receive keyboard focus by default
• “Click” with the Space key
• Submit form data to a server
• Reset a form
• Are disabled with the disabled attribute
• Inform browsers and assistive technology with the implicit button role
• Show :focus, :hover, :active, :disabled

A button is the perfect element for:

• Opening a modal window
• Triggering a popup menu
• Toggling an interface
• Playing media content

Links:

• Create hypertext
• Navigate the user to a new page or view
• Change the URL
• Support page jumps with internal href attributes
• Are focusable by default with the href attribute
• Register a click with the Enter key
• Have the implicit link role
• Can’t be disabled like buttons
• Allow opening in new window/tab
• Show :link, :visited, :focus, :hover, :active

More to Keep in Mind

Device Independence

Users must not be required to use any specific device to operate the control. In other words, users must be able to gain focus on it and activate it using a keyboard or voice commands as well as a mouse.

Color Contrast

The design of the button must have sufficient color contrast, and the button must not disappear in high contrast mode.

Name, State, Role, Value

The button must properly expose itself to accessibility APIs using the appropriate State, Role, and Value for the object.

• State – What is it doing? Implicitly, what else can it do?
• Role – What type of object is it?
• Value – What value does it have?

How to Choose Between Link and Buttons

1. Will this control be used to initiate an immediate action? Use a button!
2. Is the action to navigate to another page? Use a link!

If you choose to not use the semantic button tag and create something that looks like a button using a link, span or div tag and don’t add all the stuff to make it function as a button, you run the risk of not meeting the WCAG 2.0 4.1.2 Name, Role, Value, Level A guideline.

In closing, think about this - If a screen reader user calls tech support and gets instructions to “click the button” in your User Interface that’s really coded as a link, they may have trouble finding it. Also, consider voice interfaces: if you say a command to click a button but it’s really coded as a link, that element may not work.