How To Scale Digital Accessibility With Design Systems

I am Jesse Gardner. I'm glad that you are all here today. I really appreciate you being here. I started at the State about three years ago.

I started doing web design way before that in the 90s when we were using Photoshop and trueSpace and HoTMetaL and all of those all of those antique tools and I actually started as a designer and over time I got frustrated because I kept having developers tell me that you couldn't do something and I said well what can you do and I wanted to learn more about engineering so over the course of the 2010s I began to or 2000s I began to learn how to do engineering and so over the course of probably 20 plus years or so I focused a lot on engineering and ended up doing engineering at large organizations and then coming along Coming back to New York State three years ago, I got connected with Luke Chard, who heads up the Human Center design team.

We have a number of folks here from our team, so kudos to them for joining. But Luke and I met, and one of the things that impressed me was that Luke and his team, they were doing tons of amazing work around sense-making and design and user research, and really trying to make sense of what can often be a pretty messy process in government. But one of the things that I saw there that I see in a lot of organizations was the handoff between design to engineering.

Often there's a lot of friction there, or there was missing intent where something that was designed got handed off to developers, and it just didn't end up being what the designers had envisioned. And so, I figured this would be a really great opportunity to bring the engineering and the design together. And so pretty early on, I really wanted to focus on that. So design systems is a part of that.

I'm going to be talking about that a little bit tonight. I oversee a design system team. Don't worry if you don't know what design systems are, we'll talk about it. But accessibility is another interesting part as well.

Because accessibility, especially when you talk about digital accessibility, has a design aspect to it, because it's about the customer experience. Accessibility really is a subset of usability. But then there's also some technical parts that are really important to understand, but are often missing from engineers that do a lot of the building. And so our human-centered design team focuses on everything from user research to accessibility, accessibility to design systems.

And so I'm going to cover some of that today. I want to actually start with the 2024 State of the State. Back in 2024, the leadership of New York State committed to creating a centralized design system, backed by a dedicated team, which is somewhat unusual. And this was meant to serve as a foundation for better experiences for digital services across the state.

But what does that actually mean? What does design systems actually mean? I've talked to a lot of different people, and different people have different ideas of what that means. But before I get to that, you know, we're the human-centered design team, so I think it's probably best if we actually start from the perspective of the journey of a resident.

So if you think about one of the more common journeys for a New York State resident, they're searching for help with some government service, right? And they land on an ny.gov website. And they click around the site. They're looking for information.

Probably looking for an application or to do something related to a service, a government service. And, you know, a lot of the times they're complex applications. There's a lot of questions. There's a lot of caveats and language.

And so they might have to log in, but they maybe need to create a new account or maybe they need to remember which one they logged in with or what their password is. And that can be really frustrating. But what's interesting is a resident goes through this whole process and they don't really have any idea that behind the scenes they're actually using a whole bunch of different systems, right? You're on Google and then you land on maybe one site that's being served up by one system and then you have to log in, which that login screen is being served by another system.

And so you're going through all of this and it's different platforms, different teams that are managing this. But to the user, to the resident, it doesn't matter, right? They don't really care about what they care about is I need to pay my sales tax. I need to renew my barber's license.

I need to whatever. And so they have a goal. Can they accomplish it or is it going to be a headache? And so, you know, if you what I have on screen is actually like a snapshot of those visual experiences along the way on that video that I just showed.

And so if you look at this kind of holistically, when the design, the language, the experience all shifts from one step to the next and ends up creating kind of a fragmented experience. I know I'm probably preaching to the choir. If you're a New Yorker, you I'm sure have experienced this. And it adds a bit to the cognitive load for a user.

But it doesn't just confuse them. It actually can impact their trust in the services. Can I actually get what I need? Or is it just easier for me to call into a call center?

Or go to like a local office? Now I want to be clear. I always try to be very gracious, you know, when working with teams. I haven't met anybody yet that wants to build a frustrating experience for users.

Most people are driven and passionate for what they do. But this kind of fragmentation happens because what happens is you have teams that are solving the same problems over and over again in a narrow context. Right? They have their own business logic that they have to think about.

They have policies that they're beholden to. Agency stakeholders that they're working with. They have limited time. Limited capacity.

