Shipping WCAG AAA-aligned from line one — what it actually took

The problem

Most freelance-workspace tools assume SaaS economics: monthly billing, team seats, login flows, analytics, telemetry. That model creates accessibility tax at every layer — every form is a different form, every dialog has different focus semantics, every email opens in a different webview.

Hour Terms takes the opposite bet: one HTML-and-PHP install, run on the freelancer's own server, with no third-party JS, no tracking, and no account system. The accessibility goal was AAA-aligned within a defined scope (invoice flows, authentication, dashboard, dark theme) — not "AAA where convenient," and not "AAA everywhere." That scope and its limits are documented in the linked accessibility statement.

The decisions

This section documents the technical decisions that made AAA-aligned conformance achievable on the build budget of a solo developer.

• Self-hosted by design. No third-party scripts means no accessibility regressions from a vendor update I didn't approve.
• Status without color (WCAG 2.2 SC 1.4.1). Every status indicator (paid, overdue, draft, signed) pairs a colour cue with a textual/iconic cue. Colour is never the sole signalling channel.
• Focus management for modal dialogs (SC 2.4.3 Focus Order, SC 2.4.11 Focus Not Obscured). When a dialog opens, focus moves to the dialog heading. When it closes, focus returns to the trigger. Implemented without a JS library — vanilla focus() calls with a focus-return stack.
• Dark mode that passes contrast (SC 1.4.6 Contrast Enhanced, AAA, 7:1 on body / 4.5:1 on large). Both themes have been verified against AAA contrast thresholds for every surface listed in the accessibility statement, with identical axe-core configuration in both.
• Keyboard-first form flows (SC 2.1.1, 3.3.1, 3.3.3). Tab order matches reading order. No tabindex values above 0. Submit buttons are reachable without mouse. Forms validate inline with aria-invalid and aria-describedby pointing to the error message.
• Honest about what's not AAA. Two surfaces remain AA-only and are listed in the accessibility statement under "Scope of AAA-aligned testing." Claiming those as AAA would be the inverse of what this case study argues.

What it cost (time, tradeoffs, surprises)

• Time: AAA-aligned scope added roughly 30% to the build time over the equivalent AA-only target. Most of that cost was in dark-mode contrast iteration and dialog focus testing.
• Tradeoff: No analytics. I cannot tell you how many users hit a specific page. The trade was deliberate — telemetry is an accessibility-and-privacy tax I declined to pay.
• Surprise: The hardest AAA target wasn't a screen-reader interaction — it was getting all 4-pixel UI strokes to AAA contrast against every theme variant. Standard Material/Tailwind palettes don't survive AAA at small stroke widths; I had to hand-tune the brand palette.

What I'd do differently

• Earlier formal axe-core CI gate. I retrofitted that around month 4. Doing it from commit one would have caught two slow regressions earlier.
• Document the partial-AA areas in the public docs sooner. They were noted internally for months before publishing.
• Build the keyboard-shortcut help dialog before the keyboard shortcuts. I shipped the shortcuts in v1.2, then realised power users couldn't discover them without a help affordance. Help dialog shipped in v1.3.

Why this matters if you're hiring an auditor

I'm not arguing every product needs to ship AAA-aligned. Hour Terms is a deliberate edge case: a small product where the constraint was tractable. What I am arguing is that when I audit your site for EAA conformance, I know what it costs in build time, what trade-offs I asked of my own engineering, and where AAA actually breaks down in practice. That perspective is rare among auditors who have never shipped accessibility-first.

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 apply to Hour Terms.