Accessibility on a zero-server budget

The problem

The cycling-tracker market is dominated by venture-backed apps that pay for accessibility (when they pay for it) out of a marketing budget that doesn't exist for solo products. The default conclusion is: AAA isn't realistic at €14.99 one-time without funding.

Sluip rejects that framing. The constraint that AAA needs budget is a tooling problem, not an accessibility problem. Sluip is one HTML file. It runs in the browser. It uses the device's localStorage. Every accessibility decision was a design decision before it was an engineering decision.

The decisions

• Single HTML file. No build pipeline, no server, no dependency tree. Means accessibility regressions can't enter via a vendor update — there are no vendor updates.
• No accounts, no PII, no telemetry. GDPR scope = zero personal data collected. The product cannot violate a user's privacy because it doesn't have access to it.
• AAA in both themes. Both light and dark themes designed to clear the §02 AAA contrast thresholds. The dark theme was harder — most "dark mode" palettes are AA on the surface and AA-or-fail on the form controls.
• Touch targets that work for tremor. All interactive controls meet WCAG 2.2 SC 2.5.8 (Target Size) at 44×44 CSS pixels minimum. The cycling-pause control specifically is 56×56 because cyclists' hands are often gloved.
• Status without color, again. Ride state (active / paused / ended) signals via icon + text label, never color alone.
• Keyboard PWA. Yes, a cycling app has keyboard support. Yes, that matters — for users who use a screen reader to preview a route before going outside.

What it cost (time, tradeoffs, surprises)

• Time: AAA on a 1-file PWA cost roughly the same as AAA on a multi-page app. The win was that the AAA work wasn't multiplied across 20 templates.
• Tradeoff: No cloud sync. Users who lose their phone lose their ride history. Documented in the product page. The trade was deliberate — privacy and accessibility share a constraint: the simpler the system, the fewer the failure modes for the end user.
• Surprise: The hardest AAA target on Sluip wasn't visual — it was making haptic feedback (used to signal a successful ride pause) accessible to users with motor differences. Haptic isn't standardized across devices. Solution: pair every haptic cue with a visible animation.

What I'd do differently

• Ship the dark theme first. I built light, then iterated dark twice. Dark theme always reveals the hardcoded colors in the system.
• Document the constraint budget publicly. Sluip's accessibility achievement isn't impressive in isolation — it's impressive given the budget. That's a sales argument the product page doesn't make explicitly.
• Pre-write the FAQ entry "why no cloud sync." Users assume cloud sync is a feature; for Sluip it's a deliberate omission. Pre-writing the rationale would have saved 30 support emails.

Why this matters if you're hiring an auditor

The conventional argument against accessibility-first design is budget. Sluip is the counter-argument at the smallest scale that argument can run on: one developer, one HTML file, one €14.99 price point, AAA in both themes. If your site has more than that, AAA-aligned WCAG 2.2 AA is achievable in your engagement.

If you're looking for an EAA audit, the EAA Readiness Audit package starts at €2,400 fixed. I'll bring the same standards I applied to Sluip.