Digital transformation baseline · Article 5
Your Alt Text Is Your Hosting Provider's Name
A screen reader announces a logo by its alt text. On the old site, a visitor using one wouldn't have heard this company's name at all — they'd have heard the hosting provider's own auto-generated server address, word for word. It was reported fixed once. It wasn't. Here's what actually closed it.
Fifth in the digital transformation baseline series.
A logo's alt text has one job: tell someone who can't see the image what it is. On every page of the old site, that job was being done by a string nobody had written on purpose — the web host's own temporary, auto-generated server address, the kind every hosting account gets before a real domain is pointed at it.
What a visitor using a screen reader actually heard
Sighted visitors saw the company's logo, same as always. A screen reader user landing on the same page heard the logo announced by its alt attribute — and instead of the company name, that attribute held a long, machine-generated hosting hostname: the kind of string a control panel invents automatically the moment an account is created, never meant to be read by anyone, let alone read aloud as the first thing a visitor hears about who they've landed on.
This isn't a hosting provider doing anything wrong — every host needs some placeholder address before a domain is attached, and that's a completely normal, temporary artefact. The defect is that it was still sitting in the alt attribute of a logo on a live, indexed, production website, months after the real domain and real branding were in place. Nobody had gone back and checked what was actually in that one attribute.
Reported fixed once
Verified fixed is not the same claim as reported fixed — and only one of them is true until someone actually checks.
The part worth dwelling on
This finding was flagged, and word came back that it had been corrected. The following day, a fresh check against the live site — not a cached copy, a direct fetch — showed the exact same leaked hostname still sitting in the same attribute. Nothing had actually shipped. The gap wasn't dishonesty; it's the ordinary, easy way a one-line fix on a page-builder platform can get made in a preview, then never actually published, with nobody the wiser until someone goes back and checks the live output byte for byte.
That's the operational lesson underneath the accessibility one: a status update is not evidence. The only thing that closes a finding is checking the thing itself, again, after the fix is supposed to be live — which is exactly what the second check here did, and exactly why it caught what the first "fixed" report didn't.
What actually closed it
The rebuild doesn't just replace the value in that one attribute — it changes the structure so the failure mode can't recur the same way. The company name is now live text next to the mark, not pixels baked into an image with a caption bolted on after the fact; the icon beside it carries an empty alt="", because the adjacent text already names the link and a screen reader shouldn't announce the same thing twice. Real text also beats an image's alt attribute on its own merits — sharper at any zoom level, and impossible to accidentally leave holding a leftover hosting artefact, because there's no attribute left to leak from.
On top of that: the exact hosting-hostname pattern is now a hard build failure. If that string ever reaches the compiled output again, for any reason, the build stops rather than shipping it — turning a defect that survived one "it's fixed" report into one that can't survive a single deploy.
The through-line
For a firm that sells digital competence, the specific failure here matters more than its size: the one visitor most likely to notice — someone relying on a screen reader, exactly the audience accessibility work exists for — was the one visitor guaranteed to hit it. Fixing the value once wasn't the fix. Checking that the fix actually shipped, and building a rule that keeps checking after you stop looking, was.