Type something to search..

Ai and wcag

AI test: Can AI detect a div pretending to be a button?

Can AI find a clickable div on a live website? I tested it with Claude Code and Playwright. Here are the results, the limitations, and the tools you need.

Can AI detect a div pretending to be a button?

A <div> with an onclick. Looks like a button. Does something when you click it. But press Tab and nothing happens. Enter? Nothing either.

For a keyboard user, this button doesn’t exist.

This is the number 1 keyboard issue I encounter in audits (WCAG 2.1.1). And the easiest to fix: replace the div with a <button>. But can AI find this problem too? And not just in a code snippet, but on a real, live website?

Test 1: Code analysis

I gave Claude the following HTML, without hints:

<div class="btn-primary" onclick="addToCart(123)">Add to cart</div>

My prompt: “What accessibility issues do you see in this code?”

Result

Claude recognized it immediately:

“A <div> with an onclick handler is not keyboard accessible by default. It cannot be reached with Tab, it has no button role, and pressing Enter or Space will not activate it.”

It links the problem to WCAG 2.1.1 (Keyboard) and gives the correct solution: use a <button>.

But I gave AI a piece of code. That’s the easy version. Can AI also find this when you only have a URL?

Test 2: Testing a live website

Can AI visit a web page and detect this issue? Yes, but not by itself. AI needs a browser.

With Playwright (a browser automation tool), Claude Code can open a real browser, visit a web page, and inspect the DOM. That looks like this:

const { chromium } = require('playwright');

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage();
await page.goto('https://example-webshop.com');

// Find all elements with onclick that aren't buttons or links
const problems = await page.evaluate(() => {
  const elements = document.querySelectorAll('[onclick]');
  return Array.from(elements)
    .filter(el => {
      const tag = el.tagName.toLowerCase();
      return tag !== 'button' && tag !== 'a' && tag !== 'input'
             && el.getAttribute('role') !== 'button';
    })
    .map(el => ({
      tag: el.tagName.toLowerCase(),
      text: el.textContent?.trim().substring(0, 80),
      onclick: el.getAttribute('onclick')
    }));
});

This script finds every div, span, or other non-interactive element with an onclick attribute. No source code needed. It tests the live page.

What can Playwright test?

Playwright runs a real Chromium browser. All JavaScript is executed, so you see the rendered DOM, not the source code. You can click, wait for a modal to appear, and then inspect the new HTML. Modals, accordions, tabs, lazy-loaded content, open Shadow DOM, iframes. It all works.

Where does it go wrong?

The biggest problem: addEventListener. Most modern websites don’t use onclick="..." in the HTML. They attach click events via JavaScript:

element.addEventListener('click', function() {
  addToCart(123);
});

This is invisible in the DOM. There’s no onclick attribute to search for.

You can look for signals that an element is meant to be clickable:

  • Does it have cursor: pointer in the computed style?
  • Does it have a class like “btn”, “button”, “clickable”?
  • Is it a <div> or <span> with tabindex="0" but without role="button"?

But those are educated guesses. You’ll get false positives (elements that look clickable but aren’t) and false negatives (clickable elements without visual hints).

Other limitations:

LimitationImpact
addEventListener is invisible in DOMHigh, most modern sites use this
You test one page state at a timeMedium, logged in vs. logged out, different tabs
Closed Shadow DOM is inaccessibleLow, rarely used
Bot detection (Cloudflare etc.)Medium, some sites block headless browsers
Pages behind loginMedium, possible but you need to provide credentials

What do you need?

To run this test yourself, you need three things:

  1. Node.js (version 18 or higher)
  2. Playwright (npm install playwright)
  3. A Chromium browser (npx playwright install chromium)

No source code needed, no special access. You test the website as a visitor sees it.

The scorecard

TestScoreNotes
Code analysis: detect div onclickFoundClaude recognizes the problem in a code snippet
Live website: find inline onclickFoundPlaywright can search DOM for onclick attributes
Live website: find addEventListenerMissedInvisible in DOM, only approachable via heuristics
Live website: dynamically loaded divsFoundPlaywright can click, wait, and inspect new DOM
Understanding context (why it’s wrong)FoundClaude explains what it means for users

AI finds this problem in code and with inline onclick. But with addEventListener (the way most modern websites work), it depends on heuristics. That’s a serious limitation.

The fix

<!-- Don't do this -->
<div class="btn-primary" onclick="addToCart(123)">Add to cart</div>

<!-- Do this -->
<button class="btn-primary" type="button" onclick="addToCart(123)">
  Add to cart
</button>

A <button> is focusable by default, activatable with Enter and Space, and has the correct role for screen readers. Free. No extra code needed.

What I learned from this

Claude understands this problem well. It explains why a div isn’t a button, what it means for keyboard users, and how to fix it. That’s more than what axe or Lighthouse tell you, which only report that there’s an element without a role.

But finding it on a live website is a different story. Searching the DOM works when the site has onclick attributes in the HTML. With JavaScript event listeners, you need heuristics that aren’t watertight.

And then the point that really matters: AI can tell you that the div should be a button. But it can’t press Tab. It reads and reasons. It doesn’t test.


This is test #1 of the series “AI and Accessibility Testing.” Each test examines whether AI can detect a specific accessibility issue, not just in code but also on a live website. Want to know how accessible your website is? Have it tested by a human for the best results. Get in touch.

Julia Tol, senior auditor at Proper Access

Julia Tol, developer, WCAG expert, AI consultant

Continue on this topic

  • WCAG Radar

    Bookmarklet and browser extension for Chrome and Firefox. Checks alt text, headings, contrast, focus and tab order live on any page. 29 of 50 checks are free.

  • Accessibility credits

    Buy a bundle of credits and ask a senior accessibility auditor a question whenever you need one. One credit is one question on one topic. No audit required.

  • Accessibility audit

    An accessibility audit against WCAG 2.2 and EN 301 549. You get concrete solutions, visually explained, with code examples your team can act on.

Related Posts

Can AI test your website for accessibility? I'm going to find out

Can AI test your website for accessibility? I'm going to find out

Can AI test your website for accessibility? “Can’t ChatGPT just check my website?” I hear this question more and more. From developers who want their code reviewed. From product owners without the budget for a full audit. From e-commerce owners who really should have been EAA-compliant yesterday. It’s a fair question. AI can write code, grade essays, and analyze medical scans. Why wouldn’t it be able to spot that your contrast ratio is too low, or that your button has no accessible name? The short answer: AI can do quite a lot. It’s getting smarter by the day. But there are limitations and drawbacks. The longer answer? That depends on what exactly you want to do, which tools you use, how much you’re willing to pay, and how long you’re willing to wait. In this series, we’re going to find out. Over a series of articles, I’ll test exactly what AI can and can’t detect when it comes to accessibility issues. No theory, no assumptions. Real tests with real code.