Accessibility statement
I have spent years doing accessibility work in enterprise software: WCAG guidelines alongside a design-systems team, VPAT coordination for federal sales, EAA readiness for European business. It would be strange to publish a portfolio that didn't hold to the same standard.
This site targets WCAG 2.2 Level AA.
It was designed against those criteria and tested as it was built, rather than audited at the end. I am claiming a target, not a certification. No third-party audit has been performed.
Where a criterion reaches Level AAA without compromising the design — color contrast on body text, for instance — it is met. I have not degraded the design to chase AAA everywhere.
Keyboard operable
Every control — navigation, case-study cards, the before/after compare, image previews — is reachable and operable by keyboard. A skip link opens the tab order, and Escape closes the image viewer.
Visible focus
Focus is never hidden. Focused elements take a 2px accent outline with a 3px offset, in both themes.
Contrast
Body text, labels, and links clear 4.5:1 against their backgrounds in both light and dark. The teal accent is split into two values so that text and fills can each meet contrast on their own terms.
Motion
Nothing moves on its own for long, nothing flashes, and every transition and animation is reduced to an imperceptible duration under prefers-reduced-motion. The one thing that animates unprompted is a ring around the Ask control, twice, over about a second and a half — once per visitor, and never again. Under reduced motion it does not animate at all.
Structure and names
One h1 per page in a sensible heading order, real landmarks, and an accessible name on every control. Product screenshots carry descriptive alternative text.
Targets and zoom
Interactive targets meet the 24×24 minimum, and the layout reflows without horizontal scrolling down to 320px and up to 200% zoom.
The assistant
The most complex thing on the site, so it gets said explicitly. It opens from a control in the header and closes with Escape, which puts focus back on that control. The question field submits with Enter or the send button, and its label is the visible heading above it rather than a hidden one. The conversation is a live log region, so a screen reader announces the answer when it arrives instead of leaving it silent. The same applies to a loading state, an error, and the notice that a session is running out of questions. Focus stays in the field, so you can ask again without going to find it, and the thread does not animate its scroll under prefers-reduced-motion. On a phone it opens as a sheet over the page, so the page behind it is made inert and focus stays inside it until you close. On a wider screen it docks to the side and the page moves across to make room, so nothing you can click ever ends up underneath it. The opening line types itself out, which is decoration and treated as such: the live region is muted while it does, so a screen reader is given the whole sentence once rather than a hundred fragments of it, and under prefers-reduced-motion it simply appears.
Honest ones, because a statement without them isn't worth much:
- The product screenshots are images of complex enterprise interfaces. Alternative text describes what each shows and why it is here; it cannot convey every value in a dense table.
- The annotated before/after compare is a visual exercise by nature. The written analysis beside it carries the same points for anyone who cannot use the comparison itself.
- The assistant runs behind a bot check at the edge. It stays invisible unless a visitor actually has to solve a challenge, but it is a third-party widget, and if one appears its accessibility is not mine to control.
- Testing has been manual — keyboard, zoom, contrast tooling, reduced motion — plus screen-reader spot checks. It has not been through a full assistive-technology matrix.
Tell me and I will fix it. Accessibility bugs on my own site are the ones I most want to hear about.
eric@waitwut.com →LAST REVIEWED · JULY 2026