20% Off My Easy-Peasy Proposal with the Coupon Code 20OFF (Now - April 30th)

Accessibility Weekly

Divs Are Not Buttons

Published:

amber-200

Amber Hinds

Equalize Digital

Amber Hinds is the CEO of Equalize Digital, Inc., a Certified B Corp specializing in WordPress accessibility, maker of the Accessibility Checker plugin, and lead organizer of the WordPress Accessibility Meetup and WP Accessibility Day conference.

Week 26

We’ve previously discussed the differences between buttons and links and when to use one or the other. This week’s post is about one of the most significant accessibility problems that I see when auditing websites: buttons coded as divs, spans, or some other non-focusable element.

Why Divs Don’t Make Good Buttons

Using a <div> tag instead of a <button> tag when coding buttons can cause many accessibility problems for people who cannot use a mouse, either due to mobility challenges, limited vision, or situational limitations.

The <button> tag has built-in semantics and functionality specifically designed for creating interactive buttons, which divs (and spans) do not. Here are some problems that can arise from using a div to code a button.

Divs Are Not Focusable

Divs are not keyboard focusable out of the box. If you go to the front end of a website and hit the tab key, you should be able to navigate through all of the interactive elements on the page, including:

  • carousel next/previous buttons or dot pagination buttons.
  • tabs.
  • accordions.
  • buttons to open and close mobile menus.
  • popup or modal controls.
  • … and more.

These are all examples of buttons that should be coded with a <button> tag and frequently are not. If you hit the tab key and it skips entirely over a button, inspect it, and you’re likely to find that it’s a div that has just been styled to look like a button rather than coded as one.

Divs Can’t be Interacted With

Divs are meant to be containers, not interactive elements. Unless you write specific JavaScript event handlers for mouse clicks, touchscreen taps, and keyboard presses, divs will do nothing when users try to interact with them.

Most developers who use divs instead of button tags remember to add the “onclick” interaction for mouse users, but they fail to consider keyboard-only users, making their buttons nonfunctional without a mouse.

Divs Don’t Have Semantic Meaning

Screen readers and other assistive technology don’t interpret divs as buttons, and as such, even if the div is made focusable and interactive, they will not announce that the div is a button to users. This means a user might not even realize that the element is interactive because they were not told it was interactive.

Can you make a div into an accessible button?

Yes, it is possible to make a <div> behave like an accessible button by combining ARIA attributes and JavaScript. Ben Myers has a great article, “How (Not) to Build a Button,” that walks through making a div into an accessible button.

Essentially what you have to do is:

  • Add a tabindex to make it keyboard focusable.
  • Add CSS focus styles to show when it is being focused.
  • Add JavaScript key press events for the Enter key and Space bar.
  • Add a role attribute to tell screen reader users it’s a button.
  • Add additional aria attributes to indicate if it’s a toggle button, tab, or button that expands or collapses something.

As you can see, it is technically feasible to make a div into an accessible button, but it’s also a lot of work and extra code you don’t have to write if you just use a <button> tag as the HTML gods intended.

Div-Button Failures in WordPress

I wish I could say that it wasn’t common in WordPress for buttons to be incorrectly coded as divs, but unfortunately, that is not the case. This is one of the most common problems I see in plugins and when auditing websites built by even senior developers at large agencies.

How to Find Incorrectly Coded Buttons

Unfortunately, incorrectly coded buttons is an example of an accessibility problem that an automated accessibility testing tool like my plugin, Accessibility Checker, cannot find. It’s not always clear if something in a div is supposed to be a button without manual testing.

If you’re trying a new plugin or theme for the first time, test that you can use all of the buttons with your keyboard alone. You should be able to reach each button with the Tab key and then should be able to trigger it with both the Enter key and Space bar. If you listen to buttons with a screen reader, they should be announced as buttons.

What To Do If You Find A Div “Button”

If you find buttons that have been coded as divs that are in a plugin or theme you don’t control, send them this article. 😆

In all seriousness, if there are buttons that are not coded as actual buttons, that may be a reason not to use a plugin or theme. Ideally, if you report the problem to the developer, they will remediate the element either by replacing it with a proper button or by following all the steps above.

If the developer doesn’t want to fix the element, then you may be able to remediate it with JavaScript, though that is a less ideal solution both because of performance and also the likelihood that a future update could break your JavaScript patch.

For this reason, I’d consider finding a different tool if the original developer isn’t amenable to fixing it.

Additional Resources

Join the Conversation!

There's a dedicated thread on this post inside of The Admin Bar community. Join in on the conversation, ask questions, and learn more!

Group Thread
amber-200

Amber Hinds

Equalize Digital

Amber Hinds is the CEO of Equalize Digital, Inc., a Certified B Corp specializing in WordPress accessibility, maker of the Accessibility Checker plugin, and lead organizer of the WordPress Accessibility Meetup and WP Accessibility Day conference.

Through her work at Equalize Digital, Amber is striving to create a world where all people have equal access to information and tools on the internet, regardless of ability. Since 2010, she has led teams building websites and web applications for nonprofits, K-12 and higher education institutions, government agencies, and businesses of all sizes. Through this journey, she learned about the importance of making websites accessible to everyone, and it has been her passion to bring awareness to accessibility and make website accessibility easier, ever since. 

Brought to you by:

Make your WordPress website accessible and ensure all people have equal access to your products or services, regardless of ability. Reach more customers, reduce liability, and increase conversions.

Come Join Us!

Join the #1 WordPress Community and dive into conversations covering every aspect of running an agency!

Kyle Van Deusen

Community Manager

More from Accessibility Weekly

Week 51

How Accessible is “Accessible Enough”

In an ideal world where clients have unlimited budgets and everything is custom, every website would …

Week 50

How to Sell Accessibility in New Builds

Creating websites that prioritize accessibility is no longer just a best practice—it’s a business must, especially …

Week 49

Accessibility in Web Development Contracts

Whether you’re running an agency or freelancing, having a clear contract for your web development and …