The Accessibility Crisis That Built Automation Infrastructure

We encounter a pattern building enterprise web agents: some sites are dramatically easier to automate than others, in ways unrelated to their technical sophistication. A React application with the latest framework might require fragile CSS selectors that break with every redesign. An older site navigates cleanly through semantic landmarks that never change.

The difference is ARIA landmarks —semantic roles declaring what interface elements actually are. A role="navigation" region. A role="main" content area.

These weren't designed for automation. They emerged from a human crisis that nobody could see.

When the Web Became Unreadable

In 2008, the web was transforming into dynamic, Ajax-powered interfaces—Gmail, Google Maps, rich applications that made the web feel like software. For blind users navigating with screen readers, these interfaces became unreadable. A screen reader would announce: "Button. Button. Link. Button." Forty-seven times before reaching anything resembling an inbox. Each button functionally identical to assistive technology—no indication of purpose, destination, or meaning.

Visual users got structural signals from layout and design. Screen reader users got silence. The semantic structure didn't exist.

WAI-ARIA was the answer—a specification for adding semantic roles, states, and properties to web interfaces. Give assistive technology the structural signals it needs. Declare explicitly what visual layout communicates implicitly.

What accessibility advocates built for human disability became critical infrastructure for machine navigation—not through exploitation, but through convergence. Both screen readers and web agents need identical signals: machine-readable structure describing what interfaces mean, not just how they appear.

What We See at Scale

When you need competitive pricing across 500 hotel sites, CSS classes are chaos. One site uses .content, another .main-wrapper, a third .product-grid-container. Every redesign breaks selectors.

But role="main" means the same thing everywhere—a semantic contract surviving visual changes.

We see this daily building web agent infrastructure at scale. Sites without proper ARIA aren't just inaccessible to people with disabilities—they're brittle for automation. Every element needs custom logic. Every navigation pattern requires site-specific handling because there's no semantic structure to follow.

The gap: 94.8% of major websites still have detectable accessibility failures. We encounter this constantly—sites adding role="navigation" to divs without keyboard accessibility, declaring landmarks that don't match actual structure. The accessibility community warns:

For automation, bad ARIA is worse—it promises semantic structure but delivers misleading signals. You build logic around declared landmarks, then discover they're decorative rather than functional.

The Infrastructure Nobody Planned

The ARIA story shows how solving hard human problems creates durable infrastructure. Designing for the hardest navigation case—someone who can't see visual layout—often creates the most reliable structure for everyone.

This matters when building systems today. When you're designing an interface, start by asking what semantic structure makes it understandable—to humans with different abilities, to assistive technology, to programmatic agents navigating at scale. The automation question follows naturally from that foundation.

Every site implementing ARIA correctly isn't just becoming more accessible. It's becoming more automatable, more maintainable, more structurally sound. The semantic infrastructure helping a screen reader user navigate a complex interface also helps web agents run reliably across thousands of sites.

Designing for disability created machine-readable infrastructure. That convergence reshaped how we build for the web. The most durable systems, it turns out, serve the hardest use cases first.