Scaling Accessibility: Frontend Accessibility Architecture & Leadership: Niharika Pujari

>> AMBER HINDS: Hello, everybody. We are going to officially get started in about three minutes. I just want to give time for everyone to join, but please feel free to say hello in the chat, share where you are from, how you use WordPress, or what you do with accessibility. I think that is always nice for our speaker to know who is here and where they’re from. We were just having some nice conversation amongst the three of us about our different locations around the world. I’m in Austin, Texas, and Niharika is in Boston, and Paula is in the Dominican Republic, so we’ve got like a little triangle going of very different types of weather.

Please feel free to introduce yourselves, say hello, and we will officially get started. I will read out a few of these, so if you can’t see the chat, don’t worry. You’re not going to be missing out. Andrew was our first person who was brave and said hello from Massachusetts in the USA. Andrew is a traditional site webmaster. Elvis said hello from Zagreb, Croatia. I probably said that horribly wrong, Elvis. I’m sorry about not knowing your city name. Let’s see. Evelyn said hello from New Brunswick, Canada. Steven said hi from Denton, Texas. Steven designs and develops WordPress with accessibility in mind from the start, and answers questions from site owners as best as he can.

Oh, Elvis said I did an okay job pronouncing his city name, so that’s good. All the different names always throw me off. Oh, here’s a fun one. I’m so sorry, but Hoduikal, maybe, said hello from Samarkand, Uzbekistan, maybe. I love this meetup at this time slot. We used to do our second meetup of the month later in the day for us in the US, and it wasn’t as European-friendly, but this time slot, we get lots of folks from Europe, which I very much appreciate. If you’ve just joined us, we’re going to get started in one minute. I am just giving time for more folks to join in. Please feel free to say hello in the chat and share where you are from, and then we will kick off in just a moment.

Welcome to WordPress Accessibility Meetup. Scaling Accessibility: Treating Accessibility as Frontend Architecture and a Leadership Responsibility with Niharika Pujari, who is the lead software engineer at McGraw Hill. We are so excited to have you all here today. If you haven’t been before, there are a few things to be aware of. The first one is that we have a Facebook Group you can use to connect between meetups. You can find it if you go to facebook.com/groups/wordpress.accessibility, or just search WordPress Accessibility on Facebook. This is a good way to ask questions, answer questions, get recommendations on accessibility, and generally connect with other folks who are interested in building a more accessible web.

Everyone always asks, “Is this being recorded?” Yes, it is being recorded. It takes us about two weeks to get corrected captions, and a transcript, and an edited video, and then we will post that up on our website. You can find upcoming events and past recordings in one place if you go to equalizedigital.com/meetup. You can join our email list to get news and event announcements if you go to equalizedigital.com/focus-state. We send out one email a week that’s a summary of roundup of information from accessibility-related websites and resources all around the web, not just ours, and then we also send out emails before there are going to be events, so you’ll know to go register for them.

This meetup will also be on our podcast in audio format, if you prefer to listen, and you can find that at accessibilitycraft.com. We are seeking some additional sponsors for the meetup, mostly for sign language interpretation. We are so thankful to have our captioning covered for the year, which is very exciting, but if your company would be interested in helping us to make it even more accessible with some sign language interpretation, please reach out. The best way to contact us if you have suggestions for the meetup, if you need any additional accommodations to make the meetup work for you, or if you are interested in sponsoring is to contact us at meetup@equalizedigital.com.

I know it’s a Tuesday, but it really feels like a Monday to me here, so I apologize for all my stumbling this morning in my intro. I have not introduced myself yet. I am Amber Hinds. I am the lead organizer for this meetup, and I own a company called Equalize Digital. We are a mission-driven organization and a corporate member of the International Association of Accessibility Professionals, or IAAP, focused on WordPress accessibility. We have a WordPress plugin called Accessibility Checker that helps you find and fix problems on your websites, as well as online courses for NVDA and VoiceOver screen reader testing, and selling accessibility if you are interested in taking more training at your own pace.

We do accessibility audits, remediation, and consulting, and you can learn more about us at equalizedigital.com. We do want to give a big shout-out to our sponsor, who is covering the cost for both our live captioning for this event and also corrected post-event transcription and captions. That sponsor today is GoDaddy. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience.

GoDaddy provides a managed WordPress experience that is as easy as it is effective. The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, and malware removal so that their Pros can spend less time on monotonous maintenance and more time building their businesses. You can learn more about GoDaddy if you go to godaddy.com.

I also always like to ask folks, if you are willing, on whatever social media platform you are on, to tag them and say, “Thank you, GoDaddy, for sponsoring live captions for WordPress Accessibility Meetup.” That helps to tell them that this is important and that it matters and that people appreciate the support for the meetup and the additional accessibility. If you’re willing to do that and tag GoDaddy, we would very much appreciate that.

