Accessibility

Where we stand

We measure this product against WCAG 2.1 Level AA, the standard U.S. public schools are required to procure against. We are partially conformant: most of the product meets it, and specific known defects do not.

In August 2026 we stopped inferring this from our code and started measuring it. A browser pass walked 459 page-and-role combinations on a simulated phone, reading colour as it actually composites on screen, the real pixel size of every tappable control, the keyboard’s path through each page, and the accessibility tree the browser hands to assistive software. Everything below is a measured number rather than an estimate, and the list got longer as a result.

What we know is wrong

• We have not tested this product with a screen reader. Measurement in a browser can confirm that structure is exposed correctly; it cannot tell you how something is announced, or in what order. This is the largest gap on the page and we would rather say so than let the absence of a known bug read as evidence there is none.
• Some text does not have enough contrast where it renders. Twenty-two distinct colour combinations across 48 pages fall below the 4.5:1 minimum, the worst at 1.09:1 — effectively invisible. Every one is on a staff or administrator screen rather than a student one, and every one passes our design-token checks and fails only once composited, which is exactly why it took a browser to find them.
• On a phone, the navigation menu is not properly separated from the page. Closed, it sits off-screen and a keyboard still walks through it before reaching any visible content — for some roles that is most of what is focusable on the page. Open, it covers the page but does not announce itself as a dialog or keep focus inside. A fix is written and has not yet shipped.
• Sign-in and partner pages have no main-content landmark, so the “skip to content” link on those pages has nothing to skip to. A fix is written and has not yet shipped.
• A few pages render no top-level heading. These are pages shared between roles, where the heading is drawn only on the student version, so a counsellor or parent reaching the same page gets its content with no document title to navigate by.
• Some grouped buttons do not respond to arrow keys the way a native control would. They are individually reachable by keyboard and correctly labelled; what is missing is the arrow-key behaviour somebody familiar with the pattern will expect.
• Small touch targets. WCAG 2.2 asks that tap targets be at least 24 pixels; three places in the product are smaller and crowded enough that the standard’s spacing allowance does not rescue them — the state map on the alumni page, one link on a teacher board, and the school-selector in the administrator top bar, which collapses to a 22-pixel sliver on a phone. WCAG 2.2 is a newer standard than the 2.1 we measure ourselves against, so this is disclosed rather than counted against our conformance claim. We think a district should be told either way.

We publish this list because a district evaluating us deserves to compare it against whatever their own review finds, and because a short specific list is worth more than a general assurance.

What works well

The product is responsive and usable on a phone throughout, not only on the marketing pages. Measured at 320 pixels wide — the width the reflow standard actually names — not one page measured required horizontal scrolling. The keyboard focus indicator measures 8.8:1 in light mode and 10.1:1 in dark, against a requirement of 3:1.

A school’s custom branding colours are measured against a written contract — five fills the product paints text onto, each needing 4.5:1 — and rejected at the point of entry if they fail; the contract exists because a school gold once shipped sidebar text at 1.43:1 and saved without a warning. Our own fixed palette is now held to the same standard by an automated check that measures every text pair in the stylesheet. Dark mode is supported and does not degrade contrast. Accessibility lint rules run as build errors rather than warnings, so a control that cannot be reached by keyboard fails the build.

Tell us

If you hit something that does not work with a screen reader, a keyboard, magnification or voice control, write to accessibility@veristack.dev and describe what you were trying to do. We treat these as defects, not as feature requests, and we will tell you what we found.

If you are evaluating us for a district and need a formal conformance report, we keep a current one in the VPAT 2.5 format — every WCAG 2.1 A and AA criterion, what establishes each rating, which findings are measured rather than reviewed, and an explicit list of what we have not tested. Ask and we will send it.