Accessibility
What we do about accessibility, and what we do not
We are not going to tell you that a site you build here is accessible to everyone, or that it satisfies any law. Nobody can honestly tell you that about a site whose content they do not control, and the last vendor who said something close to it paid the Federal Trade Commission $1,000,000.
So here is the other kind of answer: the specific things that exist in the product, the checks that run and can fail, and the list of what we have not done.
1
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.
2
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.
3
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.
4
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.
We do not sell, bundle, embed or recommend an accessibility overlay widget, and we do not run one on this site.
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.
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
Read the long version: who is on the hook, and what a builder can honestly say