There are two upcoming events in April that I want you all to be aware of. The first one will be on Thursday, April 2nd, at 10:00 AM Central in the US, which is the same time slot, and it will be called Beyond Technical Accessibility: European Accessibility Act Compliance Requirements. That will be presented by Bet Hannon. Then, on Tuesday, April 21st, also same time slot, Donata Stroink-Skillrud will be presenting Training Support Staff on Accessibility. This is a big thing that actually a lot of companies don’t think about, which is how do you support the accessibility in your website and your products with actually having support staff who understand how to provide accessible support.

She’s going to talk about everything that is required in order to create training for staff, write company policies related to accessibility for employee handbooks, and all of those things, which, if you’re doing an international format of a VPAT or an Accessibility Conformance Report, you have to include all of this stuff in that VPAT. That presentation should be very neat as well. I am super excited to introduce our speaker. I’m going to pull her up here. Niharika Pujari is a lead software engineer at McGraw Hill, with over eight years of experience designing, developing, and delivering robust, full-stack web applications.

Niharika works in the higher education space, building technology that supports instructors, institutions, and learners through scalable backend systems and thoughtful end-to-end solutions that drive real education impact. We are so excited to have you here.

>> NIHARIKA PUJARI: Hi, nice to meet you all. Thank you for having me here today.

>> AMBER HINDS: I’m going to stop sharing. I’m going to let you take over with the share. For everyone who is watching, we will have time for questions at the end. There is a Q&A module in Zoom. It is most helpful for us if you can put your questions there instead of the chat, only because they sometimes get buried in the chat. I’ll let you take over, Niharika. Thank you so much.

>> NIHARIKA PUJARI: Of course. Thank you so much, Amber. Let me start by sharing my screen. Here we go. Can everybody see my screen?

>> AMBER HINDS: Yes.

>> NIHARIKA PUJARI: Awesome. All right. First of all, hi, everyone. Thank you for joining in today’s session. I’m really excited to be here, and my talk is going to be about Scaling Accessibility: Treating Accessibility as Frontend Architecture and a Leadership Responsibility. I would like to introduce myself. Here I am. My name is Niharika. I work as a lead software engineer, and I’m also a speaker, writer, contributor to accessibility and frontend communities. My focus is mainly on frontend architecture and how accessibility can fit in large systems. A lot of my work involves building and maintaining large frontend systems, and with many contributors and shared components.

That’s really where my interest in accessibility grew. Every small UI decision that we take has a large impact on systems. I’m very, very interested in how systems can, like we design every single day, for example, design systems or component libraries, and how these development workflows fit together. They influence accessibility outcome on a whole picture. I just wanted to make a quick note that all the opinions here are expressed on my own, and they do not represent any opinions or policies of any organization. Before we get into the main content, I wanted to do a quick vibe check, and I wanted to ensure that we are all ready to go and we are excited.

I’ll take a second here, and I’ll take silence as a yes, and let’s get started. Thank you for the vibe. Okay. I wanted to quickly get started with a quote from Tim Berners-Lee. “The power of the web is in its universality. Access by everyone, regardless of disability, is an essential aspect.” This caption, this particular quote, captures the idea really well. The web was always originally designed to be universal. Accessibility isn’t something that we add later. It is fundamental to the idea of the web itself. If I think about it, accessibility is not only for a small group of users. It improves the experience for everyone.

Bigger buttons help people with limited hand movement, but they also help users who may be using their mobile phones to tap very easily. High contrast text not only helps users with low vision, but it also helps anybody who might be using their screen in bright sunlight. Captions also support deaf users, but they also support people in noisy areas where you are not able to hear properly the audio. In that sense, accessibility is always about a universal design. When we design for more users, we make the products usable for everybody.

In this session today, we’ll focus on the following. First, we’ll take a look at why traditional accessibility approaches often do not scale in modern frontend systems. We will talk about how accessibility outcomes are shaped by architectural decisions. We will also take a look on shift left approach and talk about design system a little bit. We will understand how teams and leaders can build systems that enable accessibility instead of constantly fixing it later. How leadership can influence everyone. Finally, we’ll look at some practical steps your team can take beginning next week.

The Problem. Let’s talk about the problem a little bit. Many of us would have seen that we are working on fixing some issues after an audit or an accessibility review, and then these same issues that we just fixed comes back in later releases. This experience is very common. Today, in my talk, I’m going to cover why that happens and how we can design our systems where accessibility would scale naturally. Over time, I started noticing something very interesting about accessibility in systems. Even teams that genuinely care about accessibility often struggle when it comes to scale.

Here, I wanted to cover a familiar story. This is a pattern that many teams would probably recognize. A team puts real effort into accessibility. They organize many training sessions, they would run audits, and when issues are identified, they work really hard to fix them. On paper, that sounds like the right approach. It is clear that those activities are very, very valuable. Training will help you build awareness, and audits will help you uncover the real problems that you might see in your products. What happens in that is next, when you come to a release, you again and again see that similar issue showing up again.

