Accessibility-Driven Development turns WCAG into a discipline. With the EU Accessibility Act as the deadline, ADD is the next discipline to drive quality.
Maybe you know the acronyms: TDD, BDD or DDD. If not, go on Reddit and you will find enough debates to learn it keeps our industry busy.
Each acronym shifted how we think and how we build software. Now, with new accessibility laws setting a hard deadline, it’s time to add one more: ADD. Accessibility-Driven Development.
For years, accessibility was treated as optional or “nice to have.” A box you ticked if you had time. But history shows us that regulations and compliance raise quality and drive standardization.
Think about hardware safety regulations or industry protocols. At first, they seemed like a burden. But once enforced, they became the baseline that allowed whole industries to build better. Today, shipping is faster than ever. Compliance is the safeguard that helps prevent quality from being skipped.
If you’ve worked in UX or frontend development, you’ve probably heard of the Web Content Accessibility Guidelines (WCAG). They’ve been around for decades, laying out the rules: make software perceivable, operable and understandable.
WCAG has been the global guideline for accessibility. But for years, adoption was inconsistent. Companies did what they wanted, or what they could afford.
That changes now. The European Accessibility Act (EAA) is in force as of June 28, 2025. It harmonizes accessibility requirements across the EU and sets real deadlines for compliance. This is the moment accessibility shifts from voluntary guidance to enforceable law. A time change for the industry.
In the U.S., the Americans with Disabilities Act (ADA) has fueled a rise in lawsuits over inaccessible websites and apps. Similarly, Section 508 of the Rehabilitation Act requires federal agencies and contractors to conform to WCAG. Between lawsuits and procurement contracts, WCAG has become the standard in the U.S. too.
Different routes, same outcome: WCAG tells us that we need better software for everyone.
Disciplines reshape the way we develop software. They’re mindsets that force us to shift perspective and raise the quality of the software we ship.
With TDD, we write failing tests before we write code. It flips the order. Instead of coding first and testing later, we define the boundaries up front.
The discipline: build resilience by considering how software might fail.
BDD takes this further. Instead of only testing functions, we write scenarios in plain language: Given, When, Then. It’s not only developers who can understand, but also stakeholders, product owners, testers.
The discipline: align software with real user expectations.
DDD steps back another layer. It tells us: don’t just model features, model the domain itself. Speak the same language as the business. Reflect its truth in your system.
The discipline: design software that mirrors business reality.
Each of these disciplines changed how we think. They aren’t just tools; they’re shifts in mindset.
Now it’s time for the next discipline: Accessibility-Driven Development.
ADD means designing and testing for the edge user first—the one with constraints. The one who doesn’t use your product the way you do. If it works for them, it will work for everyone.
Think of it like TDD. In TDD, you write a failing test first. In ADD, you define the hardest case first.
Keyboard-only navigation becomes your failing test. A screen reader flow becomes your scenario. High-contrast mode becomes your business constraint. You design and build until those pass.
ADD shifts the mindset. Accessibility isn’t something you sprinkle in at the end. It is a discipline that shapes decisions during building.
The discipline: build software that is accessible to many, not to some.
Why now? Without the European Accessibility Act, many teams would keep treating accessibility as optional. But with compliance dates set, ignoring accessibility is no longer a choice.
ADD helps you shift from reactive to proactive. Instead of scrambling with audits and lawsuits, you build accessibility into the process. Compliance becomes a habit, not a fire drill.
Here’s the point: designing for edge cases improves the experience for everyone. It’s called the curb cut effect. Those sidewalk ramps built for wheelchairs are also used by parents with strollers, travelers with luggage and kids on scooters.
You’re not wasting resources on a minority. You’re building better software. Accessibility isn’t overhead. It’s an advantage.
By designing for the most constrained environments, you raise the quality of the entire system.
Accessibility is not a gesture. It’s a discipline.
A new standard to comply with in software. And compliance has always been a driver of quality. Industry protocols in manufacturing. Safety standards in hardware. Now, accessibility in software.
You don’t have to choose between TDD, BDD and DDD. They’re not a menu. They’re a collection of development disciplines that shape how we build.
The one you need to add next is ADD: Accessibility-Driven Development.
Teon Beijl is a business designer and founder of Gears & Ratio, with over a decade of experience in enterprise software for the oil and gas industry. Formerly Global Design Lead for reservoir modeling, remote operations and optimization software at Baker Hughes, he now helps organizations deliver high-quality user experiences for industrial products through knowledge sharing, design leadership and implementing scalable design systems. Connect with Teon on LinkedIn or Substack.