On Standards that influence the future of Accessibility and Inclusive Design. Q&A with Navya Agarwal.

Q1. As an active contributor to the W3C ARIA Working Group, you’ve been directly involved in shaping web accessibility standards. Can you share insights into how emerging web technologies and frameworks are influencing ARIA specifications? What are some of the most significant accessibility challenges you’re working to address at the standards level?

The landscape of web accessibility is shifting rapidly; it’s genuinely exciting and at times overwhelming. As part of the W3C ARIA Working Group, I’ve seen first-hand how component frameworks like React, Vue, and Angular have revolutionized our approach to accessibility semantics. These frameworks empower us to build sophisticated, reusable components, but can also obscure or undermine critical accessibility information if not handled thoughtfully.

One of the most pressing challenges we are addressing is the semantic disconnect caused by abstraction layers, which can make visually polished components difficult or impossible for assistive technology users to access. My focus within the ARIA group is on developing technical guidance and evolving specifications so that accessibility is preserved and enhanced, even as web technologies advance.

With the rollout of WCAG 2.2, which further raises the bar for what’s considered accessible (especially for touch and cognitive use cases), our work becomes even more essential. ARIA provides the technical “how” that helps developers meet these broad accessibility requirements in practice.

Q2. Having led greenfield projects like Adobe Express and Creative Cloud Learn, you’ve experienced the challenges of building design systems from the ground up. How do you approach design system governance when scaling across multiple products and teams? What strategies have proven most effective for maintaining consistency while allowing for product-specific needs?

When we built design systems for Adobe Express and Creative Cloud Learn, the biggest challenge was balancing consistency with flexibility. Initially, we tried to solve every team’s need in the core system, which only led to complexity, slow adoption, and a sense that the design system was more obstacle than an asset.

The breakthrough came when we treated the design system as a platform, not a prescription. We restructured it into robust base components with clear extension points, enabling teams to adapt while preserving accessibility, interaction patterns, and usability. Governance shifted from enforcement to enablement, with a federated model where each product team had champions bridging their context with the central system.

A practice that proved invaluable was variance documentation. Instead of blocking modifications, we captured and learned from team adaptations: successful patterns informed the core system, while missteps became case studies that accelerated collective growth. Ultimately, the key strategy was enforcing consistency at the behavioral and accessibility level, while allowing visual and contextual flexibility. This approach increased adoption, improved efficiency, and drove continuous innovation across the organization.

Q3. With AI becoming increasingly prevalent in web development workflows, how do you see AI tools impacting accessibility implementation? What opportunities and risks do you identify when AI is used to generate UI components or assist in accessibility testing and remediation?

Recent advances in AI are radically expanding what’s possible for users with disabilities. AI now powers services like AIRA and Be My Eyes, enabling real-time navigation, item identification, and reading of complex information through smartphones or camera-equipped glasses—transforming daily independence for many.

However, these possibilities come with real risks. AI systems trained on incomplete or biased data can inadvertently exclude users or propose accessible fixes that lack nuance in real-world use. As accessibility experts, our responsibility is to shape inclusive AI and ensure ongoing feedback from people with disabilities, so innovation genuinely improves access rather than introducing new barriers.

The promise of AI lies in its ability to augment, not replace, expert judgment. It can flag potential issues, suggest improvements, and accelerate the adoption of accessibility best practices across products. But overreliance without robust validation risks creating false confidence. That’s why my approach is to integrate AI into developer workflows and design systems, grounded in strong governance and real-world testing to ensure genuine accessibility for all users.

Q4. When architecting large-scale frontend applications, what architectural patterns and technical decisions have you found most effective for embedding accessibility as a core principle rather than an afterthought? How do you balance performance optimization with comprehensive accessibility features?

I’ve found that the most effective approach is what I call “semantic-first architecture.” Rather than starting with visuals, we model the application’s information hierarchy and user workflows in purely semantic terms. This foundation guides component structure, routing, and state management, so accessibility scales naturally. A pattern I rely on is “progressive enhancement with semantic anchors”: features begin with fully accessible HTML and minimal JavaScript, then are enhanced without breaking the semantic layer. This ensures users relying on assistive technologies always have full access, even as richer interactions are added

The performance tension is real, and I won’t pretend it’s always easy to resolve. Accessibility features can add weight, but I’ve found that when accessibility is considered from the beginning, these costs are much more manageable. My strategy is to identify the core semantic structures and interactions that accessibility requires, then optimize aggressively around them. We might lazy-load visuals or defer non-essential scripts, but accessibility foundations like keyboard navigation, screen reader support are available from the first render.

From my experience, accessibility and performance are not at odds; both benefit from clear, purposeful design, and the most accessible interfaces often turn out to be the most efficient and usable.

Q5. Beyond your technical contributions, you’re known for fostering inclusive tech communities and mentoring developers. From your experience leading high-impact projects, what organizational and cultural changes are most critical for creating truly inclusive development environments? How can engineering leaders better support accessibility expertise within their teams?

This question hits close to home. Creating truly inclusive development environments means moving from accessibility compliance to accessibility empathy. Teams that focus solely on WCAG checklists may produce technically correct but practically unusable experiences. I always start accessibility initiatives with direct engagement with real users, people who rely on screen readers, voice recognition, or other assistive technologies. Seeing how they navigate and struggle with interfaces firsthand drives lasting change in both design and engineering practices.

For leaders, embedding accessibility expertise across teams is far more effective than centralizing it. I recommend a hub-and-spoke model: core accessibility specialists provide guidance, while every team has a champion who can catch issues early and escalate when needed. Accessibility should be woven into existing development rituals – code reviews, user stories, and design discussions so it becomes a natural, continuous part of the workflow.

From a leadership perspective, embracing a “shift left” approach is key. Accessibility considerations must be raised at the earliest stages of planning and design, not deferred until QA or launch. This proactive strategy reduces costly retrofits and empowers teams to build inclusion into the product from day one, raising the standard for quality and user experience across the organization.

…………………………………………..

Navya Agarwal is a visionary technologist and champion for digital equity, redefining how people experience the web. As a senior engineer at Adobe and a global speaker on accessibility, she leads initiatives that make digital products more inclusive and usable for everyone. Through active contributions to the W3C ARIA Working Group and the International Color Consortium (ICC), Navya shapes global standards that influence the future of accessibility and inclusive design. She is known for blending technical innovation with an equity-first mindset, delivering solutions that empower all users and set new benchmarks for inclusive technology.