Legal Compliance without a Rebuild: Making a site accessible under a legal deadline

The Situation

A booking funnel that runs the business

A customer rents a storage unit at two in the morning. They find a nearby location, browse available units, reserve a space, and pay, without ever calling an office.

One web application makes all of that work. Our client, a large storage-facility management company, does nearly all of its business through it.

That makes the site less of a marketing page and more of a storefront that has to stay open. It is built on a long-lived Laravel and Livewire codebase that has grown feature by feature over years of real use. Like most applications carrying revenue, it was never something the business could take offline to rebuild.

The Trigger

A parked audit becomes a live threat

An accessibility audit in early 2025 had already flagged a long list of problems: controls that a keyboard could not reach, form errors a screen reader never announced, and images with duplicated or missing descriptions. The findings were real, but the work sat in the backlog behind everything else competing for attention. That’s a familiar story, and on most days it is a reasonable one.

Then the situation changed overnight. The company received a legal claim alleging that key parts of the site failed national accessibility standards—the ADA expectations that, in practice, are measured against the WCAG 2.1 AA guidelines. The timing was the hard part: the company was in the middle of an acquisition. A parked backlog item was suddenly a risk to the deal, and the leadership team needed to show their legal counsel and the buyer that it was being handled as their top priority.

Underneath the legal pressure was a quieter fear we have seen many times. The people responsible did not just need the problem fixed; they needed to be able to say, with confidence and evidence, that it was being fixed while the deal was still on the table.

The Challenge

The first decision was what not to do

Rebuilding a revenue-critical booking funnel to bolt on accessibility risks regressions in key features when you move too fast or work under pressure. The site wouldn’t collapse, but one small break in how users can reserve and then pay for storage units could grow into a multi-thousand-dollar problem fast. Avoiding any friction in how the changes were rolled out was key to building confidence between the company and its new potential buyers.

With this in mind, our approach was to treat the accessibility work as we would any other user-facing bug- very carefully. Moving page by page in small increments, relying on a solid testing plan and staging site to validate any changes before they went out to live users, and with a strong communication pipeline between engineers and the product owners from the storage company.

Our Approach

The client had already done the priority mapping

Luckily, we weren’t starting from a blank page. The client's product manager had mapped the site into its component pieces, ranked which problems had to be resolved first, and carried the context behind earlier decisions in the style guide that would help us make changes without interrupting the design.

That allowed us to add technical depth to each item and move quickly.

Working the site the way a customer moves through it

Shifting focus to be completely on accessibility, Planet Argon engineers were able to focus on working through the funnel as a user would: starting at the homepage elements, moving through search and location selection, then down through the reservation funnel. Like many sites, this one had compounding elements that we had to keep in mind—search leads to location, location leads to units, units lead to cost to reserve, etc.

Across more than fifty requests, there were a few common patterns:

• Image-based controls, which looked like buttons but were embedded links, became real, keyboard-operable buttons.
• Decorative icons were hidden from screen readers so they stopped adding noise.
• Form fields got proper labels, and validation errors were tied to the fields they described, so a screen reader user hears what went wrong and where.

Implementation and Iteration

An example of our approach—the dropdown

The site's dropdowns relied on Selectric, an older jQuery plugin with no meaningful accessibility support. A common practice in applications of this age. Replacing a dropdown may seem like a relatively easy task, but changing the underlying structure of how a dropdown shows results and captures selections can get tricky on a site with more than five hundred pages.

Rather than modifying the plugin to behave, we rebuilt the dropdown as a single component following the W3C WAI-ARIA listbox pattern. This gave us a uniform way to display dropdowns and live up to the published standard for this type of control. Visually, to users, the dropdown didn’t look any different—but by moving away from Selectric, we gained accessible keyboard controls and W3C compliance.

Testing it by ear

Standards on paper aren’t the same as a usable experience. Using VoiceOver, the screen reader built into macOS, we navigated the site the way a customer with low or no vision would.

Did the reservation form make sense in sequence? Did a loading state announce itself? Did a dropdown tell you what it was and what you had picked? A change only counted as done once it held up to that test.

All of these considerations are easy to miss when engineering as people who may not need the accessibility tools in our day-to-day work. It was quality control, sure. But it was also a good reminder for fast-moving teams that accessibility is a must for all kinds of users.

The Outcome

A defensible answer while the deal was live

The most valuable outcome was that the client always had something concrete to report. Because the work moved page by page, leadership could hand their legal team and the buyer a running record of what had been remediated and when—turning a source of panic into a paper trail they could stand behind. Between late April and early July of 2026, the team closed 85 tracked items, spanning every major part of the funnel. The booking flow never went dark.

The clearest measure of the result is what came afterward. The project closed with no further findings.

What is left is an application that meets the standard it’s measured against, a booking funnel that still works exactly as customers expect, and a client who came through a tense stretch with the receipts to prove it.

The Second Act

Accessibility isn't a reason to start over

Every instinct says a site facing a legal claim needs to be rebuilt properly. Here the opposite was true. The lawsuit is what made a rebuild
impossible, because the funnel had to keep taking reservations the whole time it was being fixed.

The accessibility problems lived in the components, not the architecture. Buttons, labels, focus order, a dropdown. Ordinary work,
done in order, on an application that never stopped taking reservations. Then the acquisition closed. That is what a second act success story looks like.