Justyna Weronika Łabądź — Researcher and content writer at Dodonut
Storytelling with code for better accessibility (and SEO)
September 4, 2023
15:10
A11y
🇬🇧 English
A11y
Digital Accessibility from the Ground Up: Integrating Design Principles into Organizational Processes
About
In the current digital environment, it is essential for organizations to prioritize accessibility to promote inclusivity and ensure equal access to information and services for all users. To achieve this, organizations need to embed inclusive design principles into their core processes from the very beginning. Inclusive design principles will take center stage, focusing on how organizations can integrate them into various stages of the digital development lifecycle. From requirements gathering and design to development and testing, the conference will showcase best practices, tools, and methodologies that support the integration of accessibility into each phase. Participants will learn practical techniques to ensure accessibility is considered at every step, promoting inclusive digital experiences from the ground up. We will explore the synergies between WCAG 3.0 and the iterative design process, unearthing new possibilities for co-creation, collaboration, and innovation.
Watch the full talk
Watch this WaysConf session, then continue with related talks or explore the current programme.
From the recording
Talk in brief
A process-level guide to building digital accessibility into an organization from the beginning. Accessibility is framed as equal access, a better experience for many customers, a larger potential market, social responsibility, and an increasingly important legal obligation. The talk moves upstream from code to research with disabled participants, measurable impact maps, accessible user stories, design-system documentation, Figma annotations, training, and prioritized audits. Developers cannot repair every barrier at the end because many WCAG decisions originate in content, design, and product planning. Sustainable progress comes from shared ownership, treating accessibility defects like other product defects, and testing uncertain choices with the people affected.
Key takeaways
- 01
Start accessibility before implementation begins
Research, requirements, content, interaction, and design-system decisions create many barriers long before developers receive a specification.
Watch from 5:24 - 02
Include disabled people in product research
Direct participation reveals needs and contexts that teams cannot reliably infer from standards or internal experience alone.
Watch from 5:48 - 03
Translate accessibility into measurable requirements
Impact maps and user stories connect business intent with concrete behaviors such as complete keyboard operation and logical focus order.
Watch from 8:20 - 04
Document behavior inside the design system
Keyboard controls, landmarks, heading structure, and alternative text need explicit guidance shared by design, content, and engineering.
Watch from 14:05 - 05
Prioritize accessibility defects as product risk
Audits should describe evidence and remedies, while teams rank issues by impact and address them alongside other quality problems.
Watch from 17:27
Read edited transcript highlights
These concise notes were edited from automatic captions and checked against the talk structure. They are not a verbatim transcript.
Accessibility cannot be attached to a finished building
Organizations often expect one knowledgeable developer to add headings, alternative text, and keyboard support near release. That resembles adding an accessible entrance after the structure is complete: the visible patch cannot correct every foundational choice. Equal access begins when teams decide whom to research, what success means, how content is organized, and which interaction patterns the product will use.
Watch from 1:30Standards do not replace conversations with affected people
WCAG supplies important requirements, but a team still needs to understand how blind, deaf, mobility-impaired, cognitively diverse, and older customers experience the service in context. Researchers, designers, writers, product managers, and engineers should all encounter that evidence. Inclusion becomes more accurate when it is informed by participation rather than interpreted only through a checklist.
Watch from 5:48A broad goal becomes useful through an accessible user story
An impact map can connect an organizational outcome with a particular audience and the change that audience needs. The resulting story might require a travel group to be created using only a keyboard, which in turn raises explicit questions about focus order and control behavior. This translation gives accessibility a place in planning and acceptance criteria instead of leaving it as a vague aspiration.
Watch from 8:20Design documentation carries behavior across disciplines
A component library should explain which keys activate a control and how focus leaves a modal, not merely display colors and spacing. Figma annotations can define landmarks, heading hierarchy, and image intent before code exists. Writers, marketers, designers, and engineers each own part of that structure, so the documentation must support collaboration rather than assuming accessibility belongs to one specialist.
Watch from 14:05Audits create progress when they guide prioritization
A useful audit identifies the affected location, describes the barrier, and recommends a remedy that fits the product’s implementation. Teams may not fix every issue at once, so impact and effort should inform sequencing. Accessibility defects should then enter the same quality process as other failures; postponing them indefinitely because they affect a particular group simply preserves unequal access.
Watch from 17:27
Explore WaysConf 2026
