Web accessibility, litigation, and what a website builder can honestly tell you
This page is for an organizer trying to work out how exposed they are and what a platform can actually do about it. It cites its sources so you can check every line. It makes no promise about a legal outcome, because a vendor who makes one has committed a second offence on top of whatever is wrong with the website.
Why there are no promises on this page
In April 2025 the Federal Trade Commission finalised an order against accessiBe, a vendor selling an automated accessibility product, and took $1,000,000 (In the Matter of accessiBe Inc., Docket No. C-4817; final order 22 April 2025). The order bars it from representing that its product can bring any website into conformance with WCAG, or that it will keep a site there automatically as the content changes.
The part that governs a page like this one is the standard the Commission applied. The complaint charges that the representations "are false or misleading or were not substantiated at the time the representations were made" (¶90). Read the "or". A claim nobody had evidence for is already a violation, whether or not it later turns out to be true.
Two further findings shape what is written here. The complaint states that "no automated testing tool alone can determine if a website meets accessibility standards. Rather, manual human testing is required" (¶78). And the Commission condemned where accessiBe kept its caveats — "buried in accessiBe's Terms of Service, blog posts, or other sub-pages", with nothing equally prominent next to the headline claim. So the limits of what we do sit on this page, beside the claims, and not behind a link.
That is why you will not find a badge, a score, a seal or a percentage anywhere in this product.
What Gametime Hero actually does
Four things, each one a fact about our own work that you could confirm by reading our pull requests. None of them is a statement about your site.
Six accessibility gates, and a merge that stops
Six checks run on every pull request, in a job that the required unit-test check depends on. A change that reintroduces one of them cannot reach production. Our day-to-day integration branch does not enforce them, so the same check can go red there without stopping anything — we would rather say that than let one sentence stand for both branches.
Two of them read every published-site template: one for a control with no accessible name, one for an image whose description we hardcoded instead of asking the organizer for. Two more read the form and shared-component trees: a validation error that appears in silence, and a grouped input whose label points at an id the template never declares. That last one is the trap worth naming — a name that reads correctly in review and resolves to nothing at runtime.
None of the four can tell you an image is missing its description altogether. A blank alt is indistinguishable from a deliberate one on a decorative image, so that judgement belongs to a person and we do not pretend a scanner makes it.
The fifth exists only to prove the accessibility lint rules are switched on. Those three rules were configured to fail the build and then quietly did not run for months, because the pattern that selected the files matched nothing. The sixth is the step that actually runs them. A check that cannot fail looks exactly like a check that passes.
Each of the four scanners has its own test that plants a real violation in the real tree and fails if the scanner does not refuse it.
A review before you publish that never stops you
Press Publish in the site builder and an automated review opens first. It reads the settings you filled in and says what it found: an image with no description, a link whose text names nothing, text colour it measured below the contrast threshold, a page with no heading.
It has no badge, no score and no pass/fail field. The data model it is built on has no field for one, on purpose. "Publish now" is always there, and nothing it finds stops a publish.
Above the findings, unconditionally and not behind a "learn more", it lists the fifteen things it does not look at — starting with whether a keyboard can reach everything and what a screen reader actually announces.
What we fixed, and what it took to find it
We read all 57 site-builder blocks and roughly 96 published-site templates by hand, and fixed more than 50 defects. Each fix carries a regression test.
Among them: 24 validation error messages across 17 files that appeared in complete silence; a focus indicator removed from 28 published templates by a single "all: unset", and a follow-up fix that was itself incomplete because "overflow-x: auto" was still clipping the ring off; six wide data tables no keyboard could reach; and nine shared components that blocks hand their whole view to, which nobody had ever audited.
The worst one: every undescribed image on every published site was shipping the literal word "undefined" as its alt text, read out loud. Our own alt-text scanner could not see it, because the attribute was present and not empty.
The audit drives a real browser
The audit that runs against a published site opens it in a real browser and runs the axe WCAG 2.1 and 2.2 AA rule set over every page in that site's own sitemap.
It has to be a real browser. Colour contrast needs computed styles rather than markup, and the carousel writes its roles and labels at runtime, so a fetch-and-parse checker would report a clean page where a real one fails.
What we have not done
This sits here, next to the claims above, and not on another page. Every line is something a buyer, a journalist or an opposing expert could establish about us in an afternoon, so you should hear it from us first.
- No person has sat down with a screen reader and worked through every flow. Registration and payment are first in that queue and it has not happened yet. Automated evidence is not a substitute for it, and we are not going to present it as one.
- Automated rules catch only part of WCAG. Whether your alt text is meaningful, whether a heading describes its section, whether the reading order makes sense — a person has to judge those, and no gate we run does.
- You can still publish a site that people cannot use. Your images and the words you describe them with, your colour choices, your custom CSS, your writing and anything you embed from somewhere else are yours, and we do not control them.
- Our own marketing pages, this one included, have never had an automated run, a manual pass, or a lint gate over them. The gates described above read the published-site, form and shared-component trees. They do NOT read the registration and payment path: pointing one of them at that path found eleven controls with no accessible name, and we have not turned it on there yet. The payment step has no automated accessibility coverage at all.
- We have not published an Accessibility Conformance Report. One is drafted. It carries rows marked "Does Not Support" and rows marked "Not Evaluated", and it is in review — we would rather publish it late than publish one that reads better than the product.
- A published site can now declare the language it was written in, but no editor screen lets you set it. Until one does, a Spanish-language league site still declares English to anyone who has not switched language themselves — and a wrong declaration is worse than none, because a screen reader then pronounces Spanish with English rules.
- There is no way to add captions or a transcript to video or audio you upload. The video block renders no caption track and there is no screen to author one.
- Nobody has tested any of this at 400% zoom, at 320 CSS pixels wide, at 200% text size, or with text-spacing overrides applied. Not once, on any surface.
- We have not evaluated the site-builder editor itself. Three of the lint rules are switched off outside the published-site tree, and our own config records the reason: turning them on repo-wide surfaces hundreds of pre-existing violations in editor-only surfaces.
If you are a school district, a parks department, or any public entity
The Department of Justice's Title II web rule is codified at 28 CFR part 35, subpart H. Its technical standard is WCAG 2.1, Level A and AA — §35.200(b)(3) names the W3C Recommendation of 5 June 2018. The rule does not adopt WCAG 2.2.
§35.200(b) sets two dates. April 26, 2027 for a public entity, other than a special district government, with a total population of 50,000 or more. April 26, 2028 for a public entity with a total population of less than 50,000, or any public entity that is a special district government. Both were moved back a year by a DOJ interim final rule published 20 April 2026 (91 FR 20902), which changed the dates and nothing else. The standard was untouched, and the preamble describes "an ongoing obligation" that continues "in accordance with their existing obligations under title II of the ADA".
Whether your parks department is an independent special district or a department of a city is a state-law and charter question, it decides which of those two dates you get, and we are not going to tell you the answer.
Here is the part that reaches your vendor. §35.200(a) covers web content a public entity "provides or makes available, directly or through contractual, licensing, or other arrangements". The third-party exception at §35.201(c) covers "[c]ontent posted by a third party" — "unless the third party is posting due to contractual, licensing, or other arrangements with the public entity". A member of the public commenting on your page falls outside the obligation. A vendor you contracted with falls inside it. The site your platform gave you is your web content.
DOJ then tells you what to do about that. Its "First Steps" guidance advises public entities to require "vendors to provide detailed information about the level of accessibility of their product before signing any contracts", to "[p]rohibit vendors from disclaiming any accessibility warranties", and to "[r]equire vendors to provide indemnification for any breach". We would rather you knew that before the redlines than during them.
If you are a private league, club or team — and especially in California
California's Unruh Civil Rights Act turns an ADA violation into a state claim carrying statutory damages. Civil Code §51(f): "A violation of the right of any individual under the federal Americans with Disabilities Act of 1990 (Public Law 101-336) shall also constitute a violation of this section."
Civil Code §52(a) then sets damages at "up to a maximum of three times the amount of actual damage but in no case less than four thousand dollars ($4,000)", plus "any attorney's fees that may be determined by the court in addition thereto". Four thousand dollars is the floor, per occasion, with no proof of actual damage needed. In our reading it is the fee-shifting rather than the $4,000 that makes these cases worth filing in volume.
Where the ADA is the predicate there is no intent to prove either. Munson v. Del Taco, Inc. (2009) 46 Cal.4th 661: "A plaintiff proceeding under section 51, subdivision (f) may obtain statutory damages on proof of an ADA access violation without the need to demonstrate additionally that the discrimination was intentional."
There is a defence for a business that exists only online — Martinez v. Cot'n Wash, Inc. (2022) 81 Cal.App.5th 1026 held that an online-only business's website is not a place of public accommodation under Title III. It is unlikely to be available to you. Leagues, clubs, schools and rec departments run fields, gyms, pools and rec centres, and a registration site attached to a physical place is the other line of cases — Thurston v. Midvale Corp. (2019) 39 Cal.App.5th 634, where a WCAG injunction was upheld against the website of a physical restaurant.
One reason the numbers you have seen may mislead you. Seyfarth Shaw counts federal filings only, and counted 3,117 federal website-accessibility filings in 2025 — up 27% on 2024, and 36% of all federal Title III filings that year. In California that same method counted four. UsableNet, which also reads New York and California state courts, counted more than a hundred California cases in a single half-year. That gap is not a contradiction: California plaintiffs file in state court under the Unruh Act, and a federal-only count cannot see them. Both are private trackers with different methods, and their totals should never be averaged.
On overlay widgets
We do not sell, bundle, embed or recommend an accessibility overlay widget, and we do not run one on this site.
The FTC action described above was against an overlay vendor. UsableNet, which tracks filings, reports no meaningful reduction in lawsuits for sites running a widget, and lists widget use among the factors that raise the likelihood of a suit rather than lower it. Weigh that against the fact that UsableNet sells accessibility services and competes with overlay vendors; the direction is corroborated elsewhere, the source has an interest.
We take no position on your behalf. We are telling you what we chose for ourselves and why.
What the rest of this category publishes
This is a statement about what is published, on the dates we looked, and anyone can check it.
Of fifteen website builders surveyed in September 2026, none claimed conformance for the sites its customers publish. Every one of them draws the same line we draw: the platform's own components on one side, the customer's content on the other. The strongest of them go further and enumerate what their tools do not cover, which is the practice we copied.
In the same survey, eight sports-and-recreation platforms — SportsEngine, TeamSnap, LeagueApps, Sports Connect, Jersey Watch, Playbook, SportsPlus and Crossbar — had no accessibility statement, no VPAT and no WCAG claim between them. That is what was published when we looked. Check it yourself before you rely on it, and tell us if it has changed.
We are saying nothing about what that means for their customers. We do not know, and it would not be ours to say.
This is not legal advice
We are not your lawyers and nothing here is legal advice. What the law asks of your organization turns on what kind of organization it is, where it operates and who it serves, and none of that is something a website builder can work out for you. Talk to your own counsel. We will not tell you which deadline applies to you, and you should be wary of any vendor who does.
If you hit a barrier on Gametime Hero, or on a site built with it, tell us. A specific report — the page, what you were using, what happened — is worth more to us than any scan. Send us an accessibility report