Limited expertise. You know, technology changes so much sometimes it's hard to keep up. And you knew dot net and suddenly it's rust. Right?

And so it can be frustrating when things are changing so much. So again, this isn't to blame anybody. I like to show this image. This is a snapshot of about 30 or so people.

So different New York State buttons. You know, when you take something as simple as this humble button, we visited a few dozen New York State sites and applications and found as many different buttons. So different styles. Different text treatments.

Different padding. Different colors. Different capitalization. Some have icons.

Some have shadows. So there's just a vast difference in how these things are treated. And you know, one thing that you might not be thinking about, but certainly from like a leadership perspective, each one of these buttons took time to design it, to code it, to test it out. So even if every one of those buttons just represents one day's worth of work, we're talking a month.

That's a month worth of work right there. And that's just one component. And so the question is, do we really need to spend that much time on a component?

On the screen I've got six different screenshots across different New York State sites. New York State government websites. But keep in mind, New York State has hundreds of websites. Probably more than that, but hundreds.

And if you multiply the story of the button across all of these different form elements and platforms and websites or applications and agencies, what ends up happening is we're not just creating inconsistent experiences for users. Time gets wasted because developers are solving those same problems over and over again. The quality ends up suffering. Because people have to try to come to terms with the different experiences that they're coming across.

And ultimately we're making it harder for New Yorkers to get what they need. Now there's another wrinkle that some of you may have picked up on. And that is, when I showed those buttons, we're all focused on the visual, right? But the differences that you see in those slides, they're primarily visual.

But how does a blind or low vision user experience those buttons? Does... You know, when they press tab on their keyboard, can they select each of those buttons? What gets announced to the screen reader when they actually select it?

And so there's a lot of accessibility considerations that often, like, are even forgotten more than the visual inconsistencies. Now again, to repeat, nobody is intentionally non-inclusive. Or at least it's been my experience. Most of the time, the challenge is that there are important technical considerations to making something accessible.

And really just making something inclusive for those audiences. And the people that are creating them just aren't aware of that. You'll have somebody that's a full stack developer. And what that means is at one point they learned PHP.

And they really don't know the accessibility part of this, right? And so again, I'm not casting aspersions on that. That's a very necessary skill set to have for certain things. But sometimes developers are asked to do a lot.

And so part of what we... part of the goal of creating this accessibility team was really to help New Yorkers overall. And so I want to reiterate, like, when we started this team, I told this to everybody that I spoke with at the state. You know, there's a lot of good accessibility work that's happening at the state.

But there wasn't a central effort to standardize that as much as we could. As a matter of fact, there was a really strong team at DMV. That was answering a lot of the questions from the other agencies. So when we told them we were going to stand up a central team, they were, thank you.

They had their own work to focus on. And so we've got this fantastic cross-discipline team of designers, engineers, people who have accessibility experience. We focus on websites and web applications and web content. We are the different teams, partners, and digital accessibility.

And I want to just take a minute to shout out to the team, because, you know, they've done a lot of work. Michele Bruno is our team lead. Logan, who's sitting here, he's one of our accessibility specialists. Mo is out on, he has a new baby, so he's out on parental leave.

Ethan joins us. So he is here today. Shamia, William, Sophia is here tonight as well. And Aaron, some of you might know, Aaron's here in the front row.

And so this is our amazing group of accessibility experts who have been doing fantastic work.

Now, I just wanted to point something out here. So understanding our users' needs, we are part of the human-centered design team, so that is our focus. We focus by, we start by focusing on the needs of the users that we work with. And, you know, and again, I said it, accessibility is an extension of usability.

But specifically considering these different needs, we make sure that we focus on this. And I think I had a typo in here. I think I had deaf or hearing impairments having, maybe it was audio description, then that probably would belong somewhere else. There's another thing, another reason that motivated us.

And I realized when I was putting this together, some of you, if you don't work with government, this may be more of a foreign concept for you, but there is a DOJ ruling that actually said there was like a compliance deadline that was April 24th, 2026 that got extended a year. And that's something that is top of mind for a lot of our agencies. What do we have to do? What's important to us?