Maybe it is another missing label. Maybe it is another keyboard navigational issue, or there’s some dialogue that is not working correctly, or there is a focus alignment issue. These problems are not something that you would have not seen, but they reappear when you are trying to do something. The problem is not that teams are ignoring accessibility. The problem here is that efforts often happen after patterns and implementations have been completed. That’s why accessibility fixing feels repetitive, and it is very, very hard for us to sustain.

I have a diagrammatic representation here of the accessibility fix cycle. This particular image illustrates that repeating accessibility fix cycle when teams keep identifying and fixing issues in a circular pattern. For example, a team might fix a modal after an audit happens because the focus was not trapped correctly, but if there was no shared accessible modal pattern that was implemented into the system, another team might build a similar new modal, and that issue keeps repeating. This becomes a repetitive cycle. This is where it feels frustrating for many teams, not because they do not care, but because the system keeps producing the same results over and over again.

Accessibility can sometimes feel very hard, and there might be some reasons for it. I wanted to cover a little bit on some of the reasons. The first one is it might feel expensive, because when issues are found later, teams have to go back, rework on the code that is already built, retest it, and sometimes, that code might already have been released. It feels expensive to go back, rework everything out, and then go back and release it. Second, it can also feel a little bit slow because accessibility is treated like an extra step rather than something that is part of your normal software development lifecycle.

Finally, it can feel unfinished because the same kind of issue often keep coming back from one release to the next, so the challenge here is not just the existence of the accessibility issue, it is the way many teams currently approach accessibility, which makes it feel like a reactive, or a repetitive, or difficult-to-sustain over time approach. I would want to give an example here. If a team discovers after the quality assurance has been performed that a form field is missing labels or a modal is not keyboard accessible, fixing it may involve changes to maybe the template, the styling. It would also need some testing, and also, maybe there’s a change in the interaction logic itself. This becomes much more expensive right there when you’re making those initial decisions.

Common Accessibility Issues. There are some of the most common accessibility issues that teams encounter again and again across many products. Missing accessible names means that buttons, icons, or any of the form controls may not be properly announced by the screen readers. Incorrect ARIA usage often happens when developers try to improve accessibility by adding more and more attributes, and that creates confusion instead of adding the clarity that the users require.

Keyboard navigation failures are especially important, because failures are especially important to fix because many users still rely on the keyboard rather than a mouse, and they will find it very, very hard to move to the UI if they don’t get the proper navigation. Color contrast violations can happen. That makes the content really, really hard to read, especially for users that have low vision or are using a screen in bright light. Missing form labels. They make it difficult for users to understand what the information is expected. Broken focus happens when they lose their place after an interaction, such as opening or closing of a modal.

An inaccessible modal are a very common example of a component that fail in multiple ways at once and is not able to maybe trap the right focus, or the announcements are not accurate, or that’s inaccurately stated. What happens here is that these bugs that we just went over, they are not something that is rare. They are a recurring pattern. They usually tell us that the issue is happening at the system level. For example, if a team builds a custom modal without proper focus management, and say another team comes, and they build a similar modal using the same approach, here, you already have repetition, and you have repeated the problem twice.

I would like to describe this as an accessibility debt. Many of us are already familiar with the idea of technical debt, shortcuts of design decisions that make systems harder to maintain over time, and developers are the ones who would generally suffer from any technical debt. Let’s take a look at accessibility debt. What is accessibility debt? It is similar to technical debt, but here, the users suffer. The cost is directly felt by our users. When accessibility is postponed, partially implemented, or repeatedly deprioritized, the result is that users encounter barriers in their everyday interaction. They may not be even able to complete, say, a form, or navigate through a menu, or understand a button, or stay oriented in a modal.

While technical debt slows us down, internally, accessibility debt creates that friction and exclusion for people using our product. This is why it is very, very important to treat accessibility issues as system quality issues, rather than just minor bugs or a compliance task check. I can also give an example here. Maybe there’s a team that decides to create a custom dropdown quickly, and they plan to fix the improvement for the keyboard support in a later release. This shortcut is going to help in saving time in the short term, but later, until it is fixed, the users who really rely on the keyboards or assistive technologies are the ones who are going to pay the cost because of this accessibility debt that we just discussed.

The Accessibility Challenge in Modern Frontend Systems. Modern frontend systems are working in environments which are far more complex than it used to be. Instead of having small set of static pages, teams are now building large applications with many moving parts. There are many contributors, and there are constant product requirement changes. Codebase grows massively over time, and different developers often work on many of the shared systems. In many places, components are also reused across multiple products, which means one accessibility issue can spread widely like a fire if they haven’t fixed it right from the beginning.

At the same time, teams are also under constant pressure for delivering features and meeting the delivery expectations. In that kind of environment, accessibility becomes inconsistent unless it is built into the system beforehand. This is really the challenge and reality, and I want to highlight that modern frontend work is not just about building pages. It is also about managing the complexity and allowing your accessibility to scale within that complexity.

