Recently, I was asked a question that really made me take a step back. “With all these AI tools, aren't they just to give users what you would write about anyways, so who are you writing for?”

Yes, AI can generate content faster than ever before. It can summarize, rephrase, and expand on our content. It can also write test cases, code snippets, documentation, and even write articles.

So why am I writing? Why am I spending time sitting here typing this out for the world to read when it may not even be read by a human and will just be another "piece of learning material" for AI.

The Human Element

I believe, firmly, that the accessibility content I write about is helping to teach the other part of AI that nobody is talking about. The human aspect. The person on the other side of the prompts, on the other side of the outcome from the content created.

I write because I still believe, stubbornly, that accessible development isn’t something you can fully automated. I know, I know says the guy who's been writing about automation for years.

Accessible development, when done correctly, is about intent. It’s about understanding the impact of what you build. It’s about caring enough to check, to question, to learn, and improve. Even if that caring is knowing that when you say "make me an accordion that has XYZ" adding in "make me an ACCESSIBLE accordion that has XYZ"

Knowledge is Still Power

The speed at which AI can help build out code is unbelievable! The scary part is how accurate it can be as well in building out content. However, there is still an aspect of knowledge needed to understand accessibility and know if there are features missing. Let me give an example.

You just built a modal component. The modal is your standard looking modal with a title, text content and a close button. As part of your development process, you use a prompt that says "make me test cases for this component"

AI will generate a test case for your modal, in whatever framework you choose. More than likely, you will get a whole suite of tests that will check that it opens, the background content is grayed out, and that the buttons work to open and close the modal.

The big question though, will it include accessibility checks by default? Validating focus management, keyboard focus trap, and ensuring all actions work with keyboard.

This is the human and education element with development. If they don’t know to include accessibility tests, the tools they use may not include them. If they don’t know how to evaluate the output, they won’t know what’s missing.

Bringing it Home

So who am I writing for?

The developer who wants to build accessible components but doesn’t know where to start. The tester who wants to understand what good focus management actually looks like. The teams who care about the content create, but need guidance and want to learn.

Writing and knowledge sharing is how we keep accessibility human, and accessibility has always been about people. It is people with real needs, real frustrations, real barriers, real experiences.

AI has changed the development game forever. It can help us build applications faster and more efficient than ever before.

So why do I still write? Writing is how we pass on the knowledge that AI can’t invent. It's how we teach the next person to ask better questions. Writing is how we keep accessibility grounded in real people, and that is my mission. Making developers give a damn about the impact of the work they build, and to care about the human on the other side of the screen.