Six Design Decisions I Made for Windrow, and the Two I Reversed

Building an accessibility-first website builder means saying no to things people expect. No brand color that fails contrast. No unverified AI alt text. No lock-in. Six decisions define Windrow.

Windrow is live now, so it seemed like the right week to write down what I chose and where I was wrong.

They are all versions of one idea: accessibility is not a feature you add at the end, it is the ground the whole site grows from. That sentence is on the marketing site, and I wrote it before I wrote any of the code, which is unusual for me and turned out to be the reason the product is coherent.

Every one of those is a no. That is the job.

Because the color picker is where accessible sites go to die. Windrow has one. It just will not save a color that fails.

I wrote about the publish gate back in October, so I will not repeat it. The color decision is the one that generates actual email.

Windrow's themes come with their colors already worked out: page background, surface, body text, muted text, link, border, focus ring. Every pairing in a theme passes before the theme ships. What you can change is your brand colors, and the picker lets you choose any shade you like. Then it checks each one against the colors it sits next to: your primary color against the page and against the label on your buttons, your accent against the text on top of it. Every pair has to reach 4.5:1. If one does not, the color will not save, and Windrow shows you two or three shades that pass, with the ratio each one gets.

So you can pick #8FA9C4 because it is the exact blue in the brand PDF from 2019. What you cannot do is save it with white text on it.

I got a support email about this during beta. Paraphrasing: our brand color is our brand color, and your tool is telling me my organization's identity is wrong.

Here is what I wrote back, more or less. Your brand color is fine. Your brand color as a background for 16px white body text is 2.4:1. The floor is 4.5:1, and anyone reading your page with low vision will work harder than they should to read it. Keep the color. Use it for the thing it is good at: a header band with dark text, a button with dark text, a rule under a section title. Do not use it as a canvas for white text.

They kept the color. They moved it. The site looks like them and reads like something a person can actually read.

I am not going to pretend that conversation is fun. It is a conversation the tool forces, over and over, with strangers. I kept it anyway, because the alternative is a builder that lets a nonprofit ship an unreadable site and then tells them it scored 98.

Because the AI is good enough to be dangerous and not good enough to be trusted.

Windrow will draft alt text for you. Open an image in the media library and press Suggest alt text. It is genuinely decent at "two people shaking hands in an office" and genuinely terrible at knowing that the point of the photo is the sign behind them. Alt text is not a description of pixels. It is a description of why the image is on this page, and no model on my budget knows why.

So the flow is fixed. The AI's draft lands in the field, and nothing is saved until you read it and save it yourself. You can keep it, rewrite it, write your own from scratch, or mark the image decorative. Until an image has a description or is marked decorative, the page does not publish.

That is one extra step per image and it is the only place in the entire product where I deliberately made something slower. Twenty years of audits taught me that the problem is almost never that people write bad alt text. It is that the tool let them write none and publish anyway.

Static HTML export ships in every tier, including free.

You can take your site out of Windrow as a folder of HTML, CSS, images, and a sitemap, put it on any host, and never speak to me again. No proprietary shortcodes. No JavaScript runtime that phones home. No "export" that hands you a database dump you cannot do anything with.

I know exactly what that costs me in retention. I built it first anyway, because I have spent two decades cleaning up after platforms that made leaving expensive, and the whole argument of this company is that if you cannot leave a tool easily, you were never really using it. It was using you.

Same reasoning behind the auto-updating accessibility statement. A statement that claims full conformance, has no date on it, and lists a contact address nobody monitors is worse than having no statement at all, because now you have made a written claim you cannot support. Windrow generates the statement from what the site actually does, stamps it with a date, and updates it when the site changes. You give it the contact address people use to report a barrier, and if you leave that blank, the statement says so in public. You cannot make it say something the build does not support.

Windrow is live now. If you want to try it, start free on windrow.app. If you want to argue with any of the six above, reply to this and tell me which one you would drop. That is how two of them changed the first time.

I manage web for an academic medical center. Everything I write about that work comes from what is already public. Opinions are mine.