Here, I have a diagram for the accessibility challenge in modern frontend systems. This diagram shows the kind of environment many teams, especially the frontend teams, that are working in today. You have multiple teams building features at the same exact time, often on top of a shared UI platform or a shared component library. That setup creates a lot of efficiency, but it also means that decisions have to be made in place because it can have a broader impact. If the shared platform provides strong, accessible patterns, many teams will benefit from this approach, but if there is an accessibility gap that exists in that shared layer, those problems are going to spread across products just as easily.

The challenge here is not only about individual developers making good decisions. It is also about whether these systems are helping teams build accessibility baked in from the start, or is it making it easier to fix problems than to multiply? Why accessibility approaches often fail to scale. Many teams would try to improve accessibility through training sessions and periodic audit. While these efforts are recognized, they are very important, they often don’t change how accessibility is implemented in day-to-day development.

Training would create the awareness, but developers still need to rely on tools, patterns, the components they have implemented, the way the shared system work, everything that is available to them while they are building those features. Audits tend to catch the issue after the code has already been written, which makes fixes more expensive and time-consuming because you would need to come back and fix the issues. As a result, teams often end up fixing the same repetitive issues again and again, and accessibility becomes treated as a compliance task, something to check maybe at the very end, rather than an engineering practice. Hence, we should always try to build it into the system from the beginning rather than coming back to it at the very end.

Accessibility as Architecture. This is the central idea of my talk today. We often think about accessibility as something that gets added during quality assurance, checked after audit, or fixed through an individual effort, but in practice, many accessibility outcomes are shaped much earlier, and they are led by architectural decisions. The way a component is designed, the way how focus is managed, how keyboard interactions work, what semantics are used by default, what patterns are shared across teams, all of these are architectural choices that we make. When these choices are accessible, teams can build accessible products more consistently, and that happens by default.

When they are not, the same accessibility issue would come back and repeat. When I say accessibility is architecture, I mean that accessibility is influenced by structure, defaults, systems we built into the frontend right from the beginning, not just something that we apply towards the very end. To understand why accessibility problems repeat, it helps to look at where accessibility decisions are actually made. They are influenced by component APIs, focus and state management, semantic structure, interaction patterns, and design system defaults. It is not about just adding some attributes of alt text or ARIA rules.

In reality, many outcomes are shaped by architectural decisions for accessibility. For example, a component manages focus, how keyboard interactions are implemented, and how state changes are announced through assistive technologies. If those behaviors are not very well designed correctly at the component level, every product that would inherit that component would face the same exact problem. In other words, accessibility is often determined by the architecture of the system, not just the effort of an individual developer.

I want to deep dive in all of these bullets a little bit. The first one is about component APIs and default semantics. A component API defines how developers use a component. If the API is very well defined, it encourages accessible usage automatically. Developers automatically build accessible interfaces without adding any extra attributes. The second one is about keyboard navigation patterns. Interactive components should support consistent keyboard patterns, so users who rely on keyboards can navigate and operate the interface seamlessly.

The next one is form labeling and validation. Forms should always include clear labels and accessible validation messages, so assistive technologies can correctly communicate the input requirements and errors back. The next one is focus management for modals and dynamic UI. When modals or dynamic interfaces appear, focus should move appropriately and return to the right place, so keyboard and screen reader users stay oriented. In the very end, I have navigation landmarks and heading structure. Landmarks and heading structure, the hierarchy provides structure to the page. That allows the screen reader to quickly understand the layout and navigate through the page efficiently.

Accessible architecture leads to accessible products. Making a single website accessible is challenging, but making an entire ecosystem accessible is even more difficult. This is where I want to shift our conversation and ask a question. How do we get an accessible, sustainable web? We want to move towards a system-level thinking approach. Maybe we can try a design system. Accessibility starts becoming scalable when shared systems carry the right behavior by default. What is a design system? A design system is a curated set of, maybe a set of components, patterns, or guidelines that help team build products faster and more consistently without reinventing the same UI solutions every single time.

Benefits of a design system. When teams share components and patterns across products, they also share accessibility behaviors, aligning with maybe some standards that are defined. If those components are built with accessibility in mind, developers can build accessible interfaces more easily. They don’t need to start anything from the scratch, but if those components contain accessibility issues, those issues will also be widespread. This is why design systems are such powerful leverage points for accessibility.

Instead of fixing issues repeatedly at the product level, we solve them once in the shared components so that any team that uses a shared component would benefit from those accessible patterns, and that would be used by default. I want to outline some main parts of the design system, and I also want to talk about a bonus part. Let’s talk about the main parts first. The first one is styles. Styles are nothing but rule sets for how components normally look, behave, or feel. For example, colors. The second one is components. Components are nothing but reusable, standardized– we can call them building blocks for digital user interfaces. Example, maybe a button or a dropdown.