And the answer to that question is very complicated. We'll talk a little bit about how we answer it. And there's also a state technology law, January 1st, 2027. So part of what our team is doing is we come along to that, alongside of the team and we say, focus on WCAG 2.2 AA.

Is everyone familiar with WCAG? Okay. All right. So, yeah.

So part of WCAG can feel very overwhelming for people who aren't familiar with it. And so part of what we do is we say, is this hard for you to wrap your mind around? Let's translate it in a way that's a little bit easier for you to understand. And so I'll give you some examples of how we do that.

But it's important to say that we kind of have the short-term goal to focus on manual accessibility testing. So when our team started, one of the things that we did, let me sit for a minute, one of the things that we did was we started doing manual accessibility testing and we basically met with all of the agencies and we said, give us your top public-facing workflows and we're going to go do manual testing on them.

And we did that for a couple of reasons. Number one, new team, new process. We're trying to figure stuff out. We wanted to get them familiar with the tools and the process.

We wanted to get them familiar with the state of ny.gov. Because that in and of itself is learning what's out there. We also wanted to be able to identify some of the big issues and start to get a clearer sense of like how can we provide solutions to these practical solutions to these problems. The other thing is we really wanted to find the people that were doing the engineering work.

Wanted to build that relationship with them so that we could see what the real needs were. Not just come in and preach, but come alongside and listen and say, what are the things you're struggling with? And that really helped build rapport because one of the things long-term that we're trying to do is there are hundreds of thousands of employees of New York State. At our agency alone, we've got more than 4,000.

Our team is seven. So part of what we're trying to do is grow the maturity of the teams that we work with. And so that's been a big part of our MO as we work. So one of the things that we do is accessibility testing guidance.

This is really an accessibility testing service that we provide for the various agencies. And our team goes in and does manual and automated accessibility tests. They compile a full list of issues, organized priority. And so there's a report.

There's a screenshot of a report dashboard there with a list of a whole bunch of those issues. But is anybody here an engineer, done engineering work? Okay. I don't know about you, but I always hated getting the really long spreadsheet of all the failures and needing to work through that.

And so as a result of that, and it's helpful, right? It's helpful to have that list. And we have issue details where you can go in and see what was the selector, what was the actual WCAG violation. But then we also create a deck that is specific engineering guidance.

And we actually treat that like a training session. We actually say, this is for you. And the product leader will get on and the business lead will often get on. But we'll say, this is for you, engineers.

This is a safe space for you to ask us questions. Because we want to make sure that they don't, we don't just, here's what to do. And they do it. We want to have them understand.

And so you can maybe make out, I have a screenshot of one of our slides. It's a little small, but it says, we kind of give it a little name at the top. Tab order is not following logical focus order. And then under that, we say, use your experience.

We try to explain in plain language. This is the impact it's going to have on the person that's using it. So we're building some empathy. We're helping to explain why this matters, not just like make this change in the code.

And then we have recommendations where we say, this is practically how you're actually going to, make this change and do this work.

Again, the main goal of this is because some of you have seen this before, but testing is expensive. And if we can move it backwards to where we are doing it earlier and earlier in the process, the better off we are. And this is going to tie into our design system focus in just a moment. A couple of other things I just want to praise our team for.

We've been doing bi-weekly accessibility office hours. Helps our teams. Have a greater reach. Helps to build tremendous culture.

Just this last office hours. I think one of the questions was, you know, what are you doing for the summer or something like that. Five minutes. I mean, you don't get that too often at the state.

And for people to come together and be able to feel human. I mean, that's really ultimately what we're about. And I love it. And it's a fantastic way to encourage that growth.

But they can bring accessibility questions. And so there's a screenshot here of a FigJam that we have. Where we've got some of these icebreaker questions. And then a screenshot of one of our teams meetings here.

We've been averaging about 40 or so. I think we were in the 60s maybe this last week. So doing really well. And we're excited about that.

We also have been building out an internal knowledge base. We have a teams channel where people can ask specific questions. About tools. About how to tackle specific problems.

And so the team has been documenting their process. And putting it out there. We've got role specific guidance. There's a screenshot here that shows what that SharePoint page looks like.

