Establishing accessibility in everyday agency work
07/2026
12 minutes reading time
Summary
We’re featured in t3n!
Issue 84 highlights just how practical and effective our approach to accessibility is: Under the title "Inclusion Included," our colleague Victoria shares our proven process roadmap as a best practice for the entire industry.
Accessibility often starts with overwhelm — and that’s completely okay
Web accessibility is not a new topic. It comes up more and more often at conferences, in articles, and in client conversations. And yet, implementing it in day-to-day agency work is something that tends to get postponed — not because of a lack of willingness, but because of uncertainty. Integrating accessibility meaningfully into workflows feels like a big task. Complex. Vague. And somehow never quite finished.
That’s exactly how it felt for us, too. We knew we needed to engage with the topic more deeply. Clients increasingly asked for accessible or accessibility-minded solutions, and internally at format-D, our ethical goal was clear: create products usable by as many people as possible, regardless of physical, sensory, or cognitive abilities. At the same time, only a few colleagues had deep expertise in the subject. What we lacked was a shared understanding — and a workflow that worked for everyone.
Why accessibility feels overwhelming at first
The biggest challenge wasn’t motivation — it was uncertainty:
What does accessibility actually mean in practice?
How “accessible” can a website realistically be?
What applies to small company websites, and what is legally relevant?
How do we advise clients without providing legal advice?
And very practically: How long does it all take?
Anyone who has tried reading the WCAG front to back knows how demanding the material is. The Web Content Accessibility Guidelines are the international standard for accessibility on the web: extensive, highly technical, and full of cross-references. It quickly becomes clear why accessibility isn’t a fixed state but a continuous process — and why, at first, it feels like aiming at a moving target.
At the same time, many of our clients faced similar questions:
What does accessibility actually mean for our website? What legal requirements apply? How can we act responsibly without overshooting or falling short? That insecurity is entirely understandable — companies operate between user needs, budgets, and legal gray areas.
We initially tried to make sense of everything by attending conferences, online seminars, and reading articles. But the more input we collected, the clearer it became: accessibility cannot simply be “adopted.” We needed to define for ourselves how it fits into our workflows, roles, and processes — and what is practical and sustainable for us.
As long as neither we nor our clients could clearly assess what was necessary and meaningful, the topic remained hard to grasp. And so accessibility moved with us from project to project — accompanied by the feeling: “We really should address this… but when? And how?”
Screenshot from the alignment of craft leads with accessibility standards
Working together on accessible solutions in Deep Dive
From individual knowledge to shared responsibility
In early 2025, our Craft Leads decided it was time to take responsibility for creating clarity.
In our shared-leadership model, Craft Leads ensure that each unit can deliver consistently high-quality work. They develop shared ways of working, define processes, and continuously refine them. From this role, it became clear that we needed structures to help the whole team understand the standards we set — and ensure accessibility no longer depended on the initiative of a few.
In short, we wanted accessibility to become part of our routine.
Our goal was not perfection, but:
Why accessibility matters — for users, clients, and the product.
Every role should understand what they can contribute.
Accessibility should fit naturally into existing workflows.
Without overwhelming them or slipping into legal consulting.
How accessibility became part of our processes
When we began integrating accessibility systematically into our projects, we didn’t want to create an additional “special program.” Accessibility shouldn’t only show up when someone remembers it — it should be woven into decisions, alignment, and everyday routines.
At the same time, our products must also be built with accessibility in mind — in design, development, and content. Only then does accessibility stop being a last-minute add-on and instead become a natural part of components, layouts, and content from the very beginning.
To achieve this, we developed several building blocks that reinforce each other and embed accessibility on both an organizational and a craft level.
1. Asking the right questions at the right time
Many clients come to us wanting “accessibility,” without knowing what that means for their specific case. That’s why we don’t rely on a single accessibility workshop. Instead, we use a question catalog throughout the project.
In strategy workshops, when discussing target groups, user journeys, or strategic goals, we add questions like:
“Are there customer groups for whom accessibility would be a competitive advantage?”
“Are there internal policies or CSR goals that relate to accessibility?”
These questions don’t appear in one big block but exactly when they are relevant. That creates a real conversation — not an interview script. Clients are guided step by step without being overwhelmed.
2. Documentation as a shared foundation
We created an accessibility documentation template that captures all requirements, target group needs, responsibilities, and decisions. It’s filled in at project start and updated throughout the process.
This documentation serves as a shared reference — internally and with clients — ensuring accessibility remains visible from the beginning instead of emerging as a last-minute concern before launch.
3. An offering structure that creates clarity
One of the biggest challenges is understanding how much accessibility a project actually needs. To make these decisions clearer, we structured our offering into modules that build on each other and represent different levels of depth.
The modules range from a technical foundation to accessible content workflows and optional certification support. This helps clients choose the scope that fits their project — without needing to navigate complex guidelines. At the same time, it gives us clarity on which measures apply and how they affect effort and responsibilities.
The result: a shared language between design, development, and clients — making a complex topic more predictable, transparent, and manageable.
4. Making accessibility visible in tickets and everyday decisions
Accessibility can’t be “tested in” at the end — it emerges while features are designed, built, and structured. That’s why we integrated it directly into our ticket workflow.
Every feature — from navigation to an accordion component — receives clear acceptance criteria that define the requirements and link them to the appropriate module and WCAG guideline.
An accordion, for example, won’t be marked “accessible” by default. Instead, it has explicit criteria such as: keyboard operability, visible focus states, correct ARIA attributes or usability with enlarged text.
This structure has two key benefits:
It provides the team with a clear foundation for design, development, and testing.
It gives clients a transparent reference of what was implemented — documented and verifiable.
Accessibility is no longer an abstract aspiration — it becomes part of every step in the creation process.
5. Distributing knowledge instead of centralizing it
For accessibility to work in everyday project life, we need two things:
people who drive the topic initially, and a team that carries it together.
At first, our Craft Leads take ownership: they develop training, define standards, and ensure accessibility is embedded into our processes — not as a separate function, but as a catalyst that spreads knowledge throughout the company.
Different units deepen different aspects:
The UX/UI unit focuses on contrast, typography, structure, and interaction patterns. The development unit dives into semantics, keyboard operability, focus management, and robust components.
Editorial training covers how to create and maintain accessible content over time.
These focuses are not isolated responsibilities. They ensure that all units contribute and together cover the full spectrum of accessibility. Responsibility starts with a few but is intentionally distributed across the team — with shared goals and shared understanding.
"A major accelerant in our process has been AI tools. They helped us make complex WCAG formulations easier to understand, generate examples, and structure criteria clearly. This allowed us to build shared understanding much faster — and made accessibility more tangible than specialist literature alone ever could."
Where we stand today
Even though we now handle the topic with more confidence, we still consider ourselves at the beginning of a long-term process. Accessibility isn’t something you implement once and check off. Every project brings new requirements — and new opportunities to learn.
What has changed is our foundation: we now share a clear understanding of what accessibility means for our work. We have a process that provides orientation while remaining flexible enough to evolve. And most importantly, our mindset has shifted: accessibility is no longer an additional step, but a quality criterion we consider from the very beginning.
Along the way, we learned that accessibility rarely fails because of missing knowledge — it fails because of missing routine. It takes discipline to consider it in every step, not just at the end. Perfection isn’t the goal. What matters is staying engaged with the process and learning with every project.
Of course, this means extra effort in the beginning: question catalogs, modules, documentation, acceptance criteria — all of it initially looks like a lot of additional work. And yes, it is. But with every project, it becomes more natural and easier to integrate.
That’s why we want to encourage other teams to simply start. Accessibility may seem big and overwhelming at first, but it becomes tangible as soon as you take the first steps. No one needs to get everything right immediately. What matters is choosing not to postpone it any longer — and being willing to learn and grow together.
In addition to exciting insights into Neos 9, inspiring exchanges with the community and a practical workshop, we were also able to help create a small piece of the atmosphere with our stand and official conference shirts.
We report below on what we experienced, learned and contributed.
