
Designing Accessible Digital Solutions in the Real World: Lessons Learned
About
Today the majority of product teams understand that accessibility is an essential characteristic of a digital product, not a nice set of low-priority user stories that can die in the backlog. What challenges does a product team face on the way to make an existing product accessible? How does it handle legal issues? I’m going to share my personal experiences and the insights I gained working on improving accessibility of digital products based in Europe and North America. I'll reveal practical tips and lessons learned from real-world projects, where accessibility played a pivotal role. Together, we'll explore how to foster an accessibility-first mindset within design teams and drive positive change in the digital landscape.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
Talk in brief
Accessibility work succeeds through pragmatic, continuous improvement rather than a single compliance project. Drawing on real product audits, the talk shows why seemingly simple fixes can reveal deeper component and organizational problems, why different auditors may recommend conflicting interaction patterns, and why teams need internal allies and accessible design-system foundations. The practical message is to understand the product’s pain points, address high-impact barriers in small steps, and treat standards, interpretations, and technology as an evolving design constraint.
Key takeaways
- 01
Begin with a real customer barrier
Concrete failures in forms and service journeys make accessibility work understandable and easier to prioritize than abstract ambition.
Watch from 0:23 - 02
Use audits to create an actionable queue
An external or internal audit can expose specific issues, but the team still needs to choose a practical sequence for fixing them.
Watch from 1:35 - 03
Build a coalition around accessibility
Progress is fragile when one person owns the concern; designers need engineers, product partners, and leaders who can sustain it.
Watch from 2:52 - 04
Expect legitimate implementation disagreement
Different audits can recommend different patterns, so teams must evaluate user behavior, semantics, context, and technical constraints.
Watch from 5:16 - 05
Fix foundations before chasing perfection
Accessible components, contrast, labels, and basic interaction behavior create more value than an unrealistic promise to solve everything at once.
Watch from 8:01
Video chapters
- 0:23A product promise meets an accessibility gap
A real service scenario exposes the difference between inclusive intent and usable delivery.
- 1:35Starting with the first audit issue
The team turns a broad accessibility goal into a concrete repair sequence.
- 2:52Pain points, fixes, and internal allies
Sustainable improvement requires product knowledge, solution knowledge, and shared ownership.
- 4:02When semantics reshape a component
Audit feedback demonstrates why appearance and behavior must match the element’s actual role.
- 5:16Conflicting recommendations from auditors
Two valid reviews can point toward different solutions for the same interface.
- 6:31Accessibility as continuing exploration
Changing technology and interpretation keep the work active after individual fixes ship.
- 8:01Pragmatic advice for lasting progress
The conclusion prioritizes basic standards, design-system repairs, and achievable steps.
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
Inclusive intent must survive the actual form
A service may exist to help disadvantaged people while its interface still blocks them. Looking at a concrete journey—such as requesting essential support—makes that contradiction visible. Accessibility begins when a team tests whether the intended beneficiary can complete the real task, not when the product’s mission statement uses inclusive language.
Watch from 0:23An audit turns ambition into specific work
The first commercial audit produced a ranked set of issues in a form-heavy product. Choosing one item from that list created momentum and taught the team what remediation involved. The lesson was not to ignore the rest, but to replace an overwhelming goal with a visible queue of barriers that could be understood, fixed, and checked.
Watch from 1:35One advocate cannot carry the system
Knowing the product’s pain points and possible fixes is necessary, yet progress stalls if accessibility belongs to a single interested designer. Teams need allies who can change components, prioritize defects, test behavior, and defend the work during delivery pressure. Shared capability matters more than isolated expertise.
Watch from 2:52Audit findings still require design judgment
Different auditors may classify the same control differently and each can provide a defensible rationale. A team cannot resolve that tension by copying a report mechanically. It must examine semantics, expected behavior, context, and user impact, then document a decision that can be applied consistently across the product.
Watch from 5:16Accessibility is a maintained product quality
The practical path is to meet foundational requirements, repair recurring design-system problems, and improve the product in manageable steps. Standards, technologies, and interpretations evolve, so accessibility cannot be completed once and forgotten. It needs ownership, monitoring, and continued investment like security or performance.
Watch from 8:01