We're answering questions for teams. So lots of really great work that's being done there as well. And we also get to, you know, any big announcements and stuff can happen there. But here's the question.

You know, our team is doing great work. And I didn't talk about some of our other teams. We have an experienced design team. That's really doing fantastic work.

There's a lot more work that even the accessibility team is working on. Accessibility language for procurements. For project contracts. Making sure that we get that in.

So that when vendors bid on things. They know that this is an expectation that we have from them. But again, there's thousands of engineers at New York State. And if our testing has taught us anything.

It's that digital inclusivity requires technical work. And so the challenge for us. Is how do we scale that? How do we deliver accessible user interfaces to New York State at scale?

So that brings us to the New York State design system. And you still might say, well, what do you mean by a design system? Well, I'll give you our definition of a design system. The New York State design system is a collection of components.

Design tokens. Accessibility standards. And usage guidelines. That helps teams rapidly build usable.

Accessible. Mobile friendly applications and sites. It's made up of essentially three core pillars.

I'm going to read the three of them. We've got our code component library. Basically all components are built and tested to meet accessibility guidelines in design and code. We also have a design prototyping library.

I'm going to talk about each one of these in a little bit more depth. But this is essentially a sibling to our brand name. We have brand guidelines. We have brand guidelines for the state.

If you drive down the highway and you see signs on the side of the road, all of that needs to follow brand guidelines. And so we can't just go off and do our own thing. We need to be respectful of New York State's existing brand guidelines. And then finally, our design system reference site.

And this is basically a unified place where people can come and learn more about it. And it's really telling the story. And helping designers and engineers get very practical guidance about how to do the work. So let's do a quick tour of all three.

First of all is our code component library. So our... every component here... And an analogy I like to give is if you've heard of Google material or...

There's different teams that will basically put together a series of components. And so what we've done is we've built a series... A library of components that have been tested to meet accessibility guidelines. I'm going to talk about that specifically.

But we use keyboard navigation. We check for focus management. We check for screen reader support. What's great about these components is that we have tested them thoroughly for accessibility.

And we have accessible defaults built in. This is a snapshot. If you were to go to our design system reference site. If you were to go there, you would see...

If you clicked on components, there's a list of all of our web components. And this is the core part of the design system. It's... now this is technical.

But it's important to say that the majority of people working at New York State are engineers. And so... and not accessibility specialists. And so we wanted to create something specifically for them.

And so providing something that they can quickly use. They can grab something and know that it's going to be something that they can use. And it will be accessible. And it will be in line with New York State's brand guidelines.

And it just works. That's really important. Because that's the value proposition to our engineers. And so this is really a library of interface components.

It's your buttons. It's your toggles. It's your accordion. It's all the stuff that makes up web pages.

It's basically all of those controls. And teams can use this to quickly build out web applications that are accessible. They work on almost every platform. They look.

They function consistently. Again, we worked with the brand team to make sure that the colors and the fonts and everything were in alignment. So that there's consistency with New York State's applications and services. And then another thing that I wanted to point out here.

We wanted to make this the place that engineers wanted to come. So when an engineer comes here, you see that little thing that says example code? I have a screenshot here. This is accordion.

And it demos an accordion. But there's a spot that says example code. And if you click on that, you can actually copy out our NYS accordion. And you can paste it into a page.

And it'll work. So this is really helpful. And the reason why I wanted to point that out is later on I'm going to talk about how this being a destination for engineers is really valuable in more ways than one. Another thing I wanted to talk about.

I don't want to get too technical in this talk. We can, you know, if you have questions afterwards, we can talk about it. But I wanted to pause for a moment and talk about web components. So web components, another way to say this is these are custom HTML elements.

And it allows us to essentially create whatever we want to. But what we're able to do is we can take anything that we want and put it into a single building block. So the look, the behavior, the accessibility, we can bundle that all inside. And so, you know, when an agency uses one of our components, they don't have to wire up the accessibility themselves.

They can rely on it. So one of the things, as we've done a bunch of testing, one of the things that we've found that is one of the more common issues is that a label for a text input is disconnected from the input itself. That's one of the most common issues we see in all of our testing. And I think, what have we done?

