Summary
Centralizing design and engineering help organizations build better digital services. Fragmented experiences often occur when teams solve the same problems in isolation. This leads to visual and functional inconsistencies that frustrate users and waste resources. By using a shared library of accessible components, teams can work more efficiently. This approach ensures that inclusion is built into every digital interaction from the start, including those working for state governments like the State of New York as this is based on their experience.
This article is based on a presentation at Accessibility New York City (A11yNYC) by Jesse Gardner.
Modern digital services for state and local governments often feel disconnected because they are built by different teams using various platforms. A resident might start their journey on a search engine, land on a primary website, and then move to a separate system to log in or submit an application.
Jesse Gardner is Director of Accessibility and Design Systems at the New York State Office of Information Technology Services, where his teams serve more than 45 state agencies and 20 million New Yorkers. They know each of these steps might have a different look and feel. As a result, this can create a fragmented experience, increasing the effort required for a user to complete a task.
When the design and language shift constantly, it adds to the cognitive load of the person using the service. This does more than confuse. It can actively erode trust in the organization providing the service. If a person finds a digital interface difficult to navigate, they may give up and choose more expensive or time-consuming methods, such as calling a service center.
This fragmentation is rarely intentional. Most teams are passionate about their work but operate within narrow contexts. They face unique business logic, policy requirements, and limited time or expertise.
Because technology changes rapidly, it is difficult for every individual developer to stay current on every best practice. This leads teams within the same organization to solve the same basic problems repeatedly.
Building inclusion into the technical foundation
True digital inclusion requires deep technical work that goes beyond visual design. While many people focus on how a website looks, it is equally important to consider how a person using a screen reader or keyboard navigation experiences it. For example, a button must not only be visible but also selectable via a keyboard and properly announced by assistive technology.
Many organizations expect developers to be experts in multiple programming languages and frameworks simultaneously. They may not have the specialized knowledge required to implement complex accessibility standards. A centralized team of experts can help bridge this gap. By focusing on both design and engineering, organizations can ensure they address technical considerations before a product reaches the user.
Moving accessibility testing earlier in the development process is a more cost-effective strategy than fixing issues after a product has launched. Manual testing of top workflows helps identify major issues and provides practical solutions for engineering teams. This collaborative approach builds rapport and helps grow the overall maturity of various teams within a large organization.
Capitalizing on a centralized design system
A design system like New York State Design System is a collection of shared components, standards, and guidelines that help teams build usable applications quickly. It typically includes a code library, a prototyping library, and a reference site for documentation. These tools work together to ensure that every digital product is mobile-friendly and accessible.
The code library contains interface elements like buttons, toggles, and accordions that have been thoroughly tested for focus management and screen reader support. These components come with accessible defaults built in. When an engineer uses a component from the library, they do not have to wire up the accessibility themselves. This approach encourages adoption by making the developer’s job easier while ensuring a high-quality result.
Design tokens are another critical part of this foundation. They are small, semantically meaningful choices for things like colors and spacing. For instance, a specific “danger” color for error messages can be pre-tested for contrast. Even if a team cannot use a full component library, they can still use these building blocks to ensure their custom designs meet basic inclusion standards.
Driving adoption through practical solutions
The key to a successful design system is making it the path of least resistance for teams. Most people visit a design system reference site because they need to build a page or ship a service, not necessarily to study accessibility. By providing ready-to-use code and “quick wins,” the system solves the attendance problem.
Once teams are using the system, accessibility information can be placed directly in their workflow. Component pages can include checklists for behavior, interactivity, and color contrast. This allows designers and engineers to learn about inclusive practices as they work. Over time, this builds a culture where accessibility is seen as a core part of the development process rather than an afterthought.
For teams working on legacy systems that cannot migrate to a new library, providing “build accessible” guidance is essential. This includes showing how to achieve the same results using native HTML elements and specific CSS. Offering multiple ways to reach a goal ensures that more of the organization can benefit from the centralized team’s work, regardless of their technical constraints.
The impact of shared standards
Standardizing digital tools creates a consistent interaction experience for everyone. While not every website needs to look identical, the way a person interacts with a form or a menu should be predictable. This consistency reduces friction and makes it easier for people to get the help they need from their government or organization.
Focusing on the user journey and scaling technical solutions allows organizations to meet compliance deadlines while improving overall usability. When the light bulb goes off for an engineer and they understand why landmarks or header orders matter, the quality of everything they build improves. A design system codifies these best practices, making them available to everyone.
What organizations can do next
- Establish a centralized team of experts to create and maintain a shared library of accessible components.
- Conduct manual accessibility testing on the most common user workflows to identify and prioritize the most significant barriers.
- Provide engineers with clear, plain-language guidance that explains both how to fix an issue and the human impact of that issue.
- Use design tokens for colors and fonts to ensure that even custom-built elements meet basic contrast and brand standards.
- Create a reference website that offers copy-and-paste code examples to make it easy for teams to adopt accessible patterns.
Fostering a culture of dependability
Scaling accessibility is a long-term commitment that requires both technical tools and cultural shifts. By providing high-quality solutions that make life easier for developers, organizations can naturally drive the adoption of inclusive practices. This approach moves away from a model of policing and toward a model of empowerment.
Ultimately, these efforts are about ensuring that every individual can navigate digital services with dignity and autonomy. When accessibility is baked into the foundation of a design system, it becomes a natural part of every project. This quiet dependability creates a more inclusive digital world for all users.
Resources
- New York State Design System
- NYS Technology Law (STL §103-d) – New York State
- WCAG 2.2 AA Standards
- U.S. Web Design System (USWDS)
- NYS design system Figma community file
Video highlights
- How fragmentation occurs
- Learning from a simple button
- What prevents inclusive experiences?
- Delivering accessible experiences at scale
- Supporting engineers
- Q&A with Jesse
Watch the presentation
Bio
Jesse Gardner is Director of Accessibility and Design Systems at the New York State Office of Information Technology Services, where he leads two teams serving more than 45 state agencies and 20 million New Yorkers. He built the New York State Design System from scratch and led the state’s response to the DOJ Title II accessibility compliance deadline (recently extended to April 2027).
Before joining the public sector, Jesse spent more than two decades in software engineering and design leadership. He speaks regularly on the intersection of design systems, accessibility, and AI (most recently at Into Design Systems 2026) and writes at plasticmind.com. He lives in upstate New York with his wife and four kids.
FAQ
How do you handle incremental adoption and the evolution of components in a design system?
Components should be built to be extensible, allowing teams to use CSS overrides for specific needs like background colors. A versioning strategy, such as using a package manager like NPM, allows teams to update their library at their own pace without worrying about sudden, breaking changes.
Is it possible to use the accessibility features of a design system if my organization has its own branding?
Yes, if the system is open source, other actors can brand it to fit their needs. Organizations can override color themes in tools like Figma while still benefiting from the underlying accessibility work built into the components.
How can I make digital pages more accessible if I don’t have control over the underlying system components?
Starting with basics like avoiding unnecessary PDFs and pictures is a great first step. You can also focus on high contrast for text and buttons. Using manual testing with a screen reader to hear what is actually announced on the page can help identify bad experiences that automated scanners might miss.
What is the best way to deal with resistance to changing established workflows across different agencies?
Compliance deadlines can be a strong motivator for change. It is helpful to lead with user needs and be as pragmatic as possible when suggesting fixes. Empowering teams with a better understanding of accessibility through training and clear guidance helps move the conversation from simple compliance to making services work better for everyone.
How do you measure whether a design system is improving the user experience?
Adoption can be tracked in both design and engineering workflows. Beyond technical adoption, organizations should conduct user research to test how these patterns work in real-world scenarios. Codifying successful patterns into the design system ensures that even projects with limited funding can benefit from proven, high-quality user research.
