The Road Ahead: The New Accessibility Landscape

In parts one and two of this accessibility series, I shared a framework for creating a business case that will secure sponsorship, as well as how to dodge the "built-in" accessibility trap in Design Systems. Now, let's take a look at how various factors are shaping the future in this domain, including the rise of generative AI, the shift to voice-first interfaces, the impact of post-legislation effects, and the community driving it forward.

The future of accessibility isn't just about compliance; it's about creating truly intelligent experiences that can adapt to user needs faster than ever before. Blurring the lines between what is a legal “must have” for people with disabilities, and native capabilities that we will all start using more frequently.

The Technology Catalyst: AI and Voice Redefining Interaction

It truly is a fascinating time to leverage tech to cater to the uniqueness of being human. We are every day closer to interacting with user interfaces that are created in real-time, allowing them to detect our specific interests and needs. This enables us to complete tasks and solve problems faster than ever before.

The effort needed to deliver digital experiences that anyone can access, regardless of their abilities, is also decreasing. AI can now be leveraged to auto-generate alt text for images, suggest color palette adjustments for better contrast, and even write more accessible microcopy. Making room for us tech folks to explore innovative ways in which we interact with digital products.

Up until now, our interactions with LLMs have been mostly chat-based. However, we are moving closer to a world in which using our voice and natural speech will become more relevant in our interactions with digital services. A concept that, until now, has been limited to screen readers and biased “smart” assistants that struggle to respond to a variety of user inputs, including synonyms, colloquialisms, pronunciation, and natural variations in speech across languages. I can’t tell you how often I currently find myself deepening my voice to mimic a male timbre when I speak to my Google Home, so that it understands what I’m asking, and it's incredibly frustrating when it responds to me in Spanish, even though I’m interacting with it in English (yes, true story, and yes, it's rude!). But those days are soon to be over with the advent of Voice User Interfaces (VUIs).

Imagine being able to accurately book hotels and flights with just a simple voice request to your device without having to touch the screen. Doing grocery shopping and selecting a delivery timeframe in a matter of minutes without having to fill out dozens of input fields. Being naturally and seamlessly guided through a checkout flow that adapts to your own particularities and asks you for the minimal and precise input the service needs from you in order to produce valuable outcomes.

The more we demand that voice user interfaces improve, the more we will be able to empathize with the reality of many people who are visually or motor-impaired today.

The opportunity for Design Systems: Patterns

Things are about to get interesting in this field, too. Will we have to start thinking about how to componentize voice commands?  Probably. However, as it has recently begun to be discussed in the design systems community, the future lies in patterns, more specifically, in how these help define how services communicate, understand, and interact with humans. 

To capture your users' attention, your brand becomes the voice, and your design system the infrastructure to ensure the delivery of a coherent experience that is aligned with your values across devices. Your system will also be responsible for abstracting conversational flows that are more similar to how humans actually speak. And, we will also need to ensure that it can handle errors properly in case of mumbling or mispronunciation, just like humans do. Your system will help define, preserve, and amplify the interface’s personality.

The Legal Tailwind: Life After the European Accessibility Act (EAA)

The European Accessibility Act's deadline, which makes accessibility a legal requirement for a wide range of digital products and services in the European Union, passed on June 28th, earlier this year. In preparation for it, many organizations shifted the conversation around accessibility from "should we?" to "how do we?". In fact, there's a noticeable increase in demand for accessibility specialists and tools, and these companies have correctly started to identify their Design System as critical infrastructure to achieve compliance at scale.

However, a few businesses are seeking exceptions in the legislation to avoid being subject to the EAA. Others have failed to implement the required measures before the deadline. Notably, the first publicly reported action by a coalition of French disability advocacy and legal organizations issued formal legal notices to four of the country's largest grocery retailers: Auchan, Carrefour, E. Leclerc, and Picard.

The legal action was explicitly based on France's national implementation of the European Accessibility Act. The advocacy groups issued a clear ultimatum: the four retailers were given until September 1, 2025, to bring their online grocery services into full compliance with the regulations. Failure to meet this deadline would result in the initiation of formal legal proceedings in court.