Patterns are nothing but a set of components and best practices arranged to fulfill common functions. Example, maybe a payment details page that is created. The fourth important part of a design system is the influence, the team connections and collaboration with other group. For example, when you’re working on a design system, you need to align very well with the design team so that you can bake in the accessibility and have those about all the issues earlier.

Where are design systems the best? Design systems tend to work best in organizations where scale makes reusable valuable. When I say that, you should have multiple products that need that consistency across the board, and where we have design, engineering, and many other disciplines willing to collaborate easily and closely together. They also, I would say, require some level of investment. When I say investment, I mean it needs ownership, it needs maintenance, it needs adoption support. We shouldn’t think about design system just like a component library. We should think about it as an ongoing product that would need to be maintained for many years.

Design System Example. I have here an example of the Carbon Design System. It’s an open-source one. I like to think of design system nothing more like a construction kit, I would say. The primitives are the building blocks. The APIs describe how to use them. The semantics give the meaning, and patterns define how those pieces work together. In conclusion, I would measure a design system by its ability to help diverse products and teams.

I want to move our conversation to shift left accessibility. Before we get into shift left, I would like to talk about the traditional workflow that we have. Traditionally, accessibility has always been evaluated near the end of a development process. Towards the end, after you have implemented all the products, maybe you are doing a quality assurance test, or you are auditing, or you are just going to release it, you try to do a test on accessibility, but it’s already late in the game. That means the accessibility problems are discovered after the features have already been implemented.

Shift left accessibility. This means moving accessibility earlier in the development cycle instead of waiting until the very end to evaluate it. If you remember in the previous slide, we saw that we are testing accessibility later, but in shift left approach, we are going to move accessibility in the beginning of our development, where we’ll be having those earlier conversations rather than later. In many teams, accessibility is still treated as something maybe that is checked at the very end, but this is the thought that needs to change. The problem with that approach is that many of the important design decisions or the implementation decisions have already been made.

With a shift left approach, we try to prevent those problems earlier by considering accessibility during the design, component development, feature development phases, and then closing the loop with an automated testing. The goal here is not just to catch issues sooner, but to reduce the number of issues that reappear again and again. When accessibility is introduced earlier, teams spend less time fixing repeated bugs later, and they have more time building accessible behavior and repeating it by making it default into the system. Now we will discuss on a high level each component in this lifecycle in our upcoming slides.

The first one is design stage. A lot of accessibility decisions begin much earlier than implementation, and it would be in the design stage. It is one of the most important places to shape good outcomes. At this point, teams should not only think about how an interface look, but also how it behaves. Defining focus order means deciding where keyboard focus should move as users interact with your interface, so navigation feels more logical and predictable. Keyboard interactions are also important to define early, especially for dropdowns, because those interactions need to work without a mouse.

The next one is about color contrast. It is another foundational decision. If contrast is not built into the design tokens, palettes, or the visual choices early on, it becomes much harder to fix later without really redesigning the entire interface. The design stage is not just about visuals. It is also about many accessibility expectations that we need to do before we even get to the development stage.

The next slide talks about component development. Component development is where accessibility starts becoming repeatable. Instead of expecting every product team to solve accessibility issues from the scratch, we can build it into a reusable component that teams can rely on every single day of their development. For example, an accessible form field component can include the right label associations. It can have the help text, the error messaging, the validation behavior all set by default, so that teams can come and consume it.

We can take another example of maybe an accessible dialogue component that can handle focus management, keyboard support, screen reader announcement in a very consistent way. Another would be about, say, an accessible menu or a dropdown that can provide predictable keyboard interaction and proper semantics without each team re-implementing those patterns directly. The value here is not just about the components being reusable. It is about the accessible behavior being reusable, too. That reduces repetitive bugs, it improves the consistency, and it makes it easier for many teams to build accessible products under normal delivery pressure.

The Developer Experience. A key part of scaling accessibility is also making it easier for our developers to do the right thing. We want to bake it in the normal workflow. Most developers may not know everything about the ARIA expertise, and they might be coding and building those patterns incorrectly without their knowledge. We don’t want them to stress out on this. We want them to make their lives easier, and we want to bake it right in from the start so developers feel confident. This kind of knowledge is valuable because it would also not create a dependency for building accessible products at scale, but it will also help them understand how accessibility plays in.

I would stress that instead of developers relying on only shared components and patterns, they can also focus on handling the complex part well. In other word, a good developer experience means accessibility supported by the system, and not just relying on a certain developer remembering the rule and working on it. When teams have accessible components, they have clear documentation, they have examples to follow, accessibility becomes much more of a practical and easier step to adopt rather than a burden.

Automation. Automation is a very important part of making accessibility sustained in modern frontend teams. Once one accessible pattern has been introduced into the components, automated checks can help reinforce those expectations during development. Accessibility tests can catch issues like missing ARIA, missing labels, or improper roles, or color contrast issues, much earlier than a formal audit. Continuous Integration checks add another layer by adding accessibility part of normal engineering workflow, rather than something the teams would need to test on their own at the very single end.

