Blind-led accessibility work, explained like a person
Accessibility feedback rooted in lived experience, careful attention, and language that still sounds human.
I’m Wes. I test websites, apps, and digital workflows the way screen reader and keyboard users actually move through them, then I try to name what is breaking in a way that feels honest, specific, and useful. If you are hiring, the portfolio will give you a real sense of how I think. If you need consulting, that path is here too.
Fastest route
If you need accessibility help, start with consulting. If you want to understand how I think and write, go to the portfolio. If you are here for music, that part has its own space.
Why teams reach out
- Blind-led accessibility feedback grounded in real screen reader use and lived experience
- Clear findings and fix guidance without the usual distancing language
- Communication that stays direct without losing warmth
For hiring managers
If you are evaluating me for a role, skip the sales path and go straight to the work.
The portfolio is structured to show how I notice user impact, document blockers, and write findings that stay useful to product and engineering teams without losing the human part. It is there to answer the question a resume usually cannot: what does this work actually look and sound like in practice?
What you can evaluate there
- How I describe blockers and user impact
- Whether the findings are specific enough to implement
- How I balance assistive tech detail with plain language
- The level of judgment behind severity and prioritization
Choose the lane
Most people land here needing one honest next step, not a polished performance.
Pick the lane that fits why you came here. The rest of the page should make that feel clearer, not more complicated.
Accessibility consulting
Find where the product starts quietly pushing people out, then focus on the fixes that would actually help.
Audits, testing, fix guidance, and working sessions shaped by lived blind experience and hands-on evaluation of real user flows.
- Screen reader and keyboard testing for real user flows
- Remediation guidance your team can act on
- Support for websites, apps, SaaS, and internal tools
Accessibility portfolio
See how I test, write findings, and make sense of accessibility problems in situations that feel real.
This is for hiring managers, collaborators, or anyone who wants something more concrete than a claim to care about accessibility.
- Case-study style reviews and real findings
- Hands-on testing methods and assistive technology context
- A cleaner path for employment conversations
Audio work
Mixing, mastering, and Pro Tools help for artists who want the work to feel finished, not just technically done.
The audio side has its own page, its own tone, and a cleaner path for artists and producers who do not need to sort through accessibility language first.
- Mixing and mastering for release-ready work
- Workflow help inside real sessions
- Separate messaging for artists and producers
What makes the work different
The value is not just that issues get found. It is that the findings carry a real user point of view and still leave the next step clear.
Lived perspective
Blind-led feedback changes what gets noticed, how friction gets described, and what the team understands about actual impact.
Writing teams can use
Findings are only useful if product, design, and engineering can act on them. The language matters because people need to understand the problem clearly before they move on it.
No split identity problem
The site keeps accessibility as the lead story while still giving the audio work a real home instead of hiding it or letting it blur everything together.
How work tends to start
A small amount of honest signal early is usually worth more than a giant accessibility document later.
Most engagements start with one flow, one page set, or one area the team already knows feels shaky.
Start with the part that already feels risky.
You do not need a perfect brief. A broken signup flow, checkout path, dashboard pattern, or internal workflow is enough to begin.
Test what a real user would actually try to do.
The point is not collecting decorative issues. The point is seeing where a task falls apart for screen reader and keyboard users.
Leave with guidance your team can use right away.
That can mean findings, prioritization, remediation direction, or a working session to help the right fix happen faster.
How I work
Direct feedback, practical next steps, and no fake agency voice.
I care about making the work feel understandable as well as usable. That means clear findings, honest prioritization, and language people can act on without having to translate it first.
Best fit
- Teams that want blind-led accessibility input and direct remediation guidance
- Hiring managers who need more than a resume bullet list to evaluate accessibility work
- Artists and producers who want the audio lane without accessibility messaging getting in the way
- People who prefer plain language over consultant theater
Easy first step
If you already know what you need, reach out. If you are still circling the problem, that is fine too.
Send a link, a rough description, or even just the thing you keep running into. I can help sort out the next step from there.