As legal pressures increase, the design systems community isn't just watching from the sidelines; it's actively responding.

The response from the design systems community

A couple of weeks ago, I attended another session of the Into Design Systems chapter in Berlin, in which design systems practitioners from companies such as Babbel and Zalando shared their knowledge and advancements to ensure their users have access to more inclusive experiences including detailed recommendations from their frontend implementation, as well as the positive business impact that implementing accessibility practices has brought, raising the bar for what is expected from folks in product development.

Meetups like these are vital. They transform abstract challenges into shared, solvable problems and foster a collective sense of responsibility, pushing the accessibility and design systems space forward faster than siloed attempts could do alone.

Building Tomorrow's Inclusive Experiences, Today

The future of accessibility is a powerful combination of legal mandates (the push), technological innovation (the pull), and community collaboration (the momentum).

Instead of standing still and waiting for the next tech wave, my invitation is to start experimenting and playing around with AI tools that allow you to reproduce the VUI experience and create prototypes that use voice as their main input source for your existing apps. And join the local (and worldwide) communities that care about inclusivity in the digital world.

This is our responsibility as digital experience creators, so that we can help shape the next wave of tech in interaction design, one that is natively inclusive.

Dodging the "built-in" accessibility trap in Design Systems

In the first part of this series, I shared a guide on how to build a business case that resonates with leaders in data-driven organizations to secure accessibility buy-in. But be warned: victory comes with a risky assumption: Folks might start referring to "out-of-the-box" or "built-in" accessibility in your design system. While it sounds great, this simple statement can unintentionally shift the entire burden of compliance onto the design system team. This isn't just a misunderstanding; it's a trap. And I fell right into it.

When I sold the idea of going through our design system to ensure we were WCAG 2.2 Level AA compliant, it was easier for senior leadership to associate the effort with a term such as delivering "out-of-the-box" accessibility in the system. I didn't push back much because, in essence, it was true. Delivering accessible components would drastically reduce both the risk of introducing bugs and the effort needed by product teams to ship accessible digital products. But that also meant that the responsibility of being accessible compliant before the European Accessibility Act (EAA) deadline fell on the design system team. Learn from my mistakes, reader friend!

This trap notion really resonated with me while listening to a discussion on the Design Systems in Depth podcast by Elise Holladay.

The "Built-in" Myth: A Shared Misunderstanding

Design systems can absolutely help you deliver more inclusive experiences. If the input field in your system is accessible, the 100x input instances in your digital product will also be automatically accessible, provided that they are indeed coming from your system. Right?

But, Design Systems are no silver bullet. Mainly because the context of your organization's domain and your specific user flows, for which product teams are ultimately responsible, should be factored in. The focus order of those input fields might not match the visual layout on one screen, making it impossible for assistive technology devices to properly guide users with visual impairments, and hence, delivering a poor accessible user experience.

"Out-of-the-box" accessibility can be interpreted as: "As long as teams are adopting the DS, and since it has built-in a11y, the job is done! We are 100% compliant because the system itself is 100% accessible."

But this is far from the truth. Let's break it down.

Having a system that is 100% accessible is unattainable; the system itself will never be "done". Your DS is a living product that needs to evolve organically alongside your organization's needs. Your internal and external customer problems will change over time, and part of that evolution is adapting and responding promptly to those needs. You are responsible for putting guardrails in place to ensure accessibility is considered whenever a change is made to your system. But as new conformance laws come into effect, your design system infrastructure would need to be extremely efficient to respond to those changes on time and remain fully accessible.

Has the organization fully embraced and adopted your system? How do you define adoption? You'd be surprised at how everyone has a different understanding of this metric. I'll dive deeper into this in the future (subscribe to learn more when it comes out!), but for now, let's agree that consumers will deviate from the system, and that's okay, because they need room to experiment and play around with UI patterns not currently supported by your DS. This puts the responsibility back on those experimenters to ensure the delivery of inclusive experiences.

