ADA compliance

Accessibility built into the markup, not bolted on by a widget

Web accessibility means a site works for someone browsing with a keyboard, with a screen reader, or with the text turned up — and in the US the ADA is why it is a legal question as well as a usability one. Real accessibility lives in the HTML a screen reader reads, not in a script that runs after the page has already loaded. We handle it from the first line of code, then verify it by hand. We build and audit to the standard; we are not a law firm and nothing here is legal advice. This is the technical side of the work, done properly.

Start your projectAll services

You already took accessibility seriously. This is about where the fix actually lands.

Some visitors browse with a keyboard instead of a mouse.

Some use a screen reader — software that reads a page aloud — because they can't see it. Some just need bigger text or more contrast to read in bright sun. Reaching all of them is the same work that holds up if a demand letter ever arrives. Where the fix goes in is a timing question. A screen reader parses your HTML as the page loads; an accessibility overlay script runs only after. When the markup is missing a button name or a form label, the reader has already moved on before the widget wakes up. So the promised fix never reaches the person it was meant for. We work through the site the way those visitors do, fix what blocks them in the code itself, and leave you a dated record of what was tested and what changed.

What's included in an accessibility engagement

Handled from the first line of code

Accessibility is a build decision, not a retrofit. Heading order, focus management, labels, contrast, and semantics are handled in the markup as the site is built — on every page, not on the handful a scanner happens to sample.

Verified two ways, not just scanned

Automated scans catch a portion; the rest only surfaces by hand. We drive every key page with the keyboard alone and read it back through real screen readers, so we catch the traps a scanner reports as passing — a menu you can tab into but not out of, a field with no spoken label, a video with no captions.

The fixes made in the markup an overlay can't reach

Contrast, focus outlines, heading order, alt text, form labels, tables, PDFs, and modals corrected in the site itself. This is the part that actually changes the experience for someone using assistive technology — and the part a line of JavaScript loaded on top can never do.

A written accessibility statement and a private record

A public page describing your standard, how to report a barrier, and how quickly you aim to answer — plus a dated log of what was tested, what was fixed, and anything still open, so the work is on the record.

An optional comfort layer, clearly labeled as comfort

If you want them, we add preference controls on top of the real work — text size, contrast, spacing, and dyslexia-friendly fonts — as conveniences that visitors choose. They sit on a site that is already accessible underneath. They are comfort controls, never a substitute for the fixes.

Re-checks as the site changes

New pages, new posts, and new plugins are where accessibility quietly slips. We re-test on a set rhythm so a page published next quarter doesn't undo the work you paid for.

How an accessibility engagement runs

  1. 1

    Audit

    We scan the whole site, then hand-test the pages that matter most — home, services, contact, checkout, and anything with a form. You get a plain-English report: what the issue is, who it affects, and how serious it is.

  2. 2

    Prioritize

    We sort the findings by how many visitors they block and how exposed they leave you, then agree on what gets fixed first. Nothing is a surprise line item later.

  3. 3

    Remediate

    We make the corrections in the code and retest each one. Where a fix touches the design — usually contrast or focus styling — we show you the change before it ships and fit it to your brand rather than a default.

  4. 4

    Document

    We publish the accessibility statement, hand over the dated record of testing and fixes, and note anything still outstanding with a plan for it.

  5. 5

    Maintain

    Scheduled re-checks as content and features are added, plus the optional comfort layer if you want it — always on top of the real compliance, never in place of it.

The same way we run every engagement — how we work →

How the work is verified

  • Work delivered inside U.S. Army and U.S. Navy environments
  • A keyboard-only pass on every key page
  • A screen-reader pass on every key page
  • A dated record of what was tested and what changed

We can describe the scope and the constraints of that federal work, though not the owners — details on request. Rules move: confirm your own obligations with counsel before relying on anything on this page.

A good fit if

  • You installed an accessibility overlay and want the site underneath to actually match the promise
  • You've received a demand letter or an accessibility complaint
  • You sell to government, healthcare, education, or enterprise buyers
  • Your customers include people who use assistive technology
  • You're planning a redesign and want this handled from the start

Often paired with accessibility work

Websites

Fast, beautiful sites built to turn visitors into leads.

Learn more

Website management

Hosting, updates, backups, and round-the-clock monitoring.

Learn more

Due diligence

Buy-side audits of the site and stack you're acquiring.

Learn more

Questions we get about ADA and accessibility

It's a common and well-meant move, and it's worth knowing what the widget can and can't do. An overlay can't give a button a name, caption a video, or repair a form the markup never labeled — a screen reader has read the page before the script even runs. The trap has teeth: in 2025 the FTC fined the overlay vendor accessiBe one million dollars for deceptive claims about instant compliance, a large share of recent web-accessibility lawsuits have named sites that already had an overlay installed, and courts routinely require the widget be removed and real remediation done anyway. We fix the site itself. If you still want the convenience controls for visitors, we add them on top — clearly, as comfort, not as the compliance.
We build and audit to the standard; we are not a law firm and nothing we provide is legal advice. What we do is technical and verifiable: measure the site against the recognized accessibility standard US courts and federal agencies point to, fix what falls short in the code, and document it. If you're responding to a claim, your attorney should lead — we support them with the audit, the remediation, and the record.
Ian, the founder of Spider Digital Group, builds the sites personally. You work directly with him, not a junior or one of forty things competing for a team's attention. Some of this work has been delivered inside U.S. Army and U.S. Navy environments, where accessibility is not optional — we can describe the scope and the constraints, though not the owners. The stack is Next.js, Tailwind, Supabase and Vercel — mainstream tools with public documentation, so your site isn't a bespoke experiment that only one person can maintain.
Both the audit and the remediation depend on the number of pages and how much of the site needs rebuilding rather than adjusting. We'll give you a firm number and schedule after the first conversation, once we've seen the site.

Let's find out where your site stands.

Start your project

A few quick questions — about two minutes.