What PHP2Shell Reveals About Digital Accessibility’s Urgency Gap

On October 21, the team that maintains PHP, the programming language behind roughly 70% of websites, released emergency fixes for two critical security vulnerabilities known as PHP2Shell. The response is a model of coordination, and proved that organizations can move remarkably fast when a problem is treated as an emergency.

Government cybersecurity agencies in the U.S., U.K., Germany, Japan, Australia, and elsewhere issued urgent warnings. Cloud providers like Cloudflare, AWS, and Akamai pushed out protections within hours. Hospitals, and even a major European port, took websites offline rather than risk exposure.

Patching itself wasn’t instant, but within hours everyone knew about the problem, agreed it mattered, and began to act. Accessibility issues almost never get that response, even the ones that stop people from completing a purchase, booking an appointment, or applying for benefits. It’s worth asking why.

The flaw was 14 years old. The urgency was brand new.

The bugs behind PHP2Shell had been sitting in PHP’s code for about 14 years. OpenAI President and Co-Founder Greg Brockman noted that a limited version of this bug had been discovered in 2024, but wasn’t considered significant. Engineers say they reported it at the time, yet a fix never shipped.

What changed this month wasn't the vulnerability. It was how people approached it. The security system didn't act on this bug for 14 years. Once PHP2Shell was confirmed, named, and scored, the response system the security industry has spent decades building took over.

Each flaw got an official ID, so everyone was talking about the same problem. It got a severity score of 9.2 out of 10, a clear signal it couldn’t wait. Researchers, engineers and security firms coordinated the fix, and government agencies told organizations to act immediately.

That system is why organizations moved so fast. Not because security teams care more, but because it made the urgency impossible to miss and the next step obvious. For people with disabilities, issues online are a daily reality, but there’s no system making sure anyone notices.

Can we treat accessibility issues similarly?

If we look at how accessibility issues are handled, most of that system is missing.

PHP2Shell got an official name. Accessibility issues get a line in a report. Many tools and experts rate those issues by severity, but even a high-risk rating rarely triggers a deadline or anything else that forces a fix. In AudioEye’s 2026 Digital Accessibility Index, roughly 1 in 5 issues was high-risk, meaning it can stop someone from finishing a task. That works out to about 13 high-risk issues on the average page, and many organizations don’t treat any of them as an emergency.

None of these are hidden problems waiting to be discovered. Of the 160,000+ pages we scanned for our Index, the same five Web Content Accessibility Guidelines (WCAG) criteria fail on roughly 75% of them, regardless of industry or region. Teams know they’re there. The issues never become urgent, and “we’ll get to it” quietly becomes the most expensive sentence in the roadmap. 

There is momentum. At the federal level, the ADA Title II web accessibility rule sets a compliance deadline for state and local government websites and apps. In April, though, the Department of Justice pushed that deadline back a year, citing staffing, budget, and expertise: the same gaps that leave accessibility issues waiting everywhere else. At the state level, pressure is building faster. AudioEye’s 2026 Web Accessibility Litigation Report found that 77% of accessibility lawsuits are now filed in state courts, as total filings have more than doubled since 2020.

Europe has gone further. Since June 2025, the European Accessibility Act has required businesses selling key products and services across the EU, from online shops to banking, to meet common accessibility requirements. Regulators are actively checking. According to a recent report from Atyantik, Sweden has opened 28 investigations into online shops. In June, a French court gave Carrefour six months to make its website and app accessible, with €500 per day fine for missing the deadline.

Still, enforcement runs country by country and, more than a year in, no fines have been published. 

Nothing that applies across the board tells organizations to act today. So the pressure still arrives one case at a time, often after a high-impact issue has already shut someone out.

Built to stop break-ins, not lockouts

There’s a deeper reason accessibility waits: who feels the impact. Security tools alert a company the moment someone tries to break in. Nothing alerts it when a person using assistive technology can’t get through checkout.

PHP2Shell threatened companies directly. Their data, their servers, their reputation. Every executive could picture it happening to them and could immediately quantify the potential damage. 

A security flaw only hurts anyone once someone finds a way to exploit it. Accessibility issues work the other way around. They shut people out from the moment they go live.

When a screen reader user can’t complete checkout because a button has no label, nothing on the company’s side breaks. No alert fires. No one gets paged. The customer leaves. According to AudioEye research, 71% of people with disabilities leave a site when they run into accessibility issues, and may never tell the company why.

For that customer, the issue is as critical as a problem gets. It never shows up anywhere decisions get made. That’s why the first time leadership hears about it is so often in a lawsuit.

And when that alarm does sound, it’s expensive. A single claim typically settles for $25,000 to $75,000, and the settlement is rarely the biggest cost. Legal fees, executive time, and rushed fixes usually add more on top.

At the high end, the numbers reach millions. Last year, Fashion Nova agreed to pay $5.15 million to settle a class action brought by blind shoppers who said they couldn’t use its website.

In that sense, an inaccessible website behaves a lot like an unpatched vulnerability. It sits quietly, causing no issues anyone can see, until someone acts on it. The difference is that the people it shuts out were paying the price the whole time.

Build the routine before you need the alarm