The goal here is to not replace human judgment, because automated testing is not going to catch every single thing, but it is to create a fast and consistent feedback that helps teams catch common issues early. When automation is part of the workflow, accessibility becomes more visible, more repetitive, and less dependent on last-minute reviews, so that we can get the issues fixed earlier. This way, accessibility is tested on every single pull request before the development is merged, and also, it becomes a continuous feedback, which helps teams catch these issues early and reduce the repetitive fix later.

Release. At the release stage, the goal is not to discover any major accessibility issues for the very first time. At this point, accessibility should already have been considered in design, in building the shared components, supported during feature development, reinforced when you were doing the automation testing. That does not mean that release is irrelevant. It is still an important checkpoint, but the role of the release has changed here a little bit. Now it is more about confirming that your system is working as expected rather than catching avoidable issues at the very last minute.

When teams reach the release stage with this kind of workflow in place, accessibility becomes more predictable, and it is much easier to sustain over time because you would have handled it at the very beginning of your cycle. Leadership Responsibility. I want to talk about the leadership responsibility here a bit. Here, leadership plays a very, very important role in making accessibility sustained over time. In most cases, accessibility does not fail because a certain developer or developers or teams do not care. It fails because teams do not have the systems, patterns, the support, or tool that they need to implement it consistently.

This is why leadership matters. A good leadership is not about enforcing rules at the end or relying only on audits or workshops. Yes, training has to be provided. It is helpful, but training alone does not change the system that developers work with every single day. Systems would change the behavior. If teams are given the clear component patterns, the practical documentation, the accessible examples, the accessibility checks, tools, everything is built in the normal workflows, then they are much more likely to build accessible products consistently. The role of a leadership here is to really create that environment, where accessibility is enabled by default rather than depending on any individual effort alone.

What good leadership looks like. Good accessibility leadership is not about reviewing every screen manually or acting as a gatekeeper at the very end of the process. It is also about creating those conditions that can help team succeed consistently. That starts with defining clear accessibility standards, so teams know what good looks like and do not have to interpret everything on their own. It also means defining shared component patterns, because patterns help teams solve common interaction problems in a very consistent and reusable way. Leaders should also enable teams with documentation examples and tools, so accessibility feels more supported than a mystery or a burden.

Integrated accessibility checks have to be added into the continuous– has to be continuously evaluated. It is another important step because it makes accessibility pattern part of the normal engineering practice for every day-to-day development. Finally, a good leadership encourages a culture where accessibility is treated as part of the quality and product thinking, not just as a compliance requirement. In other words, I would summarize that leadership helps move accessibility from being development on individual heroics, to being supported by an entire system.

Here, I have a diagram that shows driving adoption without slowing down delivery. One concern maybe some of us or some other teams would have, is often, accessibility will make them slow, and they will bring development to a slowdown. That can happen if accessibility is treated as an extra work and added late in the game. It causes a lot of rework, but adoption means it becomes much easier when teams are supported with the right systems right from the beginning. If we provide clear patterns, developers do not have to guess how a menu, or a modal, or a form field should behave.

If we have automated accessibility checks, they will help us catch those common issues early, before they become expensive later. Documenting accessible examples is very important. I do want to stress on that, because many teams would want that documentation so that they can learn from it. This would reduce the inconsistency across products. Finally, also about the support. Supporting developers with tools that makes accessibility feels like part of the workflow is also very important, rather than having it as a separate task to be fulfilled. The goal here is not to slow down teams with more rules, but it is more about accessible implementation that feels the easiest and most natural path to follow.

Measuring Success. Success in accessibility should not be measured only by whether a product passes compliance check. A better way to look at it is to see whether accessibility regressions are decreasing over time. We can ask the question whether teams are using these shared accessible components and patterns, and whether the overall usability of the product that we have developed is increasing. There are strong signals that accessibility is becoming part of an engineering system rather than something checked at the very end.

The same idea applies to leadership. The goal here is to not police every single decision by becoming an accessibility gatekeeper, but to create those accessible defaults that will help team do the right thing consistently from the start. If we are able to bake it into our systems, it becomes something that all the teams would use it rather than something we have to keep correcting at the very end.

Practical steps your team can take next week. I wanted to outline a set of practical steps because not every team is starting from the same place. This kind of changes does not fall at place all at once. Some of the steps here are the first good step I can think about is to audit the most– the UI components your team or you use very often, because those tend to have the biggest impact across products and workflows. From there, we can look at recurring accessibility issues. The problems that show up again and again, like missing labels, broken focus, or maybe a weak keyboard support. Once those patterns are clear, the next step is to create the accessible version of that component, so we do not repeat the same problem in different places.

Documenting those accessible pattern is important because teams need to have a clear example of what they can trust and what they can reuse. Finally, we can add automated accessibility checks where possible, so that these improvements are reinforced over time. The overall idea is to start small, focus on what is repeated and where we can correct, and then we can build accessibility into those shared components and work on those systems first.

