How we audit accessibility (and what we do not claim)

Measured, not certified

Plenty of software claims WCAG conformance on the strength of a single consultant report from two years and four hundred deployments ago. That claim decays the moment the next feature ships.

We take the opposite position: accessibility is a property that has to be re-measured on every change, and the honest thing to publish is the measurement plus the gaps. Our target is WCAG 2.2 Level AA. What follows is exactly how that target is enforced, and exactly where the enforcement stops.

The gates that run on every change

1. Static analysis on every commit. An accessibility lint rule set runs alongside the normal linter, catching missing labels, invalid ARIA attributes, click handlers on non-interactive elements and similar structural mistakes before code is even pushed.
2. Automated engine sweep. An accessibility engine runs against Tier-1 and Tier-2 routes in a real browser. Any critical or serious violation that is not in the baseline allowlist fails the build.
3. Lighthouse floor. Every Tier-1 route must score at or above 95 out of 100 on the accessibility category, on both desktop and mobile presets. The per-route score table is published with each run, so a drop is attributable to a specific page.
4. Contrast audit. Every design-system colour pair is measured in both light and dark themes, backed by a runtime check on rendered text.
5. Behavioural end-to-end tests. Focus traps, Escape handling, focus restoration, live-region text and keyboard-only navigation are asserted as behaviour, not inferred from markup.
6. Visual regression. Key surfaces are snapshotted in light and dark across a device matrix, so an unintended contrast or layout change surfaces in review.

Automated tooling reliably catches a minority of real accessibility barriers. We state that plainly rather than presenting a green pipeline as proof of an accessible product. The gates prevent regressions; they do not certify the experience.

How routes are tiered

• Tier 1 — audited and remediated. Home, the sign-in wizard, onboarding, the farmer dashboard, pricing, contact, help and the accessibility hub. Zero critical or serious automated findings, and these are the routes under the Lighthouse floor.
• Tier 2 — covered. The technician, doctor, exporter and lab-tech dashboards, the four-view wizard, Field Mode, the marketplace and the calculator entry points.
• Tier 3 — inherited. The wider calculator suite and internal admin consoles. Built from the same audited component library and subject to the same lint rules, but not swept route by route.

Shared shells were hardened first — the dashboard layout, navigation, footer and the underlying component wrappers — so a single fix cascades across every role dashboard instead of being repeated thirty times.

The baseline allowlist as a ratchet

Switching on a strict gate against an existing product blocks every change until an unrelated backlog is cleared, which in practice means the gate gets disabled. So the gate is a ratchet instead.

A checked-in baseline records the violations that already existed, keyed by route, rule and element. Anything not on that list, at critical or serious severity, fails the build immediately. Entries leave the list only by being fixed, and regenerating the baseline is an explicit, reviewed action — never something a build does silently. The result is a number that can only go down.

We use the same discipline for security baselines, for the same reason: a gate that can quietly rewrite its own expectations is not a gate.

The manual pass we have not done

A third-party manual audit with real assistive technology — VoiceOver on macOS and iOS, NVDA on Windows, switch control, voice control, and testing with users who rely on them daily — has not been performed. It is planned.

Until it happens, every accessibility claim on this site comes from automated tooling, and should be read that way. Known limitations we already publish include sensor charts, map surfaces, generated PDF reports and third-party embedded checkout.

How to report something we missed

The report form on the accessibility hub captures the page, your browser and the barrier you hit, and optionally emails you a confirmation with a reference. Reports are triaged within two business days and a barrier that blocks you today is treated as a priority rather than queued behind the next scheduled sweep.

Reports from people using assistive technology are the highest-value accessibility signal we receive — they routinely find what the entire pipeline above cannot.