I turned on a screen reader on my own site and could not find the buy button on the first try
Every RAXXO section now gets a five-minute accessibility pass before it ships, not after a complaint
Alt text has to describe what the image means, not just what it shows
Building the check into the section template beats remembering to run it later
The Day I Actually Used a Screen Reader on My Own Site
I had read the accessibility guidelines more than once. I knew the rules about alt text and contrast ratios and heading order in the abstract way you know a rule you have never actually tested against your own work. Then one evening I turned on my laptop's screen reader, closed my eyes, and tried to buy something from my own store the way a blind visitor actually would.
It took me almost two minutes to find the add-to-cart button. Not because the button was hidden. It was right there, styled the way I wanted, sitting exactly where a sighted visitor would expect it. But the screen reader read it out as "button," nothing else, because I had never given it a label. It read a hero image as "image," skipping straight past the headline I had spent an afternoon getting right, because the headline lived inside a background image instead of real text. It read a product card's price and skipped the product name entirely, because the markup order made sense to my eyes and not to a reader that moves through a page differently than a scroll does.
None of this was a dramatic failure. Nothing crashed. The store still technically worked. But "technically worked" and "worked for the person actually using it" turned out to be two different bars again, the same gap I had already run into building OhNine's onboarding screen three separate times before it landed. That gap kept showing up in different corners of the studio, and I kept treating each instance as a one-off surprise instead of a pattern worth building a real check around.
The uncomfortable part was realizing how long the gap had been sitting there in plain sight. Every section I had shipped up to that point had passed my own eyes, my own mouse, my own habits. None of it had passed a tool that actually depends on structure instead of visual layout. I had been grading my own work on a test I was guaranteed to pass, because I was the only one taking it.
Contrast, Focus, and the Checks That Take Five Minutes
The fixes, once I knew what to look for, were fast. That was the second surprise, after the first surprise of discovering the problem at all. Nothing about making a section more accessible required rebuilding it. It required checking a short list of specific things before calling it done, the same way I already checked a section against a design system before calling it consistent.
Contrast is the first check, and it is the most mechanical. Text has to hold up against its background at a ratio that survives more than good lighting and good eyes, and I run every new section's color pairs through a checker before it ships rather than trusting my own screen, which is calibrated, bright, and nothing like the phone someone is reading on outdoors at noon. A pairing that looks fine on my desk has failed this check more than once, and every time it did, the fix was a shade, never a redesign.
Focus states are the second check, and they are the one sighted visitors never notice is missing until they try to use a keyboard instead of a mouse. Tab through a page with your hand off the trackpad and you find out fast whether a link, a button, or a form field shows you where you are. For a while, several RAXXO sections had focus states that were either invisible or removed entirely, because a default outline looked messy next to the rest of the design and getting rid of it was one line of code. Removing that outline without replacing it with something visible is one of the most common accessibility mistakes on the web, and I had made it without noticing, because I never once tried to navigate my own site without a mouse.
Heading order is the third check. A page should read top to bottom the way an outline reads, one H1, then H2s in order, without skipping a level because a smaller heading happened to look better in a particular spot. A screen reader user often jumps by heading level to navigate a long page the way a sighted visitor scans with their eyes, and a heading order that skips around breaks that navigation even when the visual hierarchy looks perfectly fine to anyone looking at it directly.
Form labels are the fourth check, and they are the one I underestimated the most. A placeholder sitting inside an empty input field looks like a label to a sighted visitor, because it occupies the same visual space a label would. It disappears the instant someone starts typing, and it was never actually connected to the field in a way a screen reader can announce, so a form that looks fully labeled on screen can announce itself as a string of unnamed fields to anyone not looking at it. The fix is a real label, connected to its field, visible or not, every time. It is a small piece of markup that changes whether a checkout form is fillable at all for a meaningful number of visitors.
Alt Text Is a Sentence, Not a Keyword
Alt text turned out to be the check I had the most wrong, and it is worth its own section because the mistake is so easy to make without noticing. I used to write alt text the way I would write an SEO keyword, a short phrase describing the literal contents of an image. A product photo got alt text like "black hoodie front view." Technically true, completely useless to someone who cannot see the photo and is relying on that sentence to understand what is being sold.
The fix was thinking about what the image is doing on the page, not what it literally contains. A product photo's job is to help someone decide whether to buy, so its alt text needs to carry the details a sighted visitor gets for free by looking, the fit, the material, the detail that makes this hoodie different from a plain description in the body copy. A decorative image, on the other hand, one that adds nothing informational and exists purely for visual rhythm, should often have empty alt text on purpose, so a screen reader skips it entirely instead of reading out a description of nothing useful. Writing alt text well means asking, every time, whether this specific image is carrying information a reader needs, and then writing the sentence a person would actually want to hear instead of a label a search engine would want to index.
This distinction matters more across five different RAXXO products than it would for one site, because the same mistake, once made, replicates itself across every new section built off the same habits. Fixing alt text one image at a time is a chore. Fixing the habit that produces bad alt text changes every image after it.
Building the Check Into the Section, Not Bolting It On After
The real lesson from all of this was not any single fix. It was that an accessibility pass done after a section ships is a pass that gets skipped the first time I am in a hurry, and I am in a hurry more often than I would like to admit. A check that lives only in my memory competes with every other thing I am trying to remember on a given day, and memory loses that fight eventually, usually on the day it matters most.
So the check moved earlier, into the same place the four-pass shipping check already lives, as a required step rather than a hopeful intention. Before any new section goes live, it gets checked for contrast, tabbed through without a mouse, scanned for heading order, checked for real form labels, and read back for alt text that actually describes what an image means rather than what it shows. None of these checks take more than a few minutes individually. Together they take less time than writing the section's copy did.
I keep a short written list next to the section template for exactly this reason, the same way a pilot keeps a checklist instead of trusting memory for a routine that has to be right every single time. A list on paper does not care whether I am tired, rushed, or certain I already know what it says. It just sits there until I run it, and running it is the entire point. The moment I trust memory over the list is the moment the list stops doing its job, so I do not let myself skip reading it even on a section I am sure is fine.
What changed was not effort. It was sequencing. A check that happens before publishing catches a problem while it is still cheap to fix, a color value or a missing label. The same problem caught after publishing, by a real visitor who cannot use the page, costs a person their actual experience of the store, not just my time. Those are not the same kind of cost, and treating them as interchangeable was the mistake underneath the mistake.
I do not think of this as a compliance checklist anymore, something to satisfy so nobody complains. I think of it the same way I think about testing a tool cold before shipping it: a way of seeing the thing I built through eyes that are not mine, because my own eyes will always miss what they are used to seeing past. A screen reader is just a very honest second opinion, and it does not care how the section looks. It only cares whether the structure actually holds up.
Bottom Line
The two minutes it took me to find a button on my own site with a screen reader taught me more about what "finished" actually means than any design review had. A section that looks right and reads wrong is not finished, it just looks finished to the one person guaranteed to already know where everything is.
Contrast, focus states, heading order, and alt text that means something are not a separate accessibility project bolted onto RAXXO's design work. They are part of the same shipping check every section already goes through, because a tool nobody can navigate is not a smaller version of the tool. It is a different tool, one that only works for people who move through a page exactly the way I do. Building for people who do not is not extra credit. It is the actual job.
Top comments (0)