3,000 tests so far? So we've done a lot. And so the connection to the label being broken is one of the things. So for those of you that aren't familiar, if you tab into one of those things, you're not going to hear what that text input field is for.

So you don't know if it's first name or social security number. So that's not a great experience for somebody who is using a screen reader. And so what we did was we built a label into our text input field so that you can just pass that in. And so we do the accessibility under the hood.

And so, again, what's beneficial about this is that these web components are easy to port to other platforms. We can wrap them up and put them out for React. We can wrap them up and put them out for Angular. They can be used in Drupal.

So it doesn't matter what an agency has built their site with. They get that same accessibility components. And so you can see we even have a checklist here where this demonstrates, like, what did we actually do to make sure that our accordions were accessible.

I mentioned the design prototyping library. This might seem inconsequential, but one of the biggest challenges, as I mentioned at the beginning of an organization, is that design-to-development handoff. The intent ends up getting lost. Designers might know more about a customer experience, but the engineers don't actually see it, right?

And so building a set of Lego blocks that are the same for a developer as a designer, when a designer is making choices in the design tool, they're having the same conversation. And so it's much easier for us to be working with the same Lego blocks. Those conversations become much easier. And they're not perfect.

We still have to have those conversations. But it certainly makes it so that we have the same language between each other. And we cover a lot. We have a lot of components built into this.

I'd encourage you to check it out. We have a Figma community file. We have a design system reference site where you can check it out. Another thing that's really valuable, and again, this is maybe a bit technical, but worth mentioning, all of our components are built on these little small things, design tokens.

They're a series of these common design choices. And so I have an example of a few of them there. We have semantically meaningful colors. So we have a danger color.

And we've checked it for accessibility. Another thing that we've seen as number one failure, almost everybody uses F00 as the color for their text input errors. And we just point them at that. We're like, please use this.

We've tested it. And so again, even if we don't have a component for their needs, they can still use these building blocks where we've checked the accessibility. And you might be able to pick that up from the side. We've got here are the colors that can be used against that.

If you hover over them or you tab over them, you'll actually see and can select this is the text input color that you should use. This is the link color that you should use. And it'll show the contrast there. So again, we've thought through those things and there's benefit behind that.

And then last but not least, I'm just going to mention the reference website and then we'll pause for some questions. But one thing I just want to say, you know, agency teams don't come to the reference site because they want to learn about accessibility. They come here because they need to build a web page or a digital service, right? And so we do that and we make that easy for them.

So we've given this thing that's like, come, free, take. And so when they come, they're looking for a quick win, something that they can drop into the project and ship. But every component page that we've got, we also have these sections where we get to talk to them about accessibility. And we could just say, here's the link.

Here's some things you need to know about this particular component. So again, for those of you who have ever tried to get developers to care about accessibility, you know that sometimes that can be challenging. And so it's about getting people to show up. And we're getting people to show up because we've given them a solution.

And so now the reference site solves the attendance problem. They're coming because we're helping them solve a problem. And so they come and we put accessibility right there in the path. And so they get to learn about accessibility along the way.

And it ends up billing. As they learn about it, the next time they build something custom, they want to learn more about it. This is the front page of our design system reference site. Shout out to Doug Bartow, who's a fantastic designer who did some of the design work for us.

I mentioned this accessibility guidance that's right along the engineering solutions. But there's one last thing I want to mention because I think this is fantastic. And kudos to Erin, who's been doing most of the work on this. Alongside of our components, we haven't done all the components yet.

But alongside our components, we have an accessibility checklist. I think the US web design system has something similar. So that's good. Oh, and also shout out to Masha, who's here taking a picture because she helped with the design of this as well.

So thanks to her. But we have an accessibility checklist that you can go through and you can say, how do you check for the behavior that's required? How do you check for the interactivity? What do you check for color and contrast?

So there's a checklist that's very valuable. But one of the things that we're finding is that as we build out these web components, there are teams that either can't migrate over to our web components for whatever reason, like they don't have the funding. They're a legacy system, but they do want to be accessible. And so one of the things that we've started to do is we have a build accessible, where it's like, use the design system components if you can.

And we have like a little sales pitch there for them. Like, please, we've thought about this. We've done all this work. But if you can't, here's how you do it with native components in HTML elements.

