Skip to content
Agent Checker
Back to Blog
TechnicalAccessibilityAI Agents

Accessibility Overlays: Do They Help or Hinder AI Agents

Agent Checker4 min read

Accessibility overlay widgets promise a quick fix: add one JavaScript snippet and your site becomes WCAG compliant. The reality is more complicated. These overlays inject code that modifies the DOM, adds ARIA attributes dynamically, and sometimes restructures page layout on the fly. For AI agents trying to read and interact with your pages, overlays introduce noise and inconsistency that can make things harder, not easier.

What accessibility overlays do

A typical overlay adds a toolbar or widget to your site that lets users adjust text size, contrast, spacing, and other display settings. Behind the scenes, the overlay's JavaScript makes changes to the DOM:

  • Adds aria-label attributes to elements that lack them
  • Inserts role attributes on containers
  • Modifies colour contrast by changing inline styles
  • Restructures heading hierarchies
  • Adds alt text to images (often generated automatically)

The overlay runs after the page loads, meaning the initial HTML and the post-overlay HTML are different documents from an agent's perspective.

How overlays affect agent browsing

Inconsistent ARIA attributes

Agents rely on ARIA labels to identify and interact with elements. When an overlay adds ARIA attributes dynamically, the labels may not match the visual content or may conflict with existing attributes.

Consider a button that already has a label:

<!-- Original HTML -->
<button aria-label="Add to basket">
  <svg>...</svg> Add to Cart
</button>

An overlay might add a second label or modify the existing one:

<!-- After overlay processing -->
<button aria-label="Button - Add to Cart" data-overlay-processed="true">
  <svg aria-hidden="true">...</svg> Add to Cart
</button>

Now the agent sees "Button - Add to Cart" instead of "Add to basket". The labels are functionally similar, but the change is unpredictable. On another page, the overlay might generate a completely different label format. This inconsistency makes it harder for agents to build reliable interaction patterns across your site.

DOM structure changes

Overlays that restructure headings or add wrapper elements change the document outline. An agent that reads heading levels to understand page hierarchy gets a different structure depending on whether the overlay has run.

<!-- Before overlay -->
<h2>Product Details</h2>
<h4>Specifications</h4>

<!-- After overlay "fixes" heading hierarchy -->
<h2>Product Details</h2>
<h3>Specifications</h3>

The overlay changed an <h4> to an <h3> because it detected a skipped heading level. On its own this seems reasonable, but the agent now sees a different DOM depending on timing. If the agent reads the page before the overlay script runs, it gets the original structure. After, it gets the modified version. Two different agents visiting the same page might read it at different points and get different results.

Auto-generated alt text

Some overlays use image recognition to generate alt text for images that lack it. The quality of this generated text varies widely. A product image might get alt text like "photo of a rectangular object" instead of "Wireless Keyboard Model WK-2045". An agent trying to understand what the image shows gets a vague description that adds no real value.

Performance impact

Overlays load additional JavaScript, typically between 100KB and 500KB. This adds to page weight and affects load times, which directly impacts agent timeout thresholds. The overlay script also needs to process the entire DOM after page load, adding to Total Blocking Time.

The underlying problem

Overlays treat accessibility as a presentation layer concern. They modify the output without fixing the source. The original HTML still has missing alt text, skipped heading levels, and unlabelled buttons. The overlay papers over these issues at render time, but the fix is fragile, inconsistent, and invisible to agents that read the page before the overlay JavaScript executes.

Genuine accessibility improvements come from fixing the HTML itself:

  • Write proper alt text in your image tags
  • Use semantic HTML elements (<nav>, <main>, <aside>)
  • Apply ARIA attributes where native semantics are insufficient
  • Follow a logical heading hierarchy
  • Build agent-friendly forms with proper labels

These changes persist in the HTML regardless of JavaScript execution. Every agent, every screen reader, and every browser sees the same well-structured content.

What the evidence shows

Multiple studies and audits have found that accessibility overlays do not achieve WCAG compliance. The National Federation of the Blind, the American Council of the Blind, and numerous accessibility professionals have published statements criticising overlay products. Sites with overlays frequently have more accessibility violations than comparable sites without them, because the overlay creates a false sense of compliance that discourages proper remediation.

For agents, the practical conclusion is clear: overlays add complexity without fixing root causes. If you want your site to be accessible to both assistive technology users and AI agents, fix your markup directly. You can run an agent readiness audit to identify the specific structural issues that affect how agents experience your pages, and address them at the source.