There are times during everyone’s career when what you do on a daily basis no longer feeds your soul.  It’s been like that for me. I spend my working hours working around and with developers, trying to help them understand how to incorporate the vagaries of WCAG into the codebase in front of them. I feel like I’m fighting an uphill battle. Accessibility isn’t the newest shiny object most developers are interested in; it’s foundational, boring even, and who wants to memorize a whole bunch of guidelines anyway?

I’ve learned that many developers, regardless of their educational background, are unaware of the semantics and structure of HTML and how that structure is the first step toward accessible products.

I’ve seen code where developers have hard-coded “name” in the alt attribute of an image tag or place test identifying code into invisible labels, which, yes, get read out by screen readers. I’ve seen sites requiring a sighted person to tab through tens of items before reaching the main menu because “we have skip blocks for screen readers.”

Developers and designers are smart people, but I’ve found many of them need to be made aware of all the people their work will eventually reach. To understand how our work connects to the real world instead of simply the vaguely identified user or customer.

I spend a lot of my time trying to convince people that accessibility is achievable. I try to help them understand that accessibility is multi-dimensional and exists along a spectrum. To simultaneously consider how a component will work for anyone, regardless of how they access the web. To consider not only how they, as a developer, uses the web instinctively but others might. How might someone who can see but only uses a keyboard have needs possibly differing from those who can access a screen reader? It could be someone with a long-term issue, like Parkinson’s, or simply someone who might have broken their dominant arm and can’t use a mouse or touchpad as easily for a specific amount of time.

Over the years of my career, I’ve learned that accessibility belongs in all aspects of software development and that ignorance at any level will eventually catch up. But it can’t only be on the backs of your front-end developers. Simply adding “must be accessible” to acceptance criteria doesn’t help if the people doing the work don’t have a solid grounding in what “accessible” means.

Whether a company wants to sell a solution to the Federal government or expects developers to learn on their own with little to no support except the vague acceptance criteria: “Conforms to Accessibility Standards,” they don’t stand a chance of making sure their products are really able to be used by everyone unless accessibility becomes a core principle.

Since I’m just starting to look for a new contract, I thought now might be the perfect time to start blogging.  I know, I know; it’s just another ubiquitous blog. But I thought I might give it a slight twist, which is where the title of this piece comes from.

A little over a year ago, I partnered with a friend who wanted to post her writing on a website. The stories she gave me to read were pretty good, and there were plenty of references between them; for all, they were just snippets in what she assures me is a vast timeline.  We hashed out an agreement. She wanted WordPress because she was familiar with the backend.  Once I realized I could satisfy her needs, I agreed to it.

I’ve never been a PHP developer. I started with ColdFusion and stayed there until I jumped into React development. But I found a way to make WordPress work the way I needed it to via a really nice plugin called Pods Framework. I created custom post types, and we began plotting out relationships between them. Slowly, we figured out what we needed, and I was able to retrieve all the connected data.

The front end was different, though. I was constantly fighting CSS and accessibility issues. I missed the ecosystem I was used to. So once we got the site able to host her writings, we began plotting to move her to a headless WordPress installation, giving her the familiar backend and allowing me to architect the entire front end.

I’ll be the first to admit I don’t have all the answers, especially around deploying code to production, but I’m pretty good at research, and I figure by the time we’re ready to launch, I’ll have a better idea.

Right now though, I’m having a ball. Instead of trying to fix someone else’s misconceptions and mistakes, I’m able to think things through and make (hopefully) better decisions for the Nudge Stories.

The base development environment is running a backend WordPress server using plugins to handle Custom post types and graphQL. The front end is Next/Js with React 19 and a set of primitive components supported by Adobe, react-aria-components and CSS modules. I’m making sure I have a firm grasp of the basics of the newer versions of everything, especially all the juicy new selectors and queries that are a part of CSS. It’s a lot of fun and my partner says they’ve never seen me as enthused about development as I’ve been the last year.

Since we started, I’ve got a mono repo going and have made sure both ends can hear each other. I’m working on facading the components I need and beginning the process of styling them. I’ve got reasons for using the stack I’ve chosen and I’ll be discussing them in future blog posts.

Quick Note, I am not allowing comments on these posts. If you want to comment, you can do so at the following post on Blue Sky. Thanks for understanding.