And finally, if an audit shows accessibility bugs, chances are some of them are specific to product feature team domains. Making a platform team responsible for bug fixing without proper context is expensive and inefficient due to the time spent trying to understand said context. And, it could have a significant impact on other key business metrics. I've seen critical bugs being caused unintentionally by "minor" UI improvements, resulting in a loss of revenue during downtime.

A New Narrative: From "Built-in" to "Accessibility as a Partnership"

Let's change the way in which we talk about accessibility from a binary setting to a scale. A design system that supports accessibility will help make digital products more accessible; however, it will not guarantee 100% accessibility compliance. This is a joint effort by everyone involved in Product Development, an effort that your design system can facilitate and amplify.

Even if your design system is widely used and loved by your internal users, there's still some work to be done on their end. You could clearly state in your documentation an SLA (Service Level Agreement) around accessibility with the following:

Use any opportunity you have to educate and set expectations: Your design system's newsletter, your Slack channels, office hours, product demos, planning meetings, PRDs, or WBDs, you name it. Your DS will make the right way the easy way, but not the only way to deliver accessibility.

Design Systems teams already have a lot on their plate, and many of them are understaffed. Overselling makes you the one to blame in case of an accessibility problem, throwing curveballs at your planned roadmap, and undermining the work your team is already delivering.

Dodging the "built-in" accessibility trap isn't about deflecting responsibility. It's about defining it. By shifting the conversation from the myth of a 'plug-and-play' solution to the reality of a powerful partnership, you empower your entire organization. Your design system becomes what it was always meant to be: not a magic wand for compliance, but a powerful engine that accelerates the delivery of inclusive, accessible experiences at scale.

This is how you build a sustainable culture of accessibility, one where ownership is clear, collaboration is key, and product teams are equipped for success.

Now that we've established the "why" and "how" to frame the conversation around the investment in accessibility. In part 3, I will close with a look into the future of the "what" in the democratization of inclusive user experiences with the introduction of agentic AI.

Mentioned in this Article

The concept of the "built-in" accessibility trap was inspired by the conversation between Elyse Holladay and Daniel Henderson-Ede in this episode of Design Systems in Depth. A highly recommended listen after you've finished here!

How to Get Buy-In for Accessibility: A Guide for Data-Driven Teams

Early in my journey as a Design Systems Product Manager, I identified the impact that delivering accessibility would have not only on the business but on our end customers. The practice of crafting inclusive user experiences that can be used by as many people as possible, regardless of their abilities, has been a part of my tech career for the last fifteen years. Yet, it is surprising that, in many cases, this is still an afterthought in product development, and most recently, a legal requirement rather than our responsibility to our fellow human beings.

I get it. When there's a lot of pressure to deliver new features to customers that bring the big bucks, thinking of how the minority of the digital population sees your product might not be a priority. Your analytics data probably shows that most of your users navigate using devices that you're already familiar with because you use those yourself. In fact, Google Analytics considers the use of assistive technology sensitive personal information because it would provide details on people's health or disability status, which could be used to discriminate against these users by targeting them with different advertising or even denying them services.

Without having full visibility into how the human spectrum interacts with digital products, it can be difficult to exercise empathy to ensure they are truly usable and can help people solve the problem for which your business has a solution.

If you're a design systems practitioner in a data-driven organization, you have probably faced this conundrum: How to secure the accessibility investment by presenting the right numbers, when there are other competing initiatives to deliver, say, more components or multi-theming support? Most likely, embedding accessibility into your system was the plan from the beginning, until other tasks crept in, and now it is part of your tech debt.

Enter, accessibility compliance.

The European Accessibility Act (EAA) deadline passed earlier this year on June 28th. According to it, a wide range of everyday products and services sold within the European Union must now be accessible to people with disabilities and the elderly. This affects organizations by making accessibility a mandatory legal requirement for products like their e-commerce websites, mobile apps, computers, e-books, and self-service terminals such as ATMs and ticketing machines.

