Accessibility consulting and web development
I’m a blind developer, so I build and test with a screen reader. If something doesn’t work, I’m the first to know.
Hey, I’m Wes. VoiceOver and a keyboard aren’t testing tools I turn on for a project -- they’re how I use a computer. I help teams find the accessibility problems that actually matter and figure out how to fix them.
Where to start
If you’re not sure where to start, the portfolio’s probably the best place.
What people usually ask for
- Testing from someone who actually uses assistive tech
- Findings you can hand directly to a developer
- Clear writing, no jargon
For hiring managers
The portfolio's probably more useful than anything I'd say here.
It shows how I test, how I write up findings, and what I think matters.
What you'll find
- How I describe problems and why they matter
- Whether the findings make sense on their own
- How I prioritize when you can't fix everything at once
- How I explain assistive tech to people who don't use it
What I do
Most people show up here for one of these.
Pick whichever fits, or just reach out.
Accessibility consulting
I use your product with a screen reader and tell you what's broken.
You don't need a 50-page report full of severity labels. You need someone who can tell you what's wrong, why it matters, and how to fix it.
- Real usage, not checkbox auditing
- Websites, apps, SaaS, internal tools
- Working sessions if that's more useful than a report
Accessible web development
Sometimes it's easier to just rebuild the thing right.
I can fix what's there or start fresh. Either way, accessibility's baked in from the start.
- Rebuilds that fix things at the source
- New sites, accessible from the first line
Portfolio
Real work, not a sales pitch.
Case studies from real projects. Probably the best way to tell if I’m the right fit.
- Actual findings from actual testing
- How I prioritize and why
Audio work
The other thing I do.
Mixing, mastering, Pro Tools help. If you're a musician or producer, there's a whole page for it.
- Mixing and mastering
- Pro Tools workflow and sessions
Why this matters to me
I care about this because I live it.
It's personal
When an app isn't accessible, I can't use it. I don't have to imagine what that's like. So when I test your product, I'm not guessing.
I write for humans
If you have to Google something to understand my report, I didn't do a good enough job.
Two things, two pages
Accessibility and audio don't really overlap, but they're both what I do.
Getting started
You probably already know what's rough.
Starting small works better than trying to audit everything at once.
Tell me what's bugging you.
A checkout flow, an internal tool, a page that's getting complaints. You don't need a perfect brief.
I try to use it.
With a screen reader, the way someone who depends on one actually would.
You get something you can act on.
What's broken, what matters most, what to do about it. Maybe a working session if that's more useful than a doc.
How I work
I just try to be clear.
If your team can read what I wrote and know what to do next, that's the whole goal.
Who usually reaches out
- Teams that got a vague compliance report and want something they can actually use
- Hiring managers -- honestly, just go look at the portfolio
- Musicians and producers who need audio help
- People who want feedback from someone who uses assistive tech every day
Say hi
If you're not sure what you need, that's okay. Most people aren't when they first reach out.
Send me a link, a rough description, whatever you've got. We'll figure it out.