And here's how to do it in other situations. And here's the CSS that you would need in order to make it function and look like the existing design system components. So we think this is a really helpful way to, again, help people understand more and give them ways to be able to build and to learn about accessibility, even if they can't use our design system components. So just to quickly recap, we see a really fragmented experience.

I always want to bring it back to the user journey. You know, what we're trying to do is we're not trying to make everything look the same, because some things that are different should look different. But we want to give people the tools that we can have a consistent interaction experience. And we want to especially make sure that those experiences are accessible at scale.

Quick thing before we're done. I would be remiss if I didn't mention we had a Global Accessibility Awareness Day event at the concourse up in Albany. We actually set up a table. And some of our team were there.

We actually created simulators where people could go through and we would disable the mouse cursor. And they'd have to tab through and see what it's like to use a keyboard. And we walked them through a poorly designed from an accessibility standpoint interface. Then we said, and now we fixed it, and here's how.

And we really set it up. I don't know if you can see the start. There's a start button. We tried to make it like a video game.

Come, interact. And we had about 100 people stop. We got a chance to talk to a lot of folks. Ethan was there.

And he had a big screen set up. And he was showing people demos of what it's like to use a screen reader. What that experience is like. Because one of the things that we found, that's the biggest a-ha moment for engineers.

Is when they go, oh, that's why landmarks matter. Or that's why the header order matters in this case. And suddenly the light bulb goes off in their head. So we really wanted that to be a core part of what we do.

So that is... that's it. And there's more information here if you want to check out some of our accessibility stuff. That will take you to our accessibility page on our design system site.

And now we've got time for questions.

Thank you so much. So the plan is we're going to alternate between in-person questions and online questions. I think I saw a hand here somewhere. Yep.

Oh.

Hi, Jessie. Came a little bit late. But this presentation is amazing. And I'm glad someone in New York State is working on kind of unifying the fragmented experiences.

And knowing that, hey, like, there's someone doing this. Which is pretty, pretty awesome. All sorts of legacy systems or all sorts of newer systems. And, like, I love this presentation.

I'll start with one question, which is, you know, with any design system, you're not finishing up, you know, like, you're not creating, you know, like, one big opus of, okay, here's the design for the inputs. Here's the design for accordions. Here's the design for, I don't know, like, tab bars. How do you do incremental adoption?

And how do you handle evolution? Like, let's say, for a color, you're like, oh, we actually want to use a different red. Or, oh, for the accordion, we're going to make a couple of changes due to these, you know, new HTML guidelines. How are you handling, like, both finishing up building the plane while flying it and also evolving sort of, you know, pieces that you think you've done before but you need to do 2.0?

Yeah. So, we are about a year into version one of our release. And so, we haven't... We don't have a fully fleshed out strategy.

We have some ideas about how to do that. But I will add that one of the things that we've tried to do... Again, this is the engineer in me. We've tried to build our components so that they're extensible.

So, an accordion, we have these overrides where if you go to the accordion page, there's a list of CSS overrides where, say, if you want to change the background color of the accordion, you can override this CSS variable. And so, it allows teams to be able to make that change. I think your question is more like how do you do it if we wanted to make that change at a high level and push it out, right?

Versioning it? You put it into a library so people just... The library is funny. Yeah.

Sorry. Yes. I forgot if people are online. I imagine you're probably just making it into like a little component library that's like NPM package for these things.

NPM package... And then they just update the NPM package numbers. And they don't have to worry about those things. It's likely versioning.

Yeah. Yeah. Some type of versioning. But the other part of my question was, let's say you've built out some components, but then you're trying to get someone to adopt it.

But you haven't finished building out all the other components that they might do to do a refresh of accessibility on your website or even start doing it at all. Do other agencies just wait? How do you sort of handle that? Like, oh, we're halfway there.

Do you want to do it? Or do you wait two or three months for us? We're big fans of the carrot. So anything that we can do to make their lives easier, if we can say we will solve 50% of your problems right now, that's what we had to do for a year.

Because when we launched, we had probably 15 components. We're now at 30. So we've dispelled some of that. We haven't tackled card yet.

