Inaccessible button patterns.

The problem

A <div> styled to look like a button is one of the most common accessibility anti-patterns. To a sighted mouse user it works fine; to everyone else it’s broken—it’s not in the tab order, doesn’t respond to Enter or Space, and isn’t announced as a button. Native <button> gives you keyboard operability, focus, role, and state for free (WCAG 4.1.2); reaching for a div trades all of that away for nothing.

The fix

<div class="btn" onclick="submit()">Submit</div>
<span onClick={handleClick} style={{cursor:'pointer'}}>Cancel</span>

<button type="submit" onClick={submit}>Submit</button>
<button type="button" onClick={handleClick}>Cancel</button>

Step by step

1. 1Use <button> for actions and <a href="..."> for navigation — never use <div> or <span>.
2. 2Always set type="submit" or type="button" to prevent unexpected form submission.
3. 3If you must use a div (e.g., in a legacy system), add: role="button", tabindex="0", and handle both click and keydown (Enter and Space).

Common mistakes

• ×Using <div> or <span> with onclick as a button.
• ×Forgetting type="button" inside a form, causing accidental submits.
• ×Re-implementing a div “button” but only handling click, not keydown.
• ×Disabling a button visually with CSS while leaving it focusable and clickable.

How to test for it

• Tab to the control—a real button is reachable and activates on Enter and Space.
• Check the accessibility tree shows role “button” with a name.
• Run an automated scan for clickable elements that aren’t real controls.

In your framework

// Correct — native button
<button type="button" onClick={handleClick}>Cancel</button>

// If forced to use a non-button element:
<div role="button" tabIndex={0}
     onClick={handleClick}
     onKeyDown={e => ['Enter', ' '].includes(e.key) && handleClick()}>

Questions