Most explanations of how a website gets made rely on pictures: a diagram of boxes, screenshots of the design tool, a video of the page coming together. If you can't see them, they don't explain much. This is a version without them. A website is a series of decisions, and most of them get made before there's any code. I'll go through the stages I use, one at a time, and point out where a decision is something you'd notice with a screen reader.
1. The first conversation
A project starts with a conversation. I ask the client what they want the site to do, what's wrong with the one they have, who the organization serves, and what they want those people to do. I'm trying to find out what the site's job is, because everything after this depends on it. One client's strategic plan said two things clearly: they wanted more survey responses and more people at their quarterly meetings. On the site they had, the meeting announcement was at the bottom of the home page and the survey took five clicks to reach. For someone using a screen reader, that put the two things the organization cared most about at the end of the reading order and five page loads away. Those two goals became the first items on the new home page, and every decision after that traced back to them.
2. Looking at what's already out there
Next I look at what similar organizations have already built. The tool I use for this is a mood board, which is a collection of screenshots, fonts, and images, so this is the most visual stage in the process. The decision underneath it isn't visual, though. I'm deciding what to keep and what to change. For that same client I went through a lot of comparable government and nonprofit sites, and the pattern I kept running into was the brochure: a home page that tells you what the organization is but never asks you to do anything. Everything sits at the same level and nothing points anywhere. My rule at this stage is that if I don't like something, I change it, until I find out why it was that way.
3. The sitemap
This is the stage that decides most of what you'll hear. A sitemap is a list of every page on the site, arranged in a hierarchy, with the home page at the top, the main sections under it, and any subpages under those. Under each page I write a bullet list of the sections that page will have, in the order they'll appear. That list is the reading order. Whatever I put first is the first thing a screen reader reads after the navigation, and whatever I put last is what most people never reach. The top level of the sitemap also becomes the navigation menu, so the order I choose here is the order you'll tab through on every page. For the client with the survey and the meetings, I also had to think about what a visitor would want to know before they'd fill out a survey or show up to a meeting. Who are these people? What does the organization do? Why should I trust them? I try to frame the ask as something that helps the visitor, but people still have questions once they've been asked to do something. The ask goes at the top of the home page, and the pages that follow it are there to answer whatever comes next.
4. Wireframes
A wireframe is a rough sketch of a single page, with boxes standing in for text, images, and buttons, and no color or real type. This stage started on paper for me and still works the same way. I get every idea out, keep the old versions, and keep iterating until something feels right, sometimes going back to the mood board to pull me in a different direction. I often work by section rather than by whole page. Choosing the final version is mostly a gut feeling. Most of what a screen reader user would notice is already settled by the sitemap, so what I'm doing here is arranging. In the back of my mind I'm also keeping an inventory: how many heading levels the site will need, how many images there will be, and the alt text each one is going to need. The last wireframes get real copy added, so this is also the first point where the words you'll actually hear exist.
5. Style guide and mockups
Now the visuals get decided: colors, fonts, icons, spacing. I collect those into a style guide, then apply the guide to the finished wireframes to make the final designs. Along the way I pull out anything reusable, like buttons, cards, and menus, into a design system, so the same element looks the same everywhere on the site. This is also the stage where how something looks and what it is in code get separated, and that took me a while to learn. I used to think the h1 had to be the largest heading on the page, and it always looked strange next to the body copy in the hero section. Then I started thinking of the page as a set of sections. If someone is only looking at one section at a time, it doesn't matter whether a heading in one section is bigger than a heading in another, and importance can be shown other ways, like the hero being the only section with an image background. Where the heading levels matter is accessibility. They give the whole page a structure. A sighted person scans the page to find that structure, and a screen reader user may pull up the headings list instead, so the list needs to make sense on its own. None of my clients have ever asked about this. They see the visuals, and they don't care whether something is an h1 or an h6 as long as visitors aren't complaining.
6. Build, launch, and fix
With the design decisions made, writing the code is the least dramatic part. What I'm thinking about is whether the code will be easy to change and whether it does what the design promised for a screen reader. Those two things are connected, because of how I test. I do a pass myself, but I've never had recruited or paid testers, so most of my accessibility feedback has come from people using the site after it's live. The site launches and I fix things as they come up. The fixes are usually small, a missing alt text here or a heading out of place there, so the code needs to make small fixes quick. The reusable elements from the design system become reusable pieces of code, which helps: fix one button and every button is fixed. If I have to go hunting for where something lives, I'll put it off until several people have reported the same thing. For a site that's mostly information, following the accessibility guidelines closely gets you most of the way there. It's apps, with forms and tasks that run across several pages, where things get messy, but that's a different article.
One more thing, because it's part of the process too. I use AI for a lot of the work above. I have low vision, and moving visual elements around a page is slow and tiring for me, so it's easier to tell an AI what to change and check the result. It doesn't always save time, but it saves strain. It's also why the testing in stage 6 matters more than I'd like. I'm not a native screen reader user, so my own pass only catches so much. I know what a badly built page costs. I just don't run into it the same way someone who uses a screen reader all day does.
None of this is the process. It isn't the best process. It's just how I do it.