Essentially, the EAA has transformed digital and product accessibility from a "nice-to-have" feature into a fundamental legal obligation. Other similar legislation acts around the world exist to alleviate this issue: The Americans with Disabilities Act (ADA) in the US, the Accessible Canada Act (ACA), Disability Discrimination Act (DDA) in Australia, the Rights of Persons with Disabilities (RPwD) in India, or the Web Accessibility Law in Japan. Other specific compliance acts for public and government services exist in Norway, New Zealand, and Brazil.

Find time to understand how the legislation works in the places where your business operates. In most cases, it asks for compliance with WCAG standards. You can show incremental value by starting with adherence to WCAG 2.2, Level AA. Aiming for AAA from the start will be way more expensive to implement and therefore a harder sell. Once you have a solid understanding of AA, you can take the leap to the next level. Defining your target is a crucial step in calculating the effort needed to help your organization deliver compliance.

Next, use your preferred LLM to help you calculate what the potential financial impact would be in fines in case of non-compliance. Trust me, that number will be an eye-opener not only for you but for the business. When I did this exercise myself, I found that the investment in accessibility could save up to 1.5 million euros in fines for my organization. Showing the data immediately raised the alarms of leadership and secured the time my team needed to work on accessibility.

What if there's no legal requirement?

Accessibility legislation acts are still limited to certain territories, but there's data around the number of users worldwide who present some type of disability.

In 2023, the WHO estimated that 16% of the digital population presents some sort of permanent disability under these categories:

• Visual – Example: blindness, low-vision, color blind
• Hearing – Example: deaf and hard of hearing
• Motor – Example: not having the use of certain limbs and paralysis
• Speech – Example: people who are not able to speak or who have a speech impediment
• Cognitive – Example: dyslexia, autism, ADHD

The total target percentage could be closer to 20% if we take into account temporary impairments (A person with a broken arm or who has had recent eye surgery) or situational limitations (A new parent holding a baby in one arm, someone using their phone in bright sunlight, or a person in a loud environment who cannot hear audio). At some point, WE ALL will need access to inclusive digital experiences.

You could use this information as a proxy metric. Essentially, your business could be benefiting from extra income coming from an untapped market of 20% of underserved users. Yes, there's no guarantee that all those additional users will convert if your products are accessible; there are a lot of factors in their buying decision process. However, if you reduce the friction in their experience, the likelihood of them becoming customers will increase. Crucially, this goes beyond a single transaction. For a community so often met with digital barriers, a seamless and accessible experience builds profound and lasting customer loyalty. These users are not only more likely to stay with your brand but also to become vocal advocates for it.

The empathy appeal: Beyond the numbers with qualitative evidence

While the numbers are compelling, nothing makes the case for accessibility quite like seeing and hearing the real-world experiences of people. Make use of resources that quickly convey the accessibility pain points of your customers.

Record yourself (or, even better, a real user) navigating a crucial business flow using assistive technology. Your UX Research team might be extra helpful here. Use your TikTok producing skills to make it short but compelling.

If you have access to sentiment analysis tools, search for user comments related to accessibility. This can provide a wealth of unsolicited feedback.

Reach out to Customer Service to see if there's any report on the topic. The most powerful feedback often comes from someone who wants to use your product but is blocked by a preventable barrier.

While most organizations acknowledge the importance of accessibility, they often struggle to prioritize it against initiatives with a clearer ROI. By combining hard data such as risk-avoidance (legal fines) and opportunity-seeking (untapped market) with human stories, you create a holistic and undeniable case for prioritizing accessibility. You're not just showing a market opportunity; you're showing the real people you can help by creating a more inclusive product. If you need a partner to help you build that case, we're here to help.

Securing the investment for accessibility is a huge win, congrats! Now, how do you make sure your Design System is accurately held responsible for accessibility? In my next article, I will explore the biggest pitfall to avoid.

Building a Web Design System with AI: A 960-Hour Project in 55 Minutes

I had some specific requirements for the Design System:

