The Broken Chain

In 2009, I wrote a book on web accessibility. It was the first one published in Brazil on the subject, at least as far as I know. At the time, I was finishing my undergraduate studies, and the topic landed on me almost by accident: a chapter of my final thesis on web technologies had caught my research advisor’s attention. We decided to turn it into something bigger.

I remember the meeting that started it all. We were at the office of the director of Edufal, the publishing house of the Federal University of Alagoas, to talk about a possible project around web standards. She mentioned, almost in passing, an email she’d received a few days earlier. A blind reader was complaining that he couldn’t access the website presenting the publisher’s new braille book collection. He couldn’t even read the titles of the books meant for him.

I didn’t need to hear anything more. I left that meeting with an agreement to write the book, and a concrete project to make that site accessible.

Twenty years later, I reopened that book. Not to reread it this time: to rewrite it.

The decision to start over

The initial idea was modest: update a few references, bring in WCAG 2.2, add some more recent design patterns. A revision, not a rewrite. But rereading the first chapters, I realized the problem wasn’t how outdated the information was. It was the conceptual framework itself.

In 2009, web accessibility was presented, in my book as in most resources of the time, as a list of recommendations to follow. A set of technical criteria to check off to be “compliant.” The implicit question was: how do you make a website accessible? The deeper question, why are so many websites still not accessible, went unanswered.

So I started over. Not an update. A complete rewrite, in French this time, as a way of giving back what I learned in Québec. And going back to the sources, I found something uncomfortable.

The numbers that don’t move

Every year since 2019, the organization WebAIM has published the WebAIM Million: an automated accessibility analysis of the million most-visited home pages in the world. It’s one of the most reliable barometers in the field.

In 2019, 97.8% of pages had detectable accessibility errors.

In 2026, that number is 95.9%. With an average of 56.1 errors per page, up 10.1% from the previous year.

Seven years of reports. A 2-percentage-point improvement. And an increase in the average number of errors per page.

This isn’t a technical failure. The tools exist. The guidelines are public, free, well documented. The six error categories that account for 96% of all detected failures have been the same for seven consecutive years: missing alt text, insufficient contrast, missing form labels, links without descriptive text. Elementary problems. Known problems.

So why?

What I understood looking for the answer

Digging into the recent literature, I found a figure that stopped me cold: 62% of French developers are unaware of accessibility standards. Not the technical details: the standards themselves.

And even among those who do know them, accessibility is treated as an end-of-project check. An audit done after the fact. A box to tick before launch. This approach has a name in the industry: bolt-on accessibility, accessibility screwed on afterward, like an accessory added to a finished product.

That’s precisely what my first book encouraged, without saying so explicitly. By presenting accessibility as a list of criteria to validate, I was unknowingly reproducing the very framework that keeps the problem in place.

So the question isn’t: how do you make a website accessible? The question is: why do we keep building inaccessible websites despite fifteen years of legislation, tools, and guidelines?

A broken chain, not a coding error

What struck me most in picking this subject back up is that inaccessibility is almost never the result of an isolated mistake. It’s the result of a break in a chain.

The Web works like an ecosystem of interdependent components: the people creating content, the tools they use, the browsers that interpret the code, and the assistive technologies that render it to the user. When one link in that chain gives way, the whole experience collapses, even if every other link is solid.

A developer can produce a perfectly captioned video. If the video player embedded on the site doesn’t offer a keyboard-accessible button to turn on those captions, the effort is wasted. A writer can structure their content with an impeccable heading hierarchy. If their CMS automatically generates code that overrides that structure, the work disappears.

Inaccessibility, in the vast majority of cases, isn’t an oversight. It’s a predictable consequence of a design that didn’t build accessibility in from the start.

What this book is trying to do differently

The new edition I’m writing starts from that observation. It doesn’t offer a list of criteria to meet. It offers an engineering approach: design patterns, methods, and ways of thinking that let you build accessibility into the design process, not bolt it on after.

WCAG 2.2 has its place here, not as a bureaucratic checklist, but as a technical foundation for understanding why certain design decisions exclude users, and how to fix that structurally.

The book is for developers, designers, content creators, project managers, and anyone who publishes something on the Web and wants to understand who their content is actually reaching.

I’ll be documenting this writing process here as it goes: the research, the doubts, the editorial decisions, the surprises.

You’ve already read the first surprise: twenty years later, the problem has barely moved. But the reasons have changed. And that’s where it gets interesting.