If you just winced, same. Trust me, I've workshopped the premise. "Sighted man with working hands has thoughts about disability" is not, on its face, a pitch that screams subscribe immediately. So let me get the throat-clearing out of the way: this blog isn't going to explain disability to disabled people. It's not a redemption arc. I'm not here to be inspiring. I'm a Test Manager at an accessibility company who spends his days running WCAG audits, and I've learned a frankly embarrassing amount from the disabled colleagues and testers I work with, and I'd like a place to write some of it down.
That's the whole pitch.
A little context, because it matters for what kind of voice you're getting here. I am 38. I spent most of my adult life as a bartender. At 31, I went back to school, and six years later I walked out of Oregon State University – Cascades with a CS degree, Summa Cum Laude, and the distinct feeling that I had no idea what I was doing (Go Beavs!). I am, by any reasonable measure, new to this. I do not have a decade of war stories. What I have is a very fresh memory of being someone who didn't know what a screen reader was, and a job that has rapidly disabused me of every assumption I brought into it.
Here's the kind of thing I mean. First week on the job, I'm in a meeting, mostly listening, because I have nothing useful to add yet. One of our most senior screen reader testers is explaining how painful it is to inspect code in browser dev tools. Dev tools assume you can see a nested tree of elements and click around in it. If you're blind, you're doing several layers of extra work to get to information a sighted developer gets in two clicks. I had spent four years in school learning to live in dev tools. I had inspected approximately one million elements by graduation. It had not once occurred to me that the tool every web developer is handed on day one is borderline unusable for a meaningful chunk of the people who'd want to use it.
While this tester was still talking, I noticed something else. The team kept referencing a bookmarklet called ANDI. I had never heard of ANDI. I had never heard of bookmarklets. I had a whole CS degree and I did not know that the bookmarks bar was a place you could put little programs. So I'm sitting there having two realizations stacked on top of each other: one, the standard developer toolchain has a giant blind spot, and two, there's apparently this whole category of tiny tools I missed entirely. And I thought, well, could a bookmarklet help with the dev tools problem?
I didn't say anything in the meeting. I just opened a tab and spent maybe an hour writing a first pass: a bookmarklet that grabs the HTML of whatever element is currently focused and dumps it to your clipboard for you to paste wherever. Tiny tool. Crude. But it worked. I sent it over, and the tester took it from there. She used AI to extend it, shape it to her actual workflow, push it well past what I'd built. She told me later she'd never thought of using a bookmarklet to assist in her testing, which was wild to me, because she was the reason I knew bookmarklets existed at all. We had each been missing a piece the other one had.
That's the kind of thing I want to write about. Not "I helped a blind colleague," because honestly the tester did most of the work and would've gotten there without me. More: two people from very different starting points, sitting in a meeting, accidentally handing each other tools. That's most of what this job is, in my limited experience so far.
Or take email. I used to write emails like many of you are probably used to. Sometimes long subject lines, three paragraphs of context, a polite sign-off. Then I learned about EOM, which stands for End Of Message. If your entire email fits in the subject line, you put EOM at the end and the recipient never has to open it. "Standup moved to 2pm Thursday EOM." Done. They read it in their notification preview and move on with their life.
This is just good practice for anyone. It's a small kindness to every coworker with a full inbox. But it's a significant kindness to someone using a screen reader, for whom opening an email to find out it contained no information you didn't already know costs real time and real cognitive load. A disabled colleague mentioned EOM in passing one day and I felt like I'd been handed a cheat code I should've gotten on day one of any office job, ever.
So that's what this blog is. Small things. Practical things. Things I'm learning the hard way or, more often, the easy way, by working alongside people who already know. I'll write about tools I've built, mistakes I've made, WCAG criteria that turn out to be more interesting than they sound, and the occasional moment of sitting in a meeting realizing I've been doing something wrong for as long as I've been doing it.
A few things this blog won't be.
It won't be me speaking for disabled people. I don't have standing to do that and I'd do it badly. When I'm passing along something I learned from someone, I'll say so.
It won't be feel-good content about how accessibility "helps everyone, really!" Even when that's true, leading with it tends to quietly recenter non-disabled users, and I'd like to not do that.
It won't be a credentialing exercise. I am, as established, a former bartender who learned to code in his thirties. I will get things wrong on this blog and I'd genuinely rather hear about it than not.
Thanks for being here.