My First Accessibility Audit: Lessons from a Gym Website
Julia Undeutsch
My First Accessibility Audit: Lessons from a Gym Website
“My first accessibility audit wasn’t perfect — but it taught me more about structure, clarity, and doing things properly than any checklist ever could.”
I still remember my first accessibility audit — not because it was perfect (it wasn’t),
but because it completely changed how I approach quality and structure in web development.
It started at my local gym.
Yes, the gym.
The same place where I try to keep my body healthy ended up being where I learned how to make websites healthier too.
Accessibility starts where people are
Our gym had a surprisingly inclusive vibe: members with low vision or blindness trained there regularly, staff were adaptive, and the community cared about making everyone feel welcome.
But their website didn’t reflect that.
So when they asked if I could “check their website for accessibility,” I thought: Sure, how hard can that be?
Spoiler: it’s harder — and way more interesting — than it looks.
Building my first audit
As a developer, I was used to fixing issues like color contrast or missing focus states on the fly.
But writing a structured accessibility audit meant something different:
it wasn’t just about fixing things — it was about explaining them.
I created my first audit in Google Docs. It seemed easy to share and structure.
I divided it into four parts:
- General information
- Automatic testing results
- Manual testing findings
- Accessibility statement
It looked clean and professional.
Until I realized… I never checked whether my audit document itself was accessible. 🤦♀️
Lesson #1: The tool you use matters
When I created my first audit, I used Google Docs. It worked fine, but I never verified its accessibility.
That doesn’t mean you have to test every document, slide, or PDF you create.
If you’re delivering audits professionally, clarify up front whether accessible documentation is included in the scope.
Some clients require it, some don’t.
What matters is setting clear expectations and keeping your output consistent.
Lesson #2: Structure is everything
When you start explaining accessibility findings to non-technical people, structure is your best friend.
I organized the audit with clear headings, a table of contents, linked sections, and a glossary.
It wasn’t about empathy — it was about maintaining clarity and precision so the document could be used efficiently by whoever needed it.
Lesson #3: Don’t rely on emojis for accessibility
At one point I got creative: I added little emoji icons to represent disabilities
👁️ for low vision, 🎧 for hearing, 🧠 for cognitive, etc.
It looked nice… until I learned that many screen readers either skip emojis or read them as random Unicode gibberish.
Now I use clear labels and descriptive icons instead.
Lesson #4: Beyond compliance = better quality
The gym wasn’t legally required to meet WCAG 2.2 AA.
But I decided to review AAA criteria as well, simply because higher accessibility standards often align with better usability and cleaner code.
Doing work to spec is the baseline; exceeding it improves maintainability and long-term quality.
Lesson #5: Testing is a team process
Automatic tools catch a lot, but not everything.
Real-world testing exposes edge cases you can’t predict.
Explaining accessibility issues to others is less about emotion and more about precision in communication — translating technical findings into actionable tickets.
Lesson #6: Explain the “why,” not just the “what”
Writing “fix color contrast” is easy.
Explaining why matters for the codebase or QA — e.g., “ensures consistency with WCAG 1.4.3 and prevents future regressions” — gives the issue context and helps prevent repeat mistakes.
Lesson #7: Accessibility is continuous learning
That first audit was messy, imperfect, and full of rookie mistakes.
But it became the foundation of how I now approach accessibility:
as a quality discipline built on repeatable processes, clear documentation, and continuous refinement.
The bigger picture
That one gym website didn’t change the world.
But it improved my workflow.
It showed me that accessibility isn’t something you bolt on for “inclusion” — it’s what happens when you write good, standards-compliant code and documentation.
Do your job well, test thoroughly, and accessibility follows.
Key takeaways
- Accessibility is part of overall code and product quality
- Define scope and deliverables clearly (including document accessibility)
- Structure and clarity matter as much as code
- Higher standards often equal better maintainability
- Explain context to prevent repeated issues
Further reading
This article was originally published at dev.to/yuridevat