What happens when you experience the product with impaired vision?
Legislative Llama: making government information accessible beyond compliance.
The Challenge
The team wanted to improve accessibility compliance, but it wasn't clear where users were actually experiencing friction.
Rather than treating accessibility as a checklist exercise, I wanted to understand how the product felt when experienced through assistive technologies.
To do this, I conducted manual testing with VoiceOver on macOS, evaluating navigation structure, heading hierarchy, interactive controls, accessibility menu behavior, and content discoverability.
The Insight
During testing, I found that many of the most significant barriers weren't purely technical.
Important content was visually structured, but not programmatically structured.
Screen reader users often struggled to understand:
- Where they were
- What information mattered
- What action they should take next
Key Findings
- Missing structure creates invisible content
Several critical sections appeared well organized visually but lacked semantic heading hierarchy. Without headings, users couldn't navigate efficiently using standard screen reader shortcuts, making important information significantly harder to discover.
The lesson: visual organization and accessible organization are not the same thing.
- Accessibility problems often start with language
One issue involved emotional response options that VoiceOver announced as:
VoiceOver announced"Optimistic optimistic" · "Sad sad"The duplication occurred because both the visible text and the ARIA labels were being read aloud. The technical issue was simple, but the user impact was meaningful: interactions became confusing, repetitive, and cognitively taxing. I audited the component labeling and rewrote the accessible names and descriptions so information was communicated once and clearly.
- Content design is accessibility design
What surprised me was how often users struggled because interface language failed to communicate hierarchy, state, or actionability. I rewrote navigation labels, interface copy, and accessibility descriptions across more than 50 components, reducing ambiguity and improving discoverability throughout the experience.
Outcome
The project resulted in:
- A comprehensive accessibility audit
- WCAG 2.1 AA recommendations
- VoiceOver usability findings
- ARIA labeling improvements
- Accessibility requirements documentation
- A prioritized implementation roadmap
More importantly, the work shifted the team from accessibility as compliance to accessibility as comprehension.
What I Learned
Before this project, I viewed accessibility primarily as a technical challenge. But people build meaning through structure, language, and navigation. When those systems break down, information may technically exist, but it becomes difficult to find, interpret, and use.
The most valuable work was understanding how people make sense of information, and translating those insights into product decisions that made the experience easier to navigate and understand.