Web3 Inclusive Design: How Failure Can Shape Success

Table of contents

Learning from Failure: The Video Player Case Study

I was contracted to build a custom video player that would be an accessibility triumph. The organization that my friend we worked with had a highly specific audience: users who were visually impaired. Our goal was not just to make it “usable” for them, but to ensure a truly inclusive and fully accessible experience. We carried our prior successes, our knowledge, and our confidence into the project. But we missed something critical.

We thought we had created a player that would meet all accessibility standards. Technically, we had. But during the development process—and more importantly, during usability testing—we realized we had crucial gaps. The player was nearly accessible, but it was not truly inclusive.

What we learned was humbling but transformation.

Winning the Contract and Initial Setup

At the beginning, we had all the right ingredients for success. We won the contract largely because of our deep expertise in assessing and building accessible video players. We had already done detailed audits on various players and knew the technical requirements backwards.

Our plan was to adopt a flexible, agile approach. We’d involve users in multiple phases and run frequent tests throughout development. It sounded like a winning formula, and in theory, it was.

But soon, our assumptions began to unravel.

The Missing Controls: A Simple Assumption Gone Wrong

One of the first decisions we made was to remove fast-forward and rewind buttons, thinking the timeline scrubber would suffice. We believed this choice would reduce clutter, simplifying interactions for screen reader users. It seemed like a small change, but in reality, this decision planted the seeds for a much larger problem.

When we pushed the player out for usability testing, users with different disabilities—particularly those using older assistive technology—struggled. Someone testing the player through an older version of a screen reader found that the timeline scrubber wasn’t adjustable. Initially, we were baffled. We’d tested it rigorously in the most current versions. How could this problem have avoided our detection?

What we missed was that not every user has access to the latest technology. Some people use outdated versions to navigate the web. So, while the timeline feature was theoretically accessible, it didn’t work for everyone. This was one of those failure moments that hurt the most, especially because we define ourselves as experts in accessibility.

Low Vision Users: A Missed Design Opportunity

Another group that we initially overlooked were users with low vision. While the video player passed technical tests, the user experience was clunky for them. A problematic issue? The timeline scrubber. We realized that low-vision users couldn’t easily see the time markers that allowed precise navigation along the timeline. We assumed that moving the video to a specific time would be easy! But that assumption hadn’t considered how users with magnifiers or reduced fields of view engage with screen content.

One user eloquently described the ordeal: They had to constantly guess where the 10-minute mark might be, move the scrubber, check the time at the left, and adjust again and again. Even with the best technical accessibility in place, the design failed to be intuitive for everyone.

Redesigning Based on User Feedback

We heard our users loud and clear. It was time to head back to the drawing board. First, we introduced a better timeline scrubber. We added a function that showed the current time as users moved along the timeline, putting it directly in their field of vision.

Additionally, fast-forward and rewind buttons made a comeback after we realized how much they mattered, especially for users accustomed to these controls on VCRs and cassette players. It became evident that some users relied on these more than the scrubber. The fact that these buttons were missing caused unnecessary friction.

What seemed like small design choices ended up creating major issues. Lesson learned: incremental improvements based on real-time feedback are vital in Web3 design processes. Inclusivity needs to factor into every step, not just the final product test.

Practicing True Inclusive Design in Web3

One mistake anyone can make—and we made—is focusing only on technical accessibility. Just because something complies with standards doesn’t mean it’s inclusive. In fact, inclusivity in Web3 design is multi-layered.

There are two levels of inclusive design:

1. Inclusion in the product. This is what we commonly refer to as ‘accessible design.’ It ensures that people with disabilities can use the product.
2. Inclusion in the process. This means involving users with disabilities as co-designers, not just testers. Specifically, including their experiences while crafting the solution ensures that we understand their needs on a deeper level.

True inclusion means engaging the actual users—people with disabilities—in the ideation, early design, and testing process. This isn’t just about ticking an accessibility box but creating innovations that work for everyone, from the get-go.

Moving from “Accessibility by Luck” to Intentional Inclusion

A common trap in the Web3 design world is creating an accessible product entirely by chance—happy accidents, if you will. Your design shouldn’t accidentally work for disabled users; it should intentionally meet their needs.

In our case, designing an accessible player wasn’t enough. We didn’t properly consult people with disabilities early in the process to inform the design better. Those missteps led to an inaccessible experience, even if it passed technical guidelines.

In Web3, where decentralized and innovative platforms are rising, accessible design must move beyond mere compliance. Inclusivity has to be intentional.

Shifting Left: Including Users Earlier in the Process

In typical Web3 product development, you often see accessibility validation happening near the end, during testing or finalizing stages. This approach assumes users with disabilities will merely tell you where you went wrong. However, this gives all the power to the designer.

What’s more effective—and truly inclusive—is shifting to an early user-centric design. Get user feedback while you’re still designing, not after you’ve built something. It’s about asking the right questions upfront:

• What don’t we know about how users will interact with this product?
• What assumptions can we challenge that may exclude someone?
• How can people with disabilities contribute to the design before it’s even a prototype?

Embracing Diversity by Default

One of the most powerful philosophies in inclusive design is, “Nothing About Us Without Us.” It encapsulates a critical concept: don’t design for people with disabilities without including their voices, perspectives, and experiences.

Accessible design in Web3 must reflect the diverse community it serves. This means that inclusivity needs to become the default, baked into the process, and not an afterthought. In a decentralized Web3 future, diversity in design means creating products that can adapt to any user—no matter their abilities, technologies, or location.

Conclusion: A Call for Intentional Inclusive Design

The key takeaway from this experience? Web3 inclusive design should empower all users, making sure that failure doesn’t stem from exclusion or oversight. Instead of using accessibility checklists as the final step, the process needs to involve people with disabilities from the outset. Their contributions directly shape better outputs, ensuring inclusivity for all.

As we continue shaping the future of the decentralized web, we must make space: space for diversity in thought, experience, and ability. Only then can we truly create digital products that work for everyone.

Intentional inclusion isn’t just necessary for legal compliance—it’s fundamental to responsible innovation in Web3. The future is decentralized; let’s make sure it’s also accessible for all.