Page Contents
Who is this for?
The accessibility landscape has changed so much over 2025 and 2026, but the conditions we're in aren't totally new. Institutional support for diversity, equity, and inclusion has declined—and it includes accessibility. Whether you work somewhere that isn't supporting accessibility work like it used to, or a place that's underfunded it from the start, I get it because I've been where you are.
It's an awful feeling when you're not able to do work you're passionate about or told that you can't. You end up having to put out work you're not proud of. Maybe you've heard some of these things when trying to discuss accessibility at work:
- "We can't let perfect be the enemy of good."
- "Why didn't you mention this sooner? Stakeholders already approved."
- "You're the only person that talks about this. It rocks the boat."
These are dismissals. They're also quite direct about placing the "blame" or "fault" on whoever is being spoken to. These aren't the only dismissals used, but they're some of the most hurtful ones I've personally heard as a deaf, neurodivergent, and multiply disabled person that works in accessibility.
This repeated reminder of mismatched values is corrosive. It leads to burnout, and if you're someone that relies on accessibility, it can come to feeling physical hurt in your body at some point. If that's you, please hear this first: you're not alone and it's not in your head. It's a genuinely difficult situation to be in and sometimes circumstances actually make it impossible to be in.
This is just one way working in these environments can feel.
- They can also be career-limiting if accessibility is what you want to study and focus in the long term.
- There may not be anyone else to collaborate or think with if you get a small chance to do accessibility work.
- There's very little room to practice and gain confidence and experience, which would enable you to have at least some impact with the little time allowed.
What does the process look like?
We'll start with a free discovery call to talk about the challenges you're trying to navigate and how I might be able to support you on that journey with 1:1 accessibility-focused coaching.
Then we'll have ongoing sessions, usually 60 minutes at a weekly or every-other-week cadency. The number of sessions depends on things like what topic areas we cover, whether you have one or a few specific tasks or you have an educational or skill goal in mind, and the type of support you're looking for and how long.
If we have a program of sessions, we'll leverage a tool like a syllabus to keep us on track and measure progress. You'll leave each session with a clear list of readings, exercises, tools, or habits to try until the next session. Then we'll do a little reflection, see what did and didn't go as expected, and iterate as needed until the end of our program.
If we don't go with the program approach—and not all coaching needs it!—it's likely you have some very specific tasks or questions in front of you and one session will do the trick.
Planning example
You're exploring the idea of adding a video communication feature in your product and you're not sure which parts of accessibility standards are relevant.
Design example
You've been tasked with designing a filterable, sortable, and searchable data table with several column types and interactive elements. You have some experience with ensuring accessible keyboard and assistive technology interactions but aren't confident yet with this in complex widgets. You want to make sure you're meeting baseline requirements before presenting your mockup, wireframe, or prototype.
Development example
You're assigned to remediate an accessibility bug report that came from a screen reader user. The code related to the report is from a third-party component library and you're not sure if it's a problem in the library itself, how the library is being used, or how to fix and then verify the fix.
Testing example
You've learned the basics of testing with a screen reader, but you have minimal experience testing with other assistive technologies and you want to broaden your skillset.
Documentation example
You've began training internal teams on addressing accessibility queries and you're starting to receive increasingly complex and nuanced questions you haven't answered before. You want to make sure your answers are backed by research and data but your schedule is full and you need help finding the research and data.
What topic areas are available?
Each section lists a few ideas, but we wouldn't be limited to just these. There may also be overlap in groups depending on your team or company structure. If you're wondering about a particular idea please fill out the interest form!
Planning
- Defining accessibility goals and scope
- Incorporating accessibility work into schedules
- Engaging with experts and disabled users in user research
- Identifying supported assistive technology, browsers, operating systems
- Drafting user stories or personas with acceptance criteria
Design
- Creating accessible mockups, wireframes, and prototypes
- Designing complex or high density user interfaces
- Facilitating accessibility design reviews with stakeholders
- Documenting test results, broad feedback, and feasibility
- Incorporating accessibility results and feedback into designs
- Building a collaborative design-dev handoff process
Development
- Evaluating component libraries for potential use
- Building custom components and widgets
- Performing accessibility-focused code reviews
- Documenting code-level accessibility details
- Leveraging semantic HTML before ARIA
- Integrating accessibility tools during code writing
- Using automated accessibility tools in CI/CD pipelines
- Interpreting remediation guidance into your codebase
Testing
- Developing accessibility test plans and scripts
- Conducting automated accessibility testing
- Analyzing automated accessibility test results
- Conducting manual accessibility testing
- Testing with multiple assistive technologies
- Reporting issues and tracking remediation
- Verifying remediation fixes before release
Documentation
- Creating user-facing documentation about accessibility
- Ensuring product docs and support content conform
- Producing conformance reports, with tools such as a VPAT
- Writing and maintaining a library of test reports
- Creating public feedback channels for issue reporting
- Training internal teams for addressing accessibility queries