Last issue I published my own accessibility report, nine failures and a link anyone could open, and said the next thing I would do was take the site into the code. The report is still there, and you can run the same scan on your own site at scan.alexandra-ciobanu.co.uk.
That is done. Before I tell you what was under there, here is how alexandra-ciobanu.co.uk got built in the first place, because the two are the same story.
I rebuilt it seven times.
v1 and v2: structure and words
The first two were not design. They were what the site says and in what order, paragraph by paragraph.
I did not know at the time that this was the most valuable part. I thought it was the throat-clearing you do before the real work. It is the real work. Every version after this one was cheaper or more expensive depending on how well these two went.
v3: the panel of eight
I wrote a prompt that reviews the whole thing from eight directions at once. UX, interface, copy, search, conversion, accessibility, brand, mobile. Three most critical changes each, and what to remove.
It found things I could not see, which is the entire point of asking. I have stopped using it as a one-off prompt since. What it taught me became standing practice: copy and strategy get reviewed before I make a single visual decision.
v4: the marketer
A friend who does this for a living looked at the site and told me what was wrong with it.
Her critique was a different species from the model’s. A model tells you what is missing against a checklist. She told me what a person would think and where they would lose interest. She also pointed her own AI at my site, which is its own small lesson: the same tools give you different answers depending on who is asking and what they already know.
v5: concrete over clever
A real hero instead of a clever one. Named portfolio pieces instead of gestures at capability. Pricing decided and written down rather than left to a conversation.
Every vague thing on that page was vague because I had not decided something yet. That is usually what vague copy is.
v6: the visual accessibility pass
This is where I rebuilt the gradients from stops of matching luminosity, with separate versions for light and dark, because one set cannot serve both themes.
It is also where I found a pattern I have been finding ever since. Eyebrow text, the small line of text that sits above a heading, gets set in the palette’s faintest tone at the thinnest weight available. That combination is what these AI tools reach for by default, and it fails on contrast almost every time. I have now fixed it on my site and on a client’s.
And it is where I added the accessibility panel, deliberately, against advice, so that I would know exactly how one behaves rather than having an opinion about it.
What that pass could not catch is the part I wrote about last issue. The colours passed and the structure did not. Every phrase given its own treatment, a gradient, a colour, a bold word, had been built as a separate piece of code sitting loose inside the sentence, so a screen reader reads the sentence in fragments instead of as one thought. That is not a gradient problem. It happens with an underline, a different colour, an italicised word, anything that makes part of a phrase look different from the rest. Nearly every AI-built site does it.
The second default is the same kind of thing in a different place. My site has a folded menu for phones and a full one for laptops. On a laptop the phone menu is hidden from view, but it was still sitting in the page, so a screen reader announced it and pressing Tab walked straight into it. Hidden to look at, fully present to everything else. Both of these are what the builders produce unless you go and check, and neither is visible in a screenshot.
v7: into the code
The seventh is the one that matters, and it is not a redesign.
A Lovable build writes its code to a GitHub repository. Most people never open it. I pointed Claude Code at mine and had it read the whole thing properly instead of prompting at the surface.
The first thing I did was simplify. I removed the newsletter signup and the table behind it, because I did not want to be holding anyone’s email address on my own site. You are reading this on Substack for that reason. Fewer things that hold personal data, fewer obligations I have to meet properly, and I would rather meet a few properly than several badly.
Then it got interesting.
My hero headline was invisible to anyone with Reduce Motion switched on. Not faint, not slow. Blank, permanently.
Four things on my site arrive by fading in. Sections as you scroll to them, lists that appear one item after another, headlines that come in letter by letter, and the big headline at the top of the page.
Each one starts out invisible on purpose, and the animation is what makes it visible. If you have Reduce Motion switched on, that animation never runs. So every one of those four has to be given a separate instruction: if the animation is off, just be visible from the start.
Someone had written that instruction for three of them. Not for the fourth. The fourth was my headline, so my headline never got told to appear, and it never did.
Reduce Motion is not a niche setting. It is switched on by people who get migraines and people with vestibular conditions, who feel sick when a page moves under them. They arrived at a site that sells accessibility and found a blank space where the sentence should be.
No test failed. Nobody reported it. It was found by going back over all four fade-in effects and asking whether that fix had really covered every one of them.
A test was supposed to walk through my whole site using only the keyboard, landing on every link in turn, the way someone who cannot use a mouse would. It never got past the first handful. It had run eighteen times and passed eighteen times.
It worked like this. As it went, it kept a list of where it had been, and it recognised each link by the words written on it. Three links on my site say exactly the same thing: Posted on LinkedIn. When the test reached the second one, it looked up its list, saw those words already there, decided it had been to this link before, and stopped walking.
The only rule checking the test asked it to reach more than five links. It was stopping right around five, just above the line, so it passed every time and nobody looked again.
Nothing was wrong with having three links worded the same way. What was wrong was the test using the wording to keep count. I changed it to keep count by position on the page instead. The walk carried on past the point it had never crossed and immediately found a real problem that had been sitting there all along: one set of portfolio links showed no outline at all when you tabbed onto them, on every screen size.
The test had never lied to me. It said the links it visited were fine, and they were. It simply never mentioned that it was visiting five of them and then going home.
Another check measures whether my text is dark enough against its background. It kept failing, but on a different part of the page each time I ran it. That should not be possible. The colours are written down in the code and they do not change.
My page fades things in as you scroll. The check was reading the colours while they were still fading, catching them halfway between invisible and finished, and reporting that halfway colour as though it were the real one.
Then a set of results arrived for something I had never sent. I asked Claude to compare my colours against a reference set, and forgot to attach the reference set. It produced the full comparison anyway. Every colour, every difference, worked out to two decimal places.
It looked completely convincing. I only caught it because I stopped and asked whether it had ever actually received the colours I thought I had given it. It had not. The whole thing went.
Three more had the same shape. A note written to say a security check had passed, before that check had finished running. A review telling me my sitemap was missing, because it looked for the file in one place and mine is made on the spot somewhere else. It had been working all along.
And one that was mine, from a different direction entirely.
This one is not in the code. It is in the report I published last week, and I put it there myself when I signed that report off.
My audit tool gives every requirement one of four verdicts. It meets the standard, it fails, it needs a person to look again, or it does not apply because there is nothing on the page to check. I set the ones a machine cannot decide, by hand.
One requirement covers the descriptions attached to images, the words a blind person hears in place of the photograph. My site has images. Their descriptions are adequate, and I wrote a note saying exactly that, along with a suggestion for making them better. Less “Alexa C., in studio” and more of what is actually in the picture.
Then I set the verdict on that same requirement to “does not apply”. No images to check.
The note says the descriptions are there and could be improved. The verdict says there is nothing there at all.
I signed that off on the 3rd of September and it stood for four weeks, including in the report I linked in last week’s issue. I corrected it yesterday. The verdict now says what my own note always said.
Fixing it taught me more than finding it. A signed report is locked on purpose, so that nobody can quietly change a verdict after it has gone out. Correcting one line meant switching that lock off, changing the row, and switching it back on, and the report now shows the right answer with no record anywhere of what it used to say or who changed it. On my own site I can live with that. On work someone has paid for, a correction that leaves no trace is worse than the mistake it fixes. That is the next thing I am building.
The copy of the report that went out as a PDF still carries the old verdict. I cannot reach into a file somebody has already saved.
Seven of them. None was found by something breaking. Every one was found by asking how the result was produced.
What seven rebuilds taught me
Not to rebuild less. To stop skipping.
Six of those versions were me finding out, expensively, what the version before had left undecided. Vague copy because the positioning was not settled. A visual pass that had to happen twice because the first one judged colour by eye. A site that looked finished for months while nobody had opened the code.
If I started today: words and structure first, all of it, before any visual work. Brand foundations before that. A sorted set of references before a single prompt. Build visually. Then into the code before it goes live, not five months after.
That is not a longer process. It is the same work, in an order that means you only do it once.
This week’s move
Do not rebuild anything.
Take whichever page you keep tinkering with and get its words into a plain document. Every heading, every paragraph, in order. No design, no colour, no layout. Type it out, or paste the link into whichever AI you use and ask it to pull the text out for you.
If a section is hard to write, you have found the thing you have not decided yet. That is what your next rebuild was going to be about anyway.
How many times have you redone the look of something, without once opening what is underneath it?
Alexandra
Need an accessible website, or an audit of the one you have? See the accessibility services I offer.