Learn the Difference and When to Use Them
3/21/2019 11:46:54 AM
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.
A button is the perfect element for:
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.
The design of the button must have sufficient color contrast, and the button must not disappear in high contrast mode.
The button must properly expose itself to accessibility APIs using the appropriate State, Role, and Value for the object.
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.
Would you like to learn more about the accessibility work being done by Minnesota IT Services and the State of Minnesota? Once a month we will bring you more tips, articles, and ways to learn more about digital accessibility.