This really brings it all together with the main message of the talk. Accessibility must scale with frontend systems. Modern frontend systems are built with shared components, multiple contributors, and fast-moving product cycles. Accessibility has to scale in the same way those systems scale. If accessibility depends only on individuals remembering every single guideline or catching every issue manually, it becomes fragile and it becomes inconsistent. Some teams may do it well, while others may miss important details. That same problem keeps repeating. As we saw, many teams might use the same codebase. If we are unaware about an accessibility behavior or a pattern, we might create that for other teams.

When we talk about accessibility, it has to be baked into the architecture of the frontend through design system, through maybe a reusable component, through a shared pattern, and even into the development workflows, like we saw in the shift left. It becomes much easier to support consistency across products and teams in that way. At this point, accessibility is no longer just a task to remember. It becomes part of how your system works. This is what makes accessibility more sustainable over a long period of time.

The key message of this session is that accessibility outcomes are shaped by the systems we build, not just by individual effort. Architecture influences how accessible interactions are implemented. Component systems help prevent the same issues repeating. Design systems make accessible patterns easier to adopt and reuse by default. Leadership would play a very, very important role by creating those standards, supporting the teams, supporting documentation and workflows that help adopting accessibility consistently very, very easy for anybody.

Accessibility scales when it becomes a system. I like this quote. “If a block is inaccessible, thousands of websites inherit that problem.” It connects directly to the point I was trying to make earlier. In large ecosystems, a single component decision can affect thousands of websites and millions of users. That’s why we cannot rely on individual developers remembering every single rule. It is very important for us to build it into the architecture and systems that we share.

Thank you for being here. I hope this talk offered a useful way to think about accessibility and not just as a checklist. I would like to ask if there are any questions that we would want to discuss. Thank you, everybody.

>> AMBER HINDS: Thank you, Niharika. I really appreciated this talk, especially that final conversation point about the block, because that goes back to what I’ve been saying about how important it is to choose your plugins or your themes for WordPress websites, because if whatever you start from is inaccessible, then whatever content you’ll add into it will never be. If anyone has questions, please do put them in the Q&A. I wrote down a couple while you were talking.

I am curious, you talked a little bit about automated testing. I’m wondering, from a dev standpoint, trying to get that as early in the process is really important. Are there any linters that you recommend or you have found that work well for doing automated accessibility testing on code, either in a developer’s IDE or maybe on GitHub pull requests?

>> NIHARIKA PUJARI: Yes. That’s a good question. I would say, as far as linters are considered, I have worked on Angular projects in my past as pet projects. That is one of the things that I have been using ESLint for. While creating pull requests, some of the things that I have used is Axe testing, the open source one. I’ve also incorporated those Axe testing in every pull request as a GitHub check, so that whenever I run my project, it goes through those Axe testing and it highlights the violations, if there are any, with that pull request. It would tell you exactly where those issues are. The check would exactly fail and let you know that you have these many violations.

Once those violations are fulfilled and they are corrected, you will be able to launch your PR. That’s how I have been incorporating those accessibility checks in my GitHub pull requests for my projects.

>> AMBER HINDS: The Axe integration for GitHub is free if it’s a public repository. Is that right?

>> NIHARIKA PUJARI: Yes. I think there’s a free version of it. I might have to check that, but the one that I used had a free version to it. I was able to add it as part of a plugin in my ID. Plus, I was able to integrate it with my project, and I was able to run it as part of my code. I could test it in my local development first and then bring it up to GitHub as well as a necessary check. One of the project that I was working with my friends is we have multiple UI developers who contribute to the same repository.

It’s not like everybody of us will run accessibility checks for every single time when we develop, so we wanted to add that automated check as part of our CI/CD, so that whenever somebody is creating that pull request, and before it goes into the main branch, we are running those checks just to ensure that the main code is protected.

>> AMBER HINDS: Yes, that makes sense. We’ve been doing a lot of that kind of stuff on ours as well. I know the one AI that I found that actually has somewhat decent accessibility feedback is CodeRabbit. I don’t know if you’ve tried that, but that one also does–

>> NIHARIKA PUJARI: I–

>> AMBER HINDS: Gemini does some, but I don’t feel like their accessibility feedback is as helpful.

>> NIHARIKA PUJARI: Okay. CodeRabbit. I haven’t tried that, but I would give it a try, for sure.

>> AMBER HINDS: Yes.

>> NIHARIKA PUJARI: Awesome.

>> AMBER HINDS: Adam had a question. Going back to your slide, where you said all developers don’t need to have deep ARIA knowledge, Adam’s curious why developers shouldn’t need ARIA knowledge. He says it seems like equipping them, as well as leadership, is crucial to sustainable accessibility success.

>> NIHARIKA PUJARI: I think that’s a good point. The reason I mentioned that is because many times, there are new developers who are right out of college and do not have that accessibility knowledge that you get by experience. Many times, when you are giving accessibility, as, say, you are baking it and you’re trying to give them those training sessions, they feel overwhelmed. We have to make them understand that accessibility grows with you, it grows with your experience, and you do not need to know everything, every rule by heart. It is a growing experience that you will get.