• Built using React and TypeScript
• It should contain basic components for an e-commerce website
• All of the components should be responsive and mobile-friendly
• Should meet AA accessibility guidelines
• Should eventually scale to add support to React Native
• Should support multiple brands; therefore, we needed a robust token system

I picked Cursor to help me turn my vision into a reality. I gave it the details, selected Claude 3.5-sonnet as my desired model, and off we went to spend quality time together building the project from scratch. It suggested using styled-components for scalability, and I agreed because I was already familiar with it. Then I saw the folder structure being created in a matter of minutes, and I felt like a goddess approving files here and there, scanning through them, and more or less understanding what was going on. Because things have only slightly changed since the last time I added a line of Frontend code over 10 years ago. Claude, my new best friend, explained the process and broke it down into digestible steps for me. I tried to praise the work every now and then, because it seemed to appreciate the feedback.

All I had to do was start the server to preview the magic. Luckily, I knew how to do that on my own. But I’m sure Claude would have helped me with something as simple as that had I just asked for it.

And there I had it —a fully responsive landing page with instances of basic components: buttons showcasing different variants and states, including an optional icon. Other form elements, such as Input fields, checkboxes, radiobuttons, and the cherry on top: A product card. I was feeling greedy and asked for a Modal and a Toast with three states. Claude didn’t forget about my wishes, and not only allowed for one brand, but also delivered light and dark themes. Creating a toggle that allowed me to quickly switch between them.

I stared at the screen, looking at what, to my rusty eye, seemed to be a decent solution that was produced in less than an hour and a couple of prompts. A similar output that three years ago, had taken two full-time engineers in my team about three months to deliver. A 99.9% reduction in time and effort, from approximately 960 person-hours to 55 minutes.

To be fair to my former colleagues, Claude’s work was fast but far from perfect. My QA trained eye couldn’t help but notice how certain elements weren’t exactly aligned. Also, the dark theme did not work properly on the product card. Nothing that Claude would get upset about after I pointed it out, as it promptly fixed those details for me.

I was absolutely impressed and excited. I spent the next couple of hours (deep into past midnight, followed by vivid dreams of AI prompts) playing around with my new project. I asked Claude to create proper documentation and a repository in GitHub. I uploaded a first version, and then decided to branch out to integrate Storybook. And, this is where the real collab happened and where I spent most of the time, as it was no easy task.

The Collaboration Challenges

After a couple of hours, I felt we were going in circles, moving random settings to plug my design system into this well-known framework. I copied and pasted console errors, killed and restarted Storybook servers several times.

Claude was getting tired, I could tell. Even after starting a new chat every now and then. It insisted I should see things working and even suggested clearing the browser’s cache —the last resort of every developer, myself included. I started to doubt the quality of the output. But at the end, we made it, we had a running instance, and I could see the full splendor of my components.

As I continued asking for features, “Let’s add a third brand that also has light/dark modes”. I started to notice my initial requirements were not being taken into account as much. I had to ask Claude to remember that we already had a working token system, and values should not be hard-coded in the components. At some point, it created documentation for random components we hadn’t yet implemented, and I got a Spinner as a freebie somehow, too. Not to mention that hell broke loose briefly when I asked for an accessibility audit of the components we had created. Some frustration and boredom started to creep in, caused by the need to repeat myself, making the excitement wear off.

Conclusions

Even though I panicked for a bit after seeing how quickly Claude produced what I asked for (fearing for my own role in this industry), my little experiment allowed me to understand that we are not yet at a point where AI will fully take over tech jobs. A lot of manual intervention, and hence, rework is still required to produce quality output that can truly solve high-scale product and tech problems. However, what is becoming increasingly evident is that organizations will start to consider replacing those who fail to learn how to utilize AI to their advantage and can't exercise critical thinking to make their tasks more efficient. To me, AI's potential lies in how it will allow people in the tech industry to become creators rather than makers. Problem solvers rather than machine language writers. Isn’t that exciting?

