The person actually doing the work

Before focusing on accessibility, I spent two decades as a software engineer, including time in enterprise codebases where a change touches thousands of users and has to hold up under real review. That's the same rigor I bring to accessibility work: read the actual code, understand why it behaves the way it does, and fix the cause instead of patching the symptom.

I am a U.S.-based Section 508 Trusted Tester. Each engagement specifies the testing process, any additional WCAG criteria, and the environments used.

I find long pages hard to read. Most accessibility tutorials I tried were wordy, out of date, and badly designed. Dense text, tiny type, cluttered layouts. They were not comfortable for someone like me to get through.

So I built the thing I wanted to read. The guides here are short, plain, and laid out so they are easy on the eyes. If a page is hard to read, that is a bug, and I want to hear about it.

I am also shaping this content so AI can read it, learn from it, and apply it. The guides are plain and structured, and the site publishes an llms.txt so a coding assistant can find them. What is easy for me to read tends to be easy for a model to read too.

The same idea applies to the findings in a report. Each one is written like a backlog item: what is wrong, where, how to fix it, and how to check the fix. You can export them into your tracker, and an AI agent can pick one up and work on it. I am building toward more automation here, so the fix and the recheck need less back and forth.

Bigger isn't always better for this work. A single senior engineer who does the testing and the fixing means nothing gets lost in a handoff between a salesperson, a tester, and a developer who never talk to each other. You get one point of contact, start to finish, and a direct line back to whoever wrote the report.

The testing scope, communication, and findings stay with the person doing the work.

For teams bigger than one, the goal is to make accessibility something your organization does, not something I do to your site once a year. That starts at the requirements stage — accessibility criteria written down before design begins — and continues through code review and CI, so it's enforced as part of how you already build, not as a separate audit that arrives after the fact.