Accessibility is a first-class citizen at Micropage
I’m visually impaired. Most site builders assume you can drag blocks around a canvas, and I can’t do that reliably. I can work in text and with a keyboard all day.
So Micropage has no canvas. A site is a .page file:
[site]
title: Wit
lang: en
colors:
primary: #b5441b
[Home -> /]
/// hero
h1: Wit, a free writing app
img: A manuscript open in Wit <- wit-hero.jpg
button: Download -> /#download
That file is the whole interface. You can open it in any editor, at any text size, with any color scheme, and search it like any other text. Nothing moves between sessions, and there’s nothing to find by eye.
Use the tools you prefer
Getting a site live should be easy, whatever tools work for you. The same file can be published in three ways:
- A web editor: nothing to install. Write the file in the browser and press Publish.
- Your own text editor and the CLI: keep the file on your machine and run
micropage publish. - An AI agent, through the MCP server: work alongside Claude or Cursor and let it edit and publish for you.
People have different abilities and preferences, so the choice is yours. The web editor works on every plan, and the CLI and MCP server are on Pro.
However you publish, everything is versioned from the start: each publish is a numbered build, and rolling back takes one click.
Sane defaults, from the start
That covers writing a site. The published site matters just as much, and that’s where defaults come in.
Accessibility and SEO aren’t add-ons here. They’ve been first-class citizens from the start, because you shouldn’t have to be an expert in either to publish a good page. If you write nothing special, the basics should still be right, and search engines should still find you. You focus on your content, and we take care of the sane defaults.
Contrast is picked for you
A commenter on Indie Hackers put it well: most people only find out about contrast after they’ve published something unreadable.
In Micropage you pick a theme color, and text on it comes out black or white, whichever has more contrast by the WCAG formula. You don’t have to know what a contrast ratio is.
Wit, the writing app from the sample above, shows both sides of this. Its light theme uses a dark orange, #b5441b, so buttons get white text at 5.52:1. Its dark theme uses a lighter orange, #e07a4f, so the same buttons get near-black text at 6.35:1. The site’s source only names the two colors.
Describing an image is how you add one
The words before an image’s file become its alt text:
img: Our team at the meetup <- team.jpg
There’s no separate field to find. You say what the picture shows, and that’s the alt text.
What every page gets
Every published page also has a skip link, proper landmarks, heading levels that stay the way you wrote them, visible keyboard focus and labelled form fields. The accessibility page in the docs lists all of it.
For search, the basics are generated so you don’t have to remember them: sitemap, robots.txt, canonical URLs, titles, descriptions and Open Graph tags from your markup, and structured data for the site and every post.
Where this is going
I’ll keep developing accessibility as far as I can, along with SEO and ease of use. Those three decide what I build next.
If you want pixel-perfect design, Framer and Webflow are better at that. But if you’d rather write a site than drag one together, the homepage is a .page file too, and you can read its source.