But by golly, we're working on it. So good question, though. Yeah. Thank you.

We can take another one from the audience.

Hi. So a bit of a relaxation of his question. Has this been released under an open source license? And is it set up in a way so that nonprofits and other actors can brand it to fit their branding needs but still use the accessibility features that you put into the components?

Great question. Yes, it's open source. One of the things, one of the battles we fought early on, because it doesn't make sense to security teams. Why would you put code out there?

But we had to convince them this is front end HTML code. We're not putting database credentials anywhere. So we did. We open sourced it with a little hashtag or asterisk about our fonts because they're proprietary.

But, yeah, we put it out there. And we also, at the end of the day... As a part of our Figma library, we have a community version of this as well where somebody can override the color theme because we have color themes for agencies. But we allow that, you know, somebody can go in and make those changes.

But, yeah, it's a big part of what we care about.

Thank you so much. I'm going to look there.

Which, by the way, if you find a problem, feel free to file a pull request or a bug. Okay. We get better with everybody participating. Hi.

Hey. I don't understand a lot of what you say. I don't know what an accordion is. But I work for City University.

And we use a platform called BrightSpace. That's where our students log in to, you know, they can see what their syllabus is for their class, what the requirements are, this and that. And there's a really cool little tool that tells us, like, you're 97% if you're a student. And it's accessible.

Or you need to change this or fix that. And kind of what I've gathered from it is that PDFs are bad. Don't use pictures when you don't have to. And also, like, contrast.

Make sure that you're using contrast. The way that things are in CUNY is that you don't need to attend training about accessibility if you don't want to. So a lot of folks don't. So I'm trying to kind of, like, share back what I'm learning.

Right. Is there anything else that you think that we could do to make our BrightSpace pages for our different classes, for our programs more accessible, other than the things I've mentioned, like stop with the uploading PDFs, the pictures, and the weird fonts and low contrast? So those are great places to start. Not knowing the system, it's hard to say exactly.

But I'll tell you, we have, I think, probably similar situations where teams have Salesforce or they have, like, announced systems. They have, like, a low-code tool or something. Where we don't really have control over the components. Even if they wanted to use it, they couldn't.

And so for teams like that, what we've tried to do is come alongside and build out themes for those systems using our design tokens, which we've tested for accessibility from a contrast perspective. I don't know what a design token is. It's so, you know, the colors, like the background color and the color of the button and the text that's on the page? Those have to get defined somewhere.

And so essentially what we do, it probably, it either has a good accessible baseline or it doesn't. And if it does, then you're probably in a good place in terms of using it, you know, using the defaults out of the box. But, again, I would rely on one of those, you know, checkers. And it never hurts to go through and do some manual testing of those pages that are created.

Use a screen reader. Just what gets announced? I'll give one quick example of this because I think it will benefit everybody. We, on our design system reference site, one of the first things, you know, we had passed an automatic accessibility scan.

And it turns out there was like a two-sentence paragraph for our logo on the top right-hand side. And then there was a two-sentence, the exact same description for that beautiful illustration on the side. So somebody using screen reader would hear those four sentences, you know, at the top of every page. So that's something where that passes the scanner.

But if you... If you took, you know, time to actually... And like, oh, that's a bad experience. So those kinds of things can help give you a little bit better guidance.

One other thing I'll just add is the required training. I would say, like, as much as possible, where you can, fight that fight. We're trying to push that as well where we create a training. And it doesn't have to be huge.

But just let people know what's there so that they can dig a little bit deeper as they're able to. Totally. Yeah. That's great.

Thank you.

Nice. And then we have an online question. How do you deal with the resistance to change across different government agencies? What does the typical adoption curve look like?

And what would you consider your primary challenge? That's a big question. First of all, shout out to everybody who's joining online. Thank you.

I really appreciate you being here as well.

So, thankfully, the DOJ ruling has been helpful. I think nothing like to fire more than a compliance deadline. When we lead, we lead with the user needs because that's important for us. But there are a lot of people who say they've got a bunch of other constraints that they're under.

And so knowing that there's this deadline is just, it does a lot of work. And I think that's really helpful. And it allows us to come in and not necessarily be the bad guy, but say, let us help you get to a better place for that. So I think that's been helpful.

