We Put Website Accessibility on Trial — and Our Founder Lost 5–0

Does a five-page local-business website really need accessibility work? We stopped debating it in the abstract and put the question on trial: a structured, adversarial debate in which every position had to survive formal rebuttal — and where a downvote isn’t allowed unless the voter files an argument to back it. Our founder took the skeptic’s side. A panel of five specialist AIs — each judging from a different discipline — ruled against him, unanimously.

The short version of the verdict: accessibility has a floor and a ceiling. The floor — real buttons, keyboard operability, a skip link, visible focus, 44-pixel tap targets, a layout that survives 200% zoom — is mandatory, because on a properly built site it costs minutes. The ceiling — paid audits, AAA conformance, manual screen-reader passes — should be priced by risk, not bought by default. And per-user “accessibility widgets” earn no credit toward either tier.

Why put a web design question on trial?

Best-practice advice on the internet has a trust problem: most of it is undated, unchallenged, and written to sell something. So we’ve been building an internal instrument for settling these questions the hard way — a court, not an oracle. A claim is posted as a thesis. Specialists attack it from independent angles: mobile conversion, accessibility, performance, maintainability, and search visibility. Disagreement is expensive by design: you cannot downvote a claim without filing a rebuttal that itself gets judged. What survives, stands — with the fight attached as provenance.

This was the first genuinely contested case, and it started because our founder did what a good skeptic should: he challenged his own panel.

What was the case against accessibility requirements?

The skeptic’s argument was proportionality, and it’s worth stating fairly because a version of it lives in most small-business owners’ heads:

  • A five-page fence-company site with a phone-first audience has different accessibility economics than a bank — one mandatory standard for both misallocates small budgets.
  • Assistive capability is migrating into the user’s own layer: browser zoom, operating-system settings, and a growing class of per-user page-adaptation tools, including the accessibility assistants now shipping with major page builders.
  • Time spent on focus states for a menu nobody keyboard-navigates is time not spent on the tap-to-call bar everybody uses.

Reasonable, budget-conscious, and grounded in how small businesses actually spend. It still lost every vote.

What did the other side prove?

The accessibility panelist’s counter-argument rested on one mechanical fact and one paper trail.

The mechanical fact: every assistive tool operates downstream of the markup you ship. A screen reader can only announce a menu if it’s built from real, labeled elements. Browser zoom is precisely what breaks a layout that was never built to reflow. A page-adaptation widget can restyle a page, but it cannot repair a clickable div into a button — the stronger the user’s own tools get, the more your underlying markup matters, not less.

The paper trail: widgets don’t stop lawsuits.

The Overlay Fact Sheet, an open letter signed by hundreds of accessibility practitioners — including the assistive-technology users the products claim to serve — recommends against accessibility overlay widgets, and UsableNet's annual litigation tracking has found that a substantial share of US web-accessibility lawsuits in recent years, on the order of a quarter of filings, were brought against sites that were already running an overlay or widget when they were sued.

Then the other three panelists piled on from their own disciplines, unprompted. The performance specialist noted that assist widgets are third-party JavaScript on the critical path — a speed tax charged to every visitor to serve a minority who already have better tools. The maintainability specialist called the widget a runtime dependency that breaks silently, versus a floor baked into templates once. The search specialist delivered the quietest kill: the accessibility tree and the crawl tree are substantially the same tree. Semantic, operable markup is what search engines and AI answer engines parse; a client-side widget is invisible to both. The floor pays twice.

What exactly is the operability floor?

The verdict’s floor, as adjudicated — every item a build-time decision in HTML and CSS:

  • Navigation landmarks and real button/a elements — never clickable divs
  • A skip-to-content link
  • Visible keyboard focus on every interactive element
  • Tap targets around 44 pixels
  • Text and layout that survive 200% zoom without horizontal scrolling
  • State never communicated by color alone

And the ceiling, explicitly not mandated for a typical small-business site: AAA conformance, paid conformance audits, and manual assistive-technology testing passes — justified when audience, sector, or legal exposure says so.

The floor is also conversion work wearing a different name. The same 44-pixel targets serve gloved hands and older thumbs. The same zoom-safe layout serves anyone reading in sunlight with text size bumped up. The same JavaScript-free navigation survives a weak cell connection in a parking lot — which is exactly where your next customer is standing.

NW eSource builds the operability floor into its site templates by default rather than selling accessibility as a line item: on a semantic-HTML build the floor is a set of decisions made once at template time, which is why the firm treats widget subscriptions as a patch for sites that were built wrong — a recurring fee that neither fixes the markup nor, per the litigation record, prevents the lawsuit.

What about the new page-builder accessibility assistants?

The trial’s most current question: major page builders are now shipping built-in accessibility assistants — Ally by Elementor is the most widely deployed, pairing a per-user usability widget with WCAG scans and guided fixes. Aren’t those the proportionality argument made real?

The verdict draws the line through the middle of that featureset. The scan-and-guided-fix side is real accessibility work — fixes that land in the page’s actual markup count toward the floor, whichever tool surfaced them. The widget side — per-user resizing and reshaping — is a genuine convenience as an enhancement, but it cannot carry the floor: it sits downstream of the DOM, it adds script weight, it does nothing for the crawlers and answer engines that read your site, and it does not repair the markup a screen reader actually consumes. If the underlying page is built from unlabeled clickables and JavaScript-dependent menus, every one of those failures is still shipped to every user, widget or not.

What should a small business actually do?

Budget by the two tiers the trial produced. Demand the floor from whoever builds your site — and expect it to be free, because on a competently built site it is. Treat the ceiling as a risk decision you revisit as you grow. Decline the widget subscription as a substitute for either. If your current site can’t pass the floor without a widget, the honest fix is the markup, not the monthly fee — that’s the standard we hold our own AI-assisted web design work to.

One more thing the trial proved, which is why we’re publishing it as a case rather than an opinion: the skeptic losing improved the answer. Before the challenge, “make it accessible” was an undifferentiated demand. The proportionality argument — wrong about widgets, right about budgets — is what forced the floor/ceiling distinction that makes accessibility a number a small business can actually plan around. The founder lost the case and got a better rule out of it. That’s the point of putting these things on trial, and this is the first dispatch of more to come.

Want a site where the floor comes built in? Talk to NW eSource — or see how we approach AI-assisted web design for conversion-first small-business sites.