Also, this technology is moving incredibly fast; more efficient models are launching every day. As of today's time of writing, Claude's Sonnet version is 4, making me think that this from-scratch Design System experiment is a little outdated, only a few weeks after I worked on it. Most AI models now have a memory, which would've allowed me to store my initial requirements, avoid the need to repeat myself, and minimize the frustration of subpar output.

AI can be leveraged to produce fast-track drafts, but it is critical and collaborative thinking that empowers the delivery of final products. Models might be getting better at writing the code, but the human mind is still writing the story to create meaningful outcomes.

Instead of spending months building foundational components, Design System teams can now focus their human expertise on strategic decisions: Defining a scalable architecture, establishing governance frameworks, and solving complex user experience challenges for both internal and external customers. The question isn't whether AI will transform design systems work; it's whether your organization will be strategically positioned to capture that value.

If you are wondering how to integrate AI into your design systems workflow, let's have a chat. I can help you deliver measurable efficiency gains while maintaining the quality and coherence your users expect.

Design Systems: A Product for People in the Age of AI

The business benefits of a design system are evident. They provide product teams with a foundational framework of tools and assets they can rely on to build user interfaces in alignment with your brand, freeing them from having to implement the same button for the n-th time. Additionally, you gain the benefit of delivering coherent experiences to your end customers, which helps them maintain trust in your business and encourages them to continue paying for your products or services.

But there's a critical aspect to a Design System that is often overlooked. Its fundamental goal is to boost collaboration and accelerate innovation by empowering the people who use it. These are individuals in product teams who are typically passionate about solving problems creatively, but often communicate in different technical languages during their day-to-day work activities.

When the users of a Design System can rely on a shared language, the process overhead, the back-and-forth between disciplines, and the delivery time of those critical features are significantly reduced. And these benefits aren't just theoretical. Case studies, like IBM's Design Thinking practice, have shown that a unified approach can lead to a 33% reduction in development time and a 2x faster time-to-market.

By working from a single source of truth, product teams eliminate the ambiguity that leads to costly rework and inefficient communication. It allows them to really focus on solving the problem with the highest priority in their domain, moving with confidence, getting extra time to work on what each discipline enjoys the most, and in turn, uplifting the other.

In the current age of AI, fostering this type of collaboration is more crucial than ever. If, like me, you've played with AI-powered generation tools that produce code or create beautiful user interfaces, you'll notice that there's a disconnect between the two domains when it comes to creating something that can actually be shipped for an organization. It is not enough to tell one of these tools to build an application with a "modern UI" or to request them to create a user flow without understanding the implications of the default tech frameworks that are used behind the scenes. The result will look generic and will be very difficult to integrate with your existing codebase, leading to more rework.

Human intervention is still needed to produce outcomes that can fully understand all your requirements, including high-quality and scalable code that is aligned with your own infrastructure, as well as visual and interactive alignment with your brand standards.

The Hidden Benefit: Team Morale and Retention.

I can attest to the fact that using a common language has a boost in team morale and engagement. Solving problems together creates a sense of camaraderie and ownership in teams. This, in turn, has a direct impact on employee retention and can reduce churn, which is extremely expensive for organizations.

Consider the average time to hire a new tech employee, which can vary from 30 to 40 days, as well as the cost of that vacant seat. The expense of replacing a single employee in a specialized role is estimated to be 100% to 150% of their annual salary, accounting for recruitment fees, onboarding time, and the significant productivity loss while the new hire gets up to speed.

When an employee goes away, they take with them valuable business knowledge about how your organization works, and depending on your size and political complexity, building that knowledge takes from 2 to 6 months. How often are you willing to make that investment in a new hire for the exact same position?

By fostering a collaborative environment with a design system, you're not just improving the day-to-day; you're investing in the people you already have, which can be one of the most powerful and cost-effective business strategies an organization can pursue.

Even as businesses leverage AI to automate repetitive tasks, humans remain their most valuable asset. Next time you discuss a Design System, ask yourself: What's the real cost of a team that can't collaborate effectively? Investing in a Design System isn't just about efficiency; it's about empowering your people, fostering a sense of belonging, and ultimately driving innovation.