Last week I ended by telling you I had registered as a sole trader and built a studio with accessibility at its spine, not as a chapter. This is what that sentence looked like on one Saturday, when the spine grew a tool.
Saturday, 1 August
Juliet, the designer I met at the Lovable hackathon on 8 March, had already pulled me into one room this year. She wrote to me on LinkedIn in May, inviting me to a private electric go-karting event for design leaders, and afterwards a pub table with eleven other leaders from London companies. I had not felt that particular adrenaline since Turin, when I used to go karting with my colleagues at Changan.
The same WhatsApp group carried a second invitation, to a whole Saturday of building, hosted at Juliet's Metaview office and taught by Mike, UNKWN's founding design director. Nine design leaders, by application, a good mix of terminal and not terminal friendly. I was in the group that had not touched a terminal much.
I arrived with a decision to make. I could spend the day on Quire, the app I have been building and rebuilding for months and which is still far from finished, or I could try to build an accessibility evaluator. Months earlier a stranger had messaged me on LinkedIn to ask if I would take a look at the evaluator he had built, given my experience at Amazon. I tried it last month on one of my own projects and did not understand the report it gave me. The thought had stayed with me since. I had no technical background and a real fear of losing a whole day and making nothing. But I knew accessibility. So I chose the auditor.
Fifty-five criteria
I did not start from code. I started from the accessibility work I did at Amazon and the judgement it left me with. WCAG 2.2, the standard everything is measured against, is thorough and hard to hold in your head, so I worked with Claude to sort its requirements into groups a founder could follow. The four groups are not mine. Perceivable, operable, understandable and robust are WCAG's own principles, and I used the structure that already exists rather than inventing one.
My first list held fifty-two criteria, pulled from memory. A round of research told me I was three short of covering all of WCAG 2.2, so I added them. Fifty-five, every one of them public, every one traceable back to the official guideline.
One list mapped to one standard did not feel like enough, so I built a second layer of checking. I had Claude compare my automated guidance against the tools already wired to WCAG: WAVE, axe DevTools, Lighthouse, AbilityNet, SilkTide, and the WebAIM Million report. Then I wired the whole thing just to axe-core, the open engine that reads a rendered page and reports what it finds, because that was the one touching most of the WCAG checks a machine can do at all.
Which brings me to the number I most want you to keep. Of my fifty-five criteria, a machine can fully clear ten. Thirteen more it can fail but never pass, because finding nothing on a check it only half understands is silence, and silence is not evidence. The remaining thirty-two need a person. No machine picks up a screen reader and moves through your site the way someone who depends on one does every morning. That work is the audit.
You can see this yourself in five minutes. Run any free scanner over a page you own, then count two numbers: how many checks came back clean, and how many it never judged at all. A perfect automated score is ten checks out of fifty-five, and the gap between those two numbers is where the real work has been waiting for you.
The terminal
Then I had to build it, and this is where I stopped being the person in the room who knew things. It is nothing like Lovable. Before you write a line you connect Supabase to GitHub to Vercel, wire in the other services, and grant Claude bypass permission, which means handing it a great deal of control over your own machine. You make a fresh folder it can read and drop your files in, the JSON holding the fifty-five criteria and the screens you designed beforehand if you want accuracy and a design system it will respect, and then you begin.
I made the plan in the Claude app, pasted it into the terminal, and for a while I followed the recommendations almost blindly, because I was no expert and there was no honest way around that. It took me a while just to find the local link where I could see the thing at all, because in a terminal you only see lines of code and fixes, never the page.
Mike carried me through the part I understood least, the plumbing between GitHub, Vercel and Supabase that turns a folder on your laptop into a sandbox you can open. The IONOS domain and Resend I handled alone, and those are what turned the sandbox into something living on a URL and sending real email.
Plenty went wrong. My design system had to be rebuilt inside the project, because the mocks were made before I fixed the inaccessible parts of the system I had already audited myself. Text I had set left-aligned came back centred. I fixed those one at a time, and somewhere in that week the fear went quiet. By the end I was discussing the next steps directly in the terminal instead of the app, which for me was the whole shift.
What I can and cannot claim
A week and a day later, the tool is live and free at scan.alexandra-ciobanu.co.uk. You give it a URL, it returns a score, the full list of criteria, what failed and why, and the checks only a person can sign off. Behind a password I have built myself an auditor's view, where I work through all fifty-five by hand, mark each one meets, fails or not applicable, write my notes, and sign the report before it leaves as a PDF.
Its own tests prove that it is stable, that it returns the same answer twice and has not drifted. Stable is not the same as correct, because I seeded those tests from my own output, which means they would defend a wrong answer just as faithfully as a right one. The only real check on whether I am right is disagreement from outside. When I ran a different tool over my own site, it caught something mine had missed, and that one disagreement was worth more than a hundred of my own runs agreeing with me.
I have now walked my own site through all fifty-five criteria by hand and signed the report. What it scored deserves its own issue, and it will get one.
This week's move
Open a terminal. Not to build a product, not this week. Ask it to make one small thing, one page, one script, something you would not miss if it broke, and stay with it until a link appears that you can click. The move is not the thing you make. It is the ten minutes where you do not understand what you are looking at and keep going anyway.
Mike had brought his six-year-old to the build day. The boy sat coding with Claude in the terminal beside his father, and at the end of the day he stood up and presented what he had made to a room full of people who lead design teams. I have fifteen years in this industry, and I was the one afraid of the black window. Fear tells you nothing about the work. It only tells you how new the work is, and new wears off.
I did not learn the tools and then build. I jumped in with a decision I could defend, no idea where I would end up, and hoped not to drown. A week and a day later there is a machine on a URL that does something useful for strangers.
So what would you make this week, if nobody had ever told you that this part was for other people? And what is the smallest version of it that could be on a screen by tonight?
Alexandra