You have to start with making sure that the leadership provides you those trainings, it gives you those ARIA knowledge that you need for beginning, but then you take it up for more or less about– yes, it’s about judging the level of the developer, and then equipping them with the level that they will need to grow into. I guess we want to make sure that the developer experience is seamless. They don’t get overwhelmed, but at the same time, they do understand that it is experience that is going to get you to a level of expertise for accessibility.

>> AMBER HINDS: Great. That totally makes sense. I think over time, we hope to get them to learn ARIA, but it doesn’t mean they can’t start with accessibility, even if they don’t know it.

>> NIHARIKA PUJARI: Yes. That is where the curiosity in the developers should rise, right? They would start with the pattern, they would understand it, and later, when they come back to it, it’s already a known pattern. That way, your experience will multiply over time.

>> AMBER HINDS: One of the questions that I had when you were talking about measuring success, and I love that you say it’s not just about WCAG compliance, it’s about actual accessibility in practice, and the fewer regressions, are components being adopted? Is there overall better usability? I also see this from a leadership perspective. There’s this question of how do we measure that? Because they always want to have some KPI that’s tied to a number and a smart goal, and all of that kind of thing. Do you have any thoughts about how you measure that better usability, and this thing beyond WCAG?

>> NIHARIKA PUJARI: I would say that maybe a practical example would be that amount of regressions that you get. If your count of regressions, say, for a product, was about 50, and you brought it down to just 10, that’s a KPI that you can look at. Also, I would say that when it becomes a leadership responsibility, if you have the right documentations, the amount of questions or the amount of rework that is needed at the very end is minimal. You will save a lot of time at the very end, and maybe you can check the amount of development you do at the very end when there’s an audit.

If you’re preparing for an audit, and right before the audit, you did a big release, and everything looked good, there was minimal regressions, and there was minimal work that was needed from your end, you know that you did a great job, and the leadership just flow in. If you were in a panic mode after the release just before an audit, and you are everywhere, that would be an indicator that maybe the influence was not consistent, or the influence did not flow in correctly. If you ask me if there’s a measure how you could see it, I would say that it is the number of rework or the pull requests that you would have created to fix your system to be at that point. If I see like 20 fixed pull requests, I would be like, “Oh, wait, maybe something is not that [unintelligible 00:59:06].”[laughter]

>> AMBER HINDS: That’s a good way to put a number on it. Evelyn says, with our design system, there’s tension between wanting it to be flexible and not overly opinionated and wanting devs using the components to not have to do extra work to ensure accessibility. How do you balance that?

>> NIHARIKA PUJARI: I think I have a little bit of an opinion for design systems. First of all, not every team needs a design system. There are different ways to perceive a design system. The flexibility part of it comes from the design team itself, the way the design team has envisioned the design system or what your vision is. Many small teams, they can work out based on custom components that they can create in their particular repository, and call it their own design system to be more flexible according to the product that they are serving to.

If you’re creating a design system that is maybe on a brighter level, like an open-source one, you want to target the most generic UI patterns. When flexibility is baked in, I would say that maybe starting in a product level is easier, so that that gives you the maximum flexibility for that system, and you can have a design– You can maybe have a component library within your project. That project, if it scales to a very high level, you can think about having it as its own repository or bringing the vision of it to be its own design system.

There are many ways to perceive it. There’s no hard or fast written rule that, okay, your team is doing this, you need a design system. It depends on every requirement that your product is trying to solve for. Accordingly, you can take the call.

>> AMBER HINDS: That totally makes sense. Thank you so much, Niharika, for speaking with us. Can you tell everyone where they can get in contact with you if they want to follow?

>> NIHARIKA PUJARI: Of course. I’m available on LinkedIn. Maybe I can quickly share my screen again and bring back the barcode.

>> AMBER HINDS: Are you able to?

>> NIHARIKA PUJARI: Yes. I have this, I don’t know why it’s not working, but– Okay, yes, here we go. I have this LinkedIn right here, the barcode, please add me on LinkedIn. I’m happy to take more questions if you have. Directly shoot them up in LinkedIn. I will also share the slides with the organizers, so if you have anything, you can take a look at that. Thank you so much for being here today. I hope this helped everybody to get a different perspective. Thank you so much, Amber and Paula, for having me here. It was really great meeting all these folks.

I look forward to attending more sessions for the meetup.

>> AMBER HINDS: Yes, thank you so much. We’ll be back here in two weeks for a presentation on the European Accessibility Act. I hope everyone has a wonderful day.

>> NIHARIKA PUJARI: Thank you.

>> [01:02:05] [END OF AUDIO]

Access “Scaling Accessibility: Treating Accessibility as Frontend Architecture and a Leadership Responsibility” Google Slides.