One day my friend the lawyer called me. She said she wanted her own website so clients could find her. Then she said her AI assistant told her she could build it herself.

My hair stood up. I know exactly how hard that is, and I could already see her giving up.

I have maintained her computers for years. I know her patience with software. So I asked her one question. Do you want a website, or do you want to learn how to build websites?

She wanted a website. Of course she did.

The AI had made it sound easy. It is not easy. A professional, accessible website needs experience, patience, and some understanding of what HTML and JavaScript can do. I also know what ready platforms like WordPress give you, and what they take away.

So I offered to build it for her. I also advised her against WordPress. She would have to fight the editor every time she writes an article.

The second call

Then another friend called.

She knows computers better and she is more confident. She told me she wanted to build her site on WordPress. I said go ahead, and call me if you hit a problem.

She called a few months later. She sounded desperate. She was close to giving up, and her project matters far too much for that. She was stuck on the appearance and on some important settings.

I said yes gladly. I know WordPress very well from building accessinfocus.com. What took her months to understand took me two days to go through and fix. Then we started the fine tuning. She is hopeful again, and now she can think about her content instead of her theme.

She still finds the WordPress editor hard to use. So I showed her a workaround that sounds strange at first. She publishes from the code editor. For her it is clearer and faster.

Building Access In Focus taught me how to help my blogger friend. Building Reysko.app taught me how to help my lawyer friend.

Here is what each project gave me.

When I write the code myself

For my lawyer friend I built a static site with Astro. Astro turns pages into plain HTML before anyone visits them. I decided how every part of the page is built, from the titles to what happens when you move through it with a keyboard. No theme sat between my code and the browser.

I also built her a dashboard. She publishes an article in a few clicks. It is fully accessible and shaped around how she works, not around a ready platform. Her contact form is custom too.

The Reysko.app site is custom as well. There the code was easy and the content was hard.

The site publishes a timetable for every line in every city the mobile app supports. At first each one was a long run of times. One block held 247 departures. You lose your place and you take the wrong bus.

So I made a table, hour by hour. The hour in a row header, the minutes beside it. The accessibility tree looked correct.

Then I opened it with a screen reader. It read 05, then 05 22 39 54. I could not tell the hour from the first minute.

Now every departure sits in its own cell. Each cell carries the whole time, spoken but never shown.

Both sites score 100. The timetable scored 100 before that fix too. The score never saw the problem.

WordPress with a paid theme

Access In Focus runs on WordPress with a paid theme and a lot of customisation. I wrote custom JavaScript for several elements. I built my own plugins too, one for booking a meeting and one that lets visitors estimate the cost of my services. Both are accessible because I wrote them.

I got close to 100, but not the same as custom code.

I did not write the theme. I can override its CSS. I can replace a component. But I cannot rewrite every template file without breaking updates.

WordPress with free tools

My second friend’s blog runs on a free theme with a good reputation for accessibility. We have added a lot of CSS to it. So the question is not whether you can customise. You can.

The question is how far free, ready-made tools let you go.

A plugin gives you a finished solution in one click. But its code often breaks ARIA rules and basic semantics. Sometimes that trips an automated scanner. Sometimes it reaches a real user, which matters more. Either way you are choosing between a feature you need and markup you would never write yourself.

Her site scores close to 90 against WCAG 2.2. The last ten percent is where the real barriers live. Some of the fixes need JavaScript, and the free tools we have will not let us add it. Those stay on the list.

What I take from this

Accessibility is not a setting you switch on at the end. It comes from decisions made long before the content exists.

Paid does not mean accessible, and free does not mean bad. What matters is how much of the code you can reach.

And remember the dashboard. A site the owner cannot edit is not accessible either.