In terms of adoption, I would say there's a couple of challenges. One is the different platforms.

So there's, I could go into great detail, but the way that state funding tends to work is a project gets funded and there's money that goes to that project getting built. And then it turns into funding. And then it turns into like operations mode and the funding, like you don't get that big spike of funding. And I'm generalizing a little bit, but let's just say that that's kind of the model.

So what happens is if we go back to a team that's at that operations model, we say, change everything. That's a very hard proposition for them. And so we really, that guidance slide, we try to be as pragmatic as possible. I have two sides, right?

The design system is very like, this is the way that it should be. But when it comes to fixing problems, I understand that teams are under a lot of control. And so I say, look, if you can just make it so that we can hit escape to get past this modal, somebody can use your service. It's not going to be great, but at least they can get past it.

So that's been another challenge. But thankfully, we've actually had a lot of great response from various teams. There's a little bit of, you know, CYA. And I think that's just inherent in any large organization, especially if people don't fully understand it.

But we've tried to empower them so that they have a better understanding. So it's less CYA. And it's more about how do we make this work? How do we make this better?

And how do we do it in a practical way? So, yeah. Thank you. And then...

I thought we said no questions from Donny. I understand it. You know what? I won't even make it a question because I just want to comment really quickly.

Because the person who was asking about CUNY, I know exactly what you're talking about in BrightSpace. And Jesse can vouch for me about knowing a little bit about design systems. So let's talk. Okay.

That's all. I didn't know... Because Jesse was about to sweat for my question, I'm sure. I've been a little bit alone.

The last question. Hi.

Sorry. Just a follow-up. So we only have time for one more question. So I'm going to hand it...

If we catch up afterwards. Okay. Yeah. We'll do that.

Okay. Cool. So we also had another online question. I'm curious whether the team tracks design system adoption alongside...

UX outcomes, both to understand how it's improving the user experience and to help drive broader adoption. So it's kind of connected to the previous online question. Yeah. It's a fantastic question.

I will tell you that... And those that are here from our team will tell you, Luke Chard, who heads up our human-centered design team, he believes user research. That is his bread and butter. He...

You know, that's the thing that is so important to him. And so it's great doing engineering work in an organization that's led by somebody who thinks that way. So he's very much about let's test these things. Let's make sure that they work.

We do measure adoption in a lot of different ways. That topic has been beat. We can, you know, talk about it afterwards. But we measure adoption in a lot of different ways.

Some in design. We can measure adoption. Some in engineering side. We have seen a significant uptick in our adoption.

But the... In terms of the user outcomes, part of what we've done is... I like to say our team is archaeologists. Because the team has been doing...

I mean, the team that I joined did the vaccine... What is it? The vaccine where you reserve being able to get your COVID vaccine. Right?

And so they did that. And they... I mean, they could tell you those stories better than I could. But the woman who heads up that experience design team, Kristin Sorrentino, she...

She has done fantastic work. And so measuring user outcomes with the work with the design system. We really come and enable that team. Because they're the ones doing a lot of the project work to come alongside agencies and say, Hey, let's dive in and make sure we do the sense making before we build anything.

And then when we build it, we've got this design system which is codified these great... These codified these great patterns. So that's really important. But what's amazing about all of that is once we do that, and once we launch that, we can bring anything that we learn back into the system.

And so the system really is meant to be... I like to describe it. It's the long tail for the engineers that... Or the projects that don't have the funding to get user research.

Because, you know, there'll be like an ag and markets cataloging system or something. That they're not going to be able to... We have a limited bandwidth of designer and user research time. And so we take those good patterns.

We bake it into the system. We provide the guidance. The documentation or an MCP server. And then it allows downstream teams to be able to make much of that.

And so that's our goal here. Is to help the ones here. But then to codify that in a place that many others can benefit from it. This is such a good closeout for the whole conversation.

Oh, my God. The vaccine stuff. Wow. All right.

So, okay. So as a follow-up to the CUNY also, I wanted to say we have a whole accessibility Slack. So if you have any questions, ping any of the organizers. And we'll be able to provide you there.

And with that, just want to say again, thank you to Jesse.