Inspiration

Can You Read Me Now? is the interactive sibling of a broader readability checker I’m building at Readable.FYI The larger tool is meant to inspect real pages; this playground shows designers and developers what makes text easier or harder to read.

I kept noticing the same dark-mode pattern across popular SaaS websites: small, thin gray text on black background. A contrast checker would approve it, but reading it still felt like work. I wanted a way to make that disconnect visible instead of turning it into another acronym soup and standards lecture.

This submission is the standalone playground. The larger checker is a separate project and is not part of this entry.

What it does

The playground lets you change the text color, background color, font size, and font weight, then swap the colors to reverse the contrast polarity.

It shows two results side by side:

  • the familiar WCAG 2 contrast ratio and AA/AAA result
  • APCA contrast together with practical size-and-weight guidance

The opening example uses a pattern derived from several popular SaaS websites: 14px Inter, regular-weight, muted text on black. It comfortably passes WCAG 2 AAA, but the APCA guidance shows why that does not automatically make it comfortable to read.

The interface also preserves keyboard access, visible focus, native form controls, and one consolidated screen-reader announcement when results change.

How I built it

I built the project as a standalone HTML, CSS, and JavaScript site with no framework, package install, or runtime dependency.

The embedded APCA calculation is adapted from Myndex/apca-w3 v0.1.9. It uses the library’s 0.0.98G-4g sRGB constants and its 0.1.7 font lookup guidance. WCAG 2 relative luminance is implemented separately so the two approaches can be compared without conflating them.

Codex with GPT-5.6 was my development collaborator throughout Build Week. I used it to turn the product idea into a working standalone interface, reason through contrast polarity and state changes, iterate on responsive controls and typography, improve semantics and screen-reader behavior, audit the visual system, add dependency-free contract tests, review pull requests, and verify the finished experience in a browser.

I made the product decisions: the problem framing, the deliberately difficult opening specimen, the interaction model, the typography, the standalone architecture, and which recommendations belonged in the final product. Codex helped me turn those decisions into tested implementation quickly.

The hard parts

The opening needed to make the problem obvious immediately, but the finished product could not be useful only for that one demonstration. Supporting arbitrary browser-recognized CSS colors, sizes from 12–120px, weights from 100–900, and either contrast polarity turned it into a real exploratory tool. The labels and results had to remain understandable after the user moved far beyond the starting example.

Fitting that control set onto real screens was its own design problem, especially on mobile. The color fields, swap action, sliders, live specimen, status, and two measurements all needed to fit within the viewport without horizontal overflow or cramped controls. I iterated on the CSS Grid layout so desktop controls stay compact while narrow and short screens use stacked labels, smaller swatches, a shorter specimen, and focus-aware scrolling.

The controls update continuously. Immediate visual feedback is useful, but announcing every intermediate slider value makes a screen reader unusable. The visual result updates immediately while accessibility messages are delayed and combined into one atomic announcement.

Finally, browser color input is messier than a hex-color demo suggests. I used the browser’s CSS parser to normalize supported text colors, rejected transparent backgrounds, and kept the rendered specimen and both calculations synchronized from the same state.

What I’m proud of

The result is deliberately small, fast, and inspectable. It works from a static deployment, has no build step, bundles its fonts locally, and includes automated contracts for layout, semantic color roles, typography, and the opening specimen.

Most importantly, it makes the problem understandable in seconds without becoming a one-use illustration. The starting text passes WCAG 2 AAA, but people can replace every relevant value and ask the more important question of their own typography: Can I comfortably read this?

What’s next

The next step for this tool is adding more body and heading fonts to help builders make sound decisions, while Readable.FYI evolves into a broader checker for existing websites.

Built With

Share this project:

Updates