Real Talk on Web Accessibility with Marcy Sutton Todd

Welcome to Syntax today. We have Marcy Sutton Todd on, who is a senior front end developer, accessibility advocate, has a course on accessibility.

Just one of the, I think, top minds in the accessibility space right now of you're building a website. You're writing some JavaScript, HTML, CSS. You gotta make sure this thing is is accessible.

She's one of the best. So welcome, Marcy. Thanks so much for coming on. Hey. Thanks for having me. I'm so excited to be here. So today, we're gonna talk about a whole bunch of stuff around accessibility, and I I really hope to get a bunch of, like like, practical things that just regular developers can get out of it. Because, honestly, I think that's, like, one of the biggest spaces that developers need to improve, which is, like, not that every single person needs to be an accessibility expert. We certainly need those. We need reviews and whatnot. But I think just, like, the the general knowledge just like you have general knowledge of CSS, you should know about how to approach these things. Every developer is kinda needs to know it. So you wanna give us a quick rundown, who you are or what you do?

Sure. Yeah. So I'm Marcy. I am a front end developer. I've been in the game for, gosh, so long.

A lot of people, but I love it. I love building user interfaces.

And somewhere along the way, I learned about web accessibility.

And it was really working with people with disabilities that it struck me that, like, woah. I can have an impact here. Mhmm. Like, this doesn't work for people that I can even talk to and say, like, oh, tell me more. Tell me how this works or doesn't work for you. Like, that connection to people with disabilities is what super resonated with me. And I've never been able to turn it off. So when I build a user interface, whether accessibility is, like, a very clear requirement or not, it's a requirement of me and how I build things.

Sometimes I put in that little extra effort, even though no one's asking, maybe even rebel a bit and just do it because it's work that needs to get And so in addition to actually building user interfaces, I've shared whatever knowledge I have with people along the way through courses, through workshops, and talks, just because it seemed like if we tell our friends and then our our friends tell their friends, it can snowball into this thing where more people know about it and there's easy, approachable things that we could do to make the web more accessible.

I just saw this lever of impact. Like, we could really make a difference here if we collectively know more and do more.

So that's kind of been my mission for a while.

Nice. Great. Yeah. I I really like this. Wes so you have this course ESLint accessibility.com, and I was scrolling through, like, the the list of of of tech in it. And it it looks like you're you're covering, like, React Hooks and Refs and and Portals and things like that, which I I think is why I asked you to come on here because you are not just the accessibility person who tells people what they're doing wrong. Mhmm. You're a front end developer. Right? Like, you actually know how to build this stuff from the get go. Is is that fair to say?

Yes. For sure. Yeah. The the wag of the finger, the kind of frustration that I totally get now that I've been in accessibility for a long time, I just didn't feel like that was a really a great way to influence people and to make it an actual difference. Like, certain tones might like, they might stick in people's minds, but if you wanna influence people to make change, you have to kinda persuade them to do it. And so making it like, hey. The cool kids are over here.

Like, people are gonna build stuff with React or with Svelte or whatever tool. Like, users don't really care what tool you're using.

We just want, you know, whatever's ubiquitous in the industry, we want to make those web applications and websites accessible.

So those are the tools that I use that I really enjoy.

So a lot of my stuff does cover the the tools using React or the React ecosystem.

But, really, any client rendered JavaScript framework is important to cover because so many of these web apps are just, like, missing the basics. Mhmm.

Yeah. Let's talk about some of that. Because I think a lot of our our listeners, when they, you know, hear accessibilities, they might think, alright. I have to make sure it works with screen readers, for my keyboard.

What are the things like, the main things that you have to think about in terms of, like, supporting Wes you're supporting accessibility?

Yeah. The keyboard is is such a big one. It sort of, like, screen reader support piggybacks on top of keyboard support. Like, they're related.

There's nuances to both. So the keyboard support is always where I start. Because if I tab through a web app or a website, I can usually tell instantly whether it is going to work or not. You Node? Can I see where my focus outline is? Can I even reach and operate everything that a mouse user could could, like, hover over and do, you know, menus and all of that stuff? Like, can I do it as if I had no mouse, no trackpad at all? That's kinda my first run through of everything.

But then there's a ton of stuff in how you mark it up with image alt text and, you know, how you use semantic markup or not with your HTML to add headings and landmarks and lists and all of that goodness that you get from HTML.

And then there's design aspects too, like color contrast.

I think that might even be the number 1 issue on the Wes is contrast that isn't obvious enough between foreground and background colors. So there's tools that we use to highlight a lot of this stuff, like browser extensions.

That with the keyboard test, like, you could get really far with those 2 things, I would say. There was a period of time where, like, all the design inspo

on all the sites, dribble and everything, had just, like, massively low color contrast until everybody took a step back and was like, wait a second.

That's such a good one. Yeah. Even today, I think we've all gained a bit of an eye for wait a second. I think sometimes it can get tricky, but the the super light gray and a a white background is hopefully out of the, the trends space for now.

You would hope.

Yes. Yes. Right. Yes. I I can still see it quite a bit. And even even myself, I've I've written many websites in my day, and then you run the accessibility checker through it and go, oh, wow. I didn't even realize it. Because it's surprising the color combos that you think would be accessible but are not. Like, for example, YouTube red with white text on top of it is not accessible, And I learned that because I was building a a button on my website that Sanity YouTube, and I had white text. And I just went to YouTube, color pickered their YouTube red, and it it flagged it. And it just you you gotta bump it down just a little bit, and it you can't even tell, but that's amazing

what you would think. Oh, that's that's no problem to to look at that type of thing, but it it flags it. Yeah. You would think. Yeah. Big big brand colors like that, you would think are accessible. But, yeah, sometimes it just takes a little tweak, and so you just kinda slip that under the radar and make that change as a developer. But sometimes there's too big of a gulf, and you have to go back to your creative team and say, hey.

This just isn't gonna work. You Node? This, like, white text on an orange background, I get that it's our brand color, but we need a palette that would actually works.

Do you educate design teams a Scott, or is that something that I think the developers and accessibility experts should be doing?

Yes. Definitely.

I would say collaborate is the really the best way to think of it JS that we're trying to work together to solve, like, problems in ways that, you know, we're balancing a lot of different priorities.

And so if we collaborate, then it's more of a a we situation and not an us versus them sort of thing. Because I'm always trying to, like, come up with the best solution that satisfies everyone's input.

But sometimes we have these hard rules, like, this has to meet contrast guidelines. And so how do we get there? It's kinda like, that's the process that I try and work within.

Yeah.

I always wondered alongside that, like, color contrast thing. And, like, we see now Versus Code is shipping with a really nice, high contrast Yarn and light themes. If you're building out a website and you have this concept of themes like, on the Syntax website, we have we have themes. Do you think every single theme needs to be accessible, or do you need to make sure that there is an accessible theme turned on by default?

I would say the default needs to be accessible for sure. Yeah. Because that way, you're not forcing somebody who needs better access to go and change the default. So that's Yep. Step 1. I would say if you have a variety of themes for people to choose from, try to get them as close as you can, like, if possible. But maybe you have a low contrast theme, and you label it that. And some people might prefer it, which is what can get tricky sometimes JS that it's it's pretty much impossible to make something that's going to work perfectly for every single person and every single situation.

So having options and allowing people to personalize a little bit, whatever ways you can do that JS helpful. And, yeah, maybe you have a low contrast theme.

Somebody who suffers from migraines or, I don't know, is just, like, kinda overwhelmed that day, maybe what they can see, maybe that would be what they chose.

I know. I didn't think about that for a long time because I I I do personally I personally like the Deno zero zero black on things. I know there's, like, a 1000000000 posts that say don't use that.

But I didn't think that was a problem until I I learned about some people do. They get migraines from

bright text on a infinitely black background, and and that can be just as much of a problem as not being able to see it. I was building out my Cobalt 2 theme. I don't know. This was probably 3 or 4 years ago when I was adding, like, TypeScript support for it. And I by default, I pick, like, a pink for the types, and there's just something off about it that hurt my eyes. When you scrolled it, it was just a bit weird. And I was I I was like, well, it's accessible, but I really had to tweak it because I don't I don't even know how to explain it, but it just hurt my eyes to look at that specific pink. And I you think about that. Like, oh, yeah. There's there's lots of people in different situations that could not like that. Yeah. Totally. Yeah. It's a moving target. You know? Every it's different. Sometimes if I was staring at the computer, like like, doing a podcast like this or doing a talk, I actually have to leave the computer for a while to not get a migraine. And so you think about, like, for people who are coming back to

your website on their phone or on their computer, that might be, like, so many things they've seen that day that could just tip the scales to, like, okay. I have to leave the Internet for the day. Yeah. So we talk a lot about motion in that realm. Like, if you have auto playing video or just motion that users can't turn off, they can't pause, stop, or hide it to invoke some, guy you know, WCAG terminology, then they're gonna leave, or they're gonna have a seizure, or, like, something really terrible could happen for people. So we wanna work within WCAG guidelines and best practices to try and make the web safer and easier to use, which is a lofty goal. Sometimes it's hard to meet that.

There's a lot of, like, new things in CSS that are making this stuff easier. You know? Like, very easily, you can add a media query nested inside of your selector that says prefers reduced motion, animation, none. Boom. You turn it off. Right? Or you just globally disable all of your your animations. So I'm curious your thoughts on some of the new stuff that has come to HTML CSS and and what they're doing for accessibility? Maybe popover, dialog.

What are some of the other ones that Scott just did a whole talk on on the screen. Color eventually. Yeah. Oh, yeah. Hopefully, that comes. Oh, gosh. What a time to be alive.

Man, focus visible and focus within, those are some of my favorites in CSS. Wes. Oh, they're so good. Because sometimes the the alternatives to, like, the lack of these new CSS features or even an HTML Yeah. The alternatives were so hairy to try and solve, inert in HTML. That one's like, we've been begging for it for Yarn, and we kinda use it anyway with a polysil. But these tools are so essential for certain tasks within accessibility that I can't imagine living without them. And focus visible is one where if you click on a button, it is actually focused.

And so if it if you have the normal CSS focus selector, you will see it, like, persist.

And I've closed those bugs on GitHub, like, where people are they open an issue, and they're like, this looks bad. Like, I clicked, and it has a focus outline.

And at the time, we didn't have, any alternatives, really. So JavaScript solutions popped up, you know, various things that we tried to do to solve that problem. And then finally, focus visible made it so that you can style just the keyboard and then turn it off for mouse users.

Oh, cool. Yeah. Which works on most cases.

It's really been helpful. So should we be using, like, focus visible, and then, like, focus within is is when an something is focused within an another element, like a child is focused?

Yes. So focus within, I found really useful recently working on a mega menu. Like, if you have you know, say you're you're tabbed down into a child within a big structure, and you have some surrounding style that needs to be visible, like, you know, a different background color or a border or, you know, something that kind of, like, shows the overall structure of something, but you are focused on a child.

Focused within can give you that styling capability to, like, you know, style the the surrounding context of something.

And that one is super handy too.

Using the not selector as well, like these combo selectors with, like, has or Scott, I've been able to do some very precise styling on accessible mega menus and things using those new selectors.

You know, I did not even really clock a focus visible. This is, like, good for me because I'm looking at this, and and it again, it it allows you to control the keyboard focus, which, man, I think that's gonna make styling this stuff a lot less annoying to some some folks. But, also, it's, you know, it's not always great to have a giant focus ring if you're using it by your mouse. So, man, man, that's really great. What about you mentioned inert. Well, how what does inert do for you? Okay. So inert, this is a bit of a niche

feature. So it's a a Boolean attribute you can apply in HTML to make a whole section of your HTML subtree, like, unreachable from the keyboard and a screen reader. So say you've got a modal dialogue.

You open that up, and you wanna trap, you know, interactions within that modal dialogue, but you've got all this interactive stuff kind of, like, visibly behind it. Like, the rest of your page has links in it and buttons in it.

So to make it so that background content is effectively disabled, if you have your modal as a sibling to, like, the main element, which contains everything else, you could mark main as inert.

And it does require a polyfill right now, but it will, put Yarn you hidden of true on that main element, and it will also disable any tab index within it. And that's really the piece that, like, the alternative was a lot of DOM walking with JavaScript, which you can do. But, I mean, it's it was tough. Like, it's way easier to just put 1 boolean attribute on something.

It will render that inert to use the word and the definition.

But it just really makes it easy to disable content that you're not supposed to be able to reach, including all of the children.

Yeah. We got we got bit by that on the the syntax website because I we had used a or sorry. A dialogue opened modally, which is when it it pops up, and then it made the rest of the website inert. But then we had a toast that was saying, like, successfully saved or something like that, but the toast was behind.

The toast was in the inert, so it was not reading out to the user. It's not announcing it's saved. So the user would just hit the button. Like, if you could see this website, you it was actually behind it. So it was it was it was broken for, like, literally everybody.

But, yeah, it bit us. And do you have any any thoughts on are we overusing dialogues? Because anytime I have a problem with a modal or dialogue, sometimes the answer is maybe you shouldn't be using a modal for that.

Modal section. Yeah. I mean, like Yes. A web switcher in a modal. Yeah. I think it does get overused just kind of, like, from a design standpoint, modal dialogue. So there is that issue.

You just reminded me, though, that I have encountered that same problem.

I think it was with Headless UI dialogue.

They put things into a nerd. And it I used to work on frameworks. Like, I get it. You're really trying to make accessibility just work from the framework level, but there's so many use cases that you can't anticipate as a framework author, JS a library author.

But sometimes those bugs crop up that are really hard to work around. And in the case of the site I was working on, it was a React app that had multiple entry points. So it wasn't like your typical React application, and the headless UI dialogue component just could you just couldn't do anything other than, like, I think there might have been a intersection observer or some sort of, like, DOM API to, like, go and remove what headless UI had added, which was, like, super problematic to have to work around it to that degree.

But you're right. Like, if you don't have the API control to be able to tell the library you're using, like, hey. Only put under here or, you know, be more specific about it. Like, if you don't have those escape hatches sometimes, like, people are gonna abandon your your library after a while. Because, like, the accessibility improvements I put in air quotes, it just sometimes, it's too hard to say, like, this is gonna work for every web app, and I've I've lived that. It's a hard line to walk. Because you wanna make it automatic. You wanna do things, like, in the UI component library as easily as you can for people to adopt, but sometimes it can go hay haywire with the case of your toast.

Yeah. Yeah. Exactly. Luckily, it was the the library we had set up for it worked really well where you could have multiple toasts, and it I think it just found the closest one. So I was able to just put the Toast inside of, the pop up, and it fixed all of our issues, which I'm glad because I don't know how we would have solved that otherwise.

Like, we would have had to move away from using modal dialogues, and then you lose the inert. You lose the animations. You lose all of the benefits of capture. Yeah. Able to do yeah. The keyboard capture.

Let's talk about ARIA attributes. So somebody is learning to make their website accessible.

I've heard that ARIA attributes are a last ditch effort. Is that true?

Yes. Or In in most cases, I would say I would label it as an advanced tool because it's really easy to make your web app worse, like, if you don't know what the attributes are doing. And some great examples are aria hidden, which actually is what Inert is applying for you automatically.

And that one removes all accessibility information from a subtree in your HTML, so a screen reader won't get that information.

Another Node and I cannot give you a bigger, like, caution before I mentioned this one, but the role of application, that one is also like if you're like, oh, yeah. I'm building an application. I'm just gonna slap this ARIA Node on here.

Okay. Like, stop.

What does that do?

It will change the, screen reader interaction mode on Windows screen readers, such as JAWS and NVDA, such that it changes how the screen reader reads out elements. So for example, in JAWS or NVDA, when you are in browse mode and you hit the h key, it will cycle through headings. So it's like a way to read content.

If you're in an input, like a text input or something that you actually need to type the h, the mode that it automatically enters, like, it will type the h into the input instead of going through the headings.

Application mode takes away that browse functionality. Like Oh. It puts you right into, like commands go straight to the computer, which sometimes is what you want. But, like, it's so rare, and that is, like, the most advanced of advanced tools that I like. Yeah. I was gonna say, when do you actually need that? Yeah. When is the what is that use case? When you're building, like, Google Docs or something Wes you are replacing every single feature that you're taking away with some custom implementation, and then you're testing it heavily to make sure it works.

Because, yeah, if you take that stuff away, the user can manually, like, flip between browse mode and, gosh. What are the 2 modes? I'm blanking on them. But you can flip between the interaction modes in Windows screen readers manually, but then it's not automatic. So it's like it takes away some of the default functionality that websites have.

So it's definitely more reserved for super advanced tools Wes you are implementing, like, all of these features that you're taking away. So if you're Google, maybe. But even then, like, you have to test things very heavily with people who use screen readers every day to make sure it still works.

Yeah. I guess that's a good Wes, or that leads directly into, like, the next question. It's like, how do how do you even test these things? Like, what what is your what are your best tools for testing?

Find people who use screen readers every day. That's that's my and pay them. That's my biggest advice, because I am very much a novice screen reader user, and that's okay. Like, I don't rely on them every day. I know a lot of the pitfalls and you know, more than most developers would, but I get it wrong sometimes. I'll be like, wait. What's that command again? What's the name of that browser or that interaction mode again? I don't remember. So I have to look it up. And I think where it really becomes tricky is when you're filing issues against something.

Is it a legitimate issue, or did you did you actually, like, capture, like, the state of something for someone who relies on a screen reader every day? Some of the stuff is easy to find, and the browser extensions that we use in the industry can catch some of this stuff.

But it's not gonna give you much, in the way of user experience.

You know? So I would say work with groups like Fable out of Toronto.

They are awesome in connecting you with people who use assistive technologies and other ways of navigating too, like someone who uses, you know, screen magnification or Yeah. You know, all different kinds of things that can help you get out of your, like, biased

zone that you live in every day. That would be my ESLint advice. We've talked about this for a while, and I think we need to make this show JS just a couple people with disabilities browsing the Wes. Because Yes. Probably 10 years ago, I watched a ESLint guy use an iPhone, and it was mind blowing to me how they did it. And I I was just like, that was, like, so good for me to understand how people with disabilities use the web. And I think, like, more people need to just watch how this works rather than like, of course, these rules and all these tools that tell you about color contrast and you don't have an alt tag, those things are are really important. But, also, understanding, like you said, how they use the web is super important as well.

Yeah. That's what it's all about. You know, we we've often say, oh, yeah. Use the screen reader. Try it. See but, like, that isn't how these folks are using it. They're experts at their devices.

They know how to use it way better than you could possibly

ever pick up in a couple of minutes of trying a a screen reader for the 1st time. Well yeah. And then people have different preferences too. You know? It's like there's no one size fits all. Screen readers are configurable. There's so many different ones. So I think in the practice of observing someone who uses their tools every day, you might pick up different things, and then we try and apply them to make something that works for a broad range of people.

I think the browser extensions and the tools we use as developers, like, that can take out the easy stuff. Like, you forgot alt text on your images, or maybe even something more advanced with ARIA. Like, maybe you put a roll of menu on your URLs, but you didn't do the rest of the pattern that goes along with it. Like, some of that stuff, you can kinda rule out ahead of time before you engage with people with disabilities who are gonna review your stuff just to make it so that, like, they're spending their time on the more nuanced user experience type issues.

But, yeah, it's really we have to remember what this is all about. Like, I recently worked with a team who was producing a presentation on accessibility for a client, and it was literally, like, all about compliance. And I don't even think they mentioned people. Like, I don't man. Like, don't get sued, and, like, you have to legally do this. There were this many lawsuits in 2023, and my my biggest message to them was, like, let's focus on what this is about. Like Yeah. This would be the driest, most boring presentation of all time if you're only talking about compliance, and you're gonna miss the point.

So I just that was, like, my best feedback to people was, like, really understand what accessibility is about and who it's for, and it's really to remove barriers to access for people with disabilities.

Man, you know, I just saw a tweet today about somebody asking Tim Cook about what was it about? Man, did did they only do x, y, and z, feature because of government expectations, or, like, did you consider the the cost that it would take to implement these accessibility features? And Tim Cook's response was, when we work on making our devices accessible to the blind, I don't consider the bloody ROI. Like, that's it. He's talking about the people. Like

Yeah. Yeah. That's such a good, yeah, good quote for that. That's cool. On that same point, like, obviously, it'd be great to hire somebody to test your application.

But at certain point, like, developers just wanna be able to test it themselves as well. Right? And there's I know there's probably 2 big screen readers, NVDA, non visual

desktop access.

Oh, developer trivia. JAWS. Yes.

And JAWS. And then but, like, most of the people listening to this are sitting in front of a MacBook Pro and don't have, like, a Windows machine handy, especially now that IE testing is is no longer a thing. Is the Apple accessibility reader is that good? Is that good enough? Is that is that a good way to test your applications?

Yeah. So Vercel over is the screen reader on Yep. OS 10 and Bos. And it's great. It works really well with Safari.

So for developers that are like, we don't test in Safari, it's like, well, if you're gonna test with voice over, it's going to work best with Safari.

But I would say it's still possible to make something that works in voice over that does not work very well on Windows screen readers, and that is missing a lot of where people navigate who use screen readers every day. And the data that I get that from, we can't track screen reader usage for privacy reasons.

We do have the screen reader surveys from WebAIM, web accessibility in mind, and it's skewed pretty heavily toward, like, web professionals in North America also.

But it's still the best data we have on, like, which screen readers are used the most, including mobile devices.

And so for that reason, I would say for developers, you know, at least somewhere in your software development life cycle, even if voice over is, like, your more regular screen reader you test with, personally, I still use a virtual machine to test on Windows.

So Parallels is pretty solid.

I mean, it does cost money, so your organization, hopefully, will pay for it, at least, like, by some means.

Because, yeah, VirtualBox and IE developer boxes, like, those are long gone. But you can test with Parallels.

MDDA is free and open source on Windows.

So it is helpful, because those screen readers work differently. Like, those interaction modes I was talking about, those aren't part of voice over. So, like, you could put a role of application in your app and totally hose Windows screen readers.

Yeah. You might have different results in voice over. So I actually had somebody ask me when I posted about a fix I had. They say, well, does it of course, it works in sorry. What's it called? The Apple one called? Voice Voice over? Mhmm. Yeah. But what about Jaws? I would think, not knowing, most people use, like, the the Mac voice over. You know, most people are on iPad or whatever, but it's not. It's it's 10% people using voice over and then probably 80% between Jaws and and VDA.

So I was I was really surprised at that. So I thought, and I so I I went and and downloaded a VM and,

got it running. Actually, no. I used some website where I had a free trial, and I could I could use it. That's super worth mentioning, actually. So the the virtual machine is, like, what I do, per se out, because I just want that control and all that stuff. However, there is a service called AssistiveLabs, and they have, like, a cloud based solution that would be another option for organizations to try and test cross platform.

Yeah. It was great. I I was up and running pretty quickly, and then you can, of course, buy a, a monthly it was $19 a month. You can get a 120 testing minutes a month. So it's Scott cheap. It's probably cheaper to go get a Windows laptop or run a VM, but you can get up and running with this extremely quickly. Especially if you have an issue, you can go from having an issue to testing it in, like, 3 minutes. Totally. Yeah. And it is worth it. I remember I I used to write a a blog called Accessibility

Wins, which I gave up on because it's actually really hard to find wins.

But I wrote up something that I was like, yeah. This works great in voice over. Yeah. Guess what? It didn't work well on Windows screen readers. So I had Vercel, like, I had to redo it. It was super embarrassing.

So I've learned that, like, in my core being that, like, you have to test it in Windows screen readers, primarily because that's where people use it the most, you know, on like, for anyone using a desktop machine with a screen reader.

Yeah. JAWS and NVDA, fortunately, they do work very similarly.

So most Okay. You could test in NVDA.

And if you want to see all of the errors in your application, you'll want to check out Sentry at century.ioforward/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to reduce entry Scott I o forward slash syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

Why do you think it's so hard to get these things right across all devices?

Well, screen readers aren't standardized for 1. So there's nuances, like, in how ARIA JS, like, how that's interpreted.

Yeah. They're commercial software products, like, in at least in the case of JAWS.

Yeah. Just like every tool has a slightly different approach to things that is reminiscent of how web browsers have been in the past too. Fortunately, it's become pretty stable. But, yeah, it's a really good question. Like, why is it so hard? Sometimes, I think it's because they're they're pretty advanced tools doing advanced things. For JAWS, I know that it does look at the accessibility tree and the DOM, so that's not always the case in screen readers. Like, how much does the screen reader go into your HTML to evaluate it? I think JAWS started doing that just because it Wes, like, the accessibility tree just didn't have as much in it. Maybe ARIA I don't know. There's all kinds of reasons. But, yeah, it's it's different in every screen reader, which is why those numbers, like the WebAIM metrics, are really helpful because it gives us some direction to follow.

And if you look at how much of your traffic is in a given browser, like, wow. We get a lot of traffic on mobile. You could use that to kind of guide you toward the WebAIM screen reader survey and say, okay. For this mobile browser, I can see in the survey that users use, you know, x screen reader the most. So it's like those metrics can at least help you narrow down what to Wes. Because, like, we only have so much time to test everything in our test matrix.

And then you add screen readers and, like, the fact that we don't have the skills in the industry to do it well, like, you have to prioritize something. So Yeah. That's how I think about it.

Can you explain how somebody with a disability moves around a website? Like, of course, you can tab. Right? But not everyone's sitting there tabbing through a 1,000 links to get to the content. Right?

Sure. Yeah. Well, I guess the first thing I would say is that, like, disability JS not a monolith, and so everybody JS gonna have a different way of navigating.

Yeah. And people might even have multiple disabilities. Like, it's so varied. I mean, people are just as different as, you know, as different as different could be. So I would say for someone who is blind or low vision and is using a screen reader and that big caveat, like, I don't use a screen reader every day. But this is where semantic markup becomes very helpful, because you can navigate by headings.

So you mentioned the tab key, but a lot of users navigate by headings using that h key I mentioned on Windows screen readers. That will just take you through every content piece of content that's marked up as an h one through h six heading. It'll announce, you know, what heading level, what the text is. Kind of depending on how your screen reader is configured, it will potentially read a summary of the page when you land on it. You might hear lots of other information, like what semantic landmarks an element is inside of. Like, if it's in a nav, it might you might hear it say, like, nav h one, you know, whatever the content JS, like, all of that information that's kinda surrounding your actual text.

Like, is it in a list? Is it a form input? Like, all that goodness, like, that's in there for a reason, and it's because it all can be announced to a screen reader. So, yeah, there's headings. You can navigate by landmarks.

In voice over, in NVDA, and probably JAWS, there are collections that you could go through. So in voice over, it's called the rotor.

In NVDA, it's called an elements list. You could pull up all the headings. Like, there's a dialogue you pop open. It can show all the headings or all the buttons, and it'll give you a whole list of everything. So that's another way to jump through content.

Yeah. There's so many different ways to navigate.

I guess Node gotcha that I will mention if you're kind of just getting started with supporting screen readers is that not everything needs to be interactive for a screen reader to announce it. So a heading is not an interactive element. It's a text text content element Mhmm. Block level.

And so you don't need to put tab index onto a heading for a screen reader to reach it. You don't interact with it. You're just reading it. So that's kinda the biggest, like, upfront tip I could give JS that Node that navigating Scott like, browsing content to read it, you have commands in the screen reader that support that. You only need to make interactive things that actually do functions, like toggling functionality or linking to another page or an internal jump link or a form control. Like, those are interactive.

So those need to be reachable with the keyboard either by, like, default, you know, elements that are focusable by default, or you can do a custom tabindex implementation with all of the other requirements that go along with with your Yeah. ARIA, you know, keyboard events. Like, an HTML button, you can go so far with that for anything that, like, needs to do functionality in your web app because of what it gives you for free.

So, like, the other big caution I would give you is if you're putting tab pnpm on elements, make sure they're actually fully interactive.

So, like, do some searching on the Internet of, like, how to make a custom widget. Maybe the ARIA authoring practices guide would be a good place to look.

Those patterns aren't production ready, but they're really

informative to give you, like, ideas on what Yeah. What the conventions are. I built my own drag and drop, and I built the drag and drop in no no time at all. And then I went to make it accessible, and I was like, I need some good examples of Yeah. How do you make drag and drop accessible? Right? We had, Alex on from Pragmatic Drag and Drop, and he he kinda explained to how to do that as well. So there's there's a lot to it. Those little recipes tabs as well is another thing that people goof up all the time. Right? Mhmm. And they have really good example of how to do tabs.

Did the drag and drop solution have an edit mode? Do you remember?

You have to, like, enter into edit mode? Yes. Yeah. The the way I I implemented it was figured it was I I hit a I hit a button, and it entered into edit mode. And then I put something in we can maybe talk about the ARIA live regions as well or announcements to say, like, now editing, whatever. And then you can press up or down, and it would reorder it and then announce. Is that is that the way to do it? Yes? Yes. Yeah. And a lot of that is because of those Windows screen reader interaction modes. Like Mhmm. That's one of those cases where that Node of application I mentioned might be appropriate JS in the edit mode, but it gets really,

like, detailed.

Like, that's kinda you're you're crossing into very advanced screen reader usage there. And sometimes, just getting stuff tested in front of people like, if you're building a Bos complex.

Can we talk about, like, live regions as well? Because, like, a website, you got text on there. You got images. Right? Like like, I think we understand that you can make that accessible. But moving into building an app Wes a single page app, you wanna save things. You wanna delete things.

When an action has taken place, you you might, like, do a green or say saved. How do you tell the a screen reader that something has changed? Sure. Yeah. So you mentioned ARIA live regions. Those are a really helpful tool

for when you need to make an announcement, but you're not going to move the user's focus.

Because, like, actually, you know, what we call focus management, like, you've opened a dialogue, or you're working in a mega menu and you hit escape, and you need to, like, put the focus back to some other location, like, moving the focus will also announce something. So in the cases where you're typing and you're doing an autosave and visually you see a toast or, you know, some some visual notification that some action has taken place.

A live region is a way to basically pipe that text information to the screen reader.

So there's 2 levels. There's polite and assertive.

Polite will wait for everything else that's being announced, like other, you know, information about the that's being announced, like other, you know, information about the element that you're focused on or any other things that are happening with so sometimes it can be a little slow. Like, the announcement comes after everything else. Oh, yeah. Canadian mode. Yeah. I can't be.

So the, assertive will interrupt, but it will also stomp out any other announcements. Like, that's the only thing you will hear. So you have to be kinda careful with it. You know, you don't wanna, like, go put our, like, live regions like, assertive live regions all over everything. Like like any tool, you want to not overuse it. And so Mhmm. Being kind of mindful about usage where, you know, you have a single action, maybe polite is the fine setting for that, another area where some user testing could be helpful, or at least heavily testing it yourself, like, trying to make sure like, I think the real question is, is this annoying or not? Like, is it helpful or annoying? That's kind of the big question.

Yeah. Sometimes you you try it out, and it's you're just saying too many things. You know? Like, that must be super overwhelming, to use this this thing. And I think some users are are used to it, and some users will speed the voice up, like, the pnpm x and are amazing at it. That's when when I watched the blind guy use an iPhone, it was just like

I think he had it on, like, 3 x or something, and he could understand it. Yeah. It's funny. My speed that I listen to is pretty fast. When I hear something slow now, I'm like, no. Same. I am listening to this quite fast. Yeah.

But, yeah, the funny anecdote I have about live regions was from a friend that worked at Facebook, when it was still Facebook. But the on actual Facebook, they have those chat windows that used to be docked. I don't know if they still are. I think now they shoot you off to Messenger. But when it was in the actual Facebook, like, desktop web UI, you could have multiple chat messages kind of docked to the bottom. And there was a a bug where it would auto announce, like, the how long it had been since the last message was sent. So it was, like, 9 minutes ago, 4 minutes ago, 1 minute ago. And it was just, like, popping off all of these automatic messages as, like, time announcements,

which would be really distracting from anything else that you'd be trying to do. So Oh, because the DOM was updating, so it reread it every time the DOM was updated?

Yes. And if you don't have a screen reader running, you have no idea it's doing it. This is the risk of ARIA JS that if you put these attributes on your markup and you don't ever turn on a screen reader, you have no idea that they're ruining everything.

Oh, man.

Even on the syntax website, I opened a bug with our the library used for Toast because it was doing some animation where it would create the DOM node and then add a class or something to animate it in, and then it would do something to animate it out. And it was reading the alert 3 times.

I don't know why I opened a bug, but I'm assuming it's because it was updating the the DOM 3 times. I don't think a class would trigger it, but contents would.

Or even if it's a or, like, a React rerender

might do it. Oh, yeah. Yeah. Because the DOM, even if it doesn't visually look different, a rerender It might be getting rerendered. Yeah. So those are tricky. Sometimes,

yeah, you get into scenarios where, yeah, you have to, like, make sure your live region is not part of the render tree so that it's, like, not getting like, say, you just can't avoid some rerendering. Maybe if you restructure your components so that this part is not getting rerendered over and over again.

That sort of stuff is like I love that. That's, like, super geeky problem solving that I am into.

I I did look into it, and they were using a role of alert. So, like, no ARIA, but then I I looked into what role of alert does. Oh, yeah. That is ARIA. Yeah. Oh, okay. But but it's not like an ARIA dash. Right? It's just a an HTML attribute.

Yep. And that's equivalent to ARIA live assertive and Yep. ARIA atomic true, which maybe the atomic part there is, is what's causing it to start again.

Yeah. You can change, like does it look at there's different parts of ARIA live regions that you can kind of play with the settings of those things. So the roles so there's Node states and properties. Right? So roles, you could put the role of alert on something.

Say something already has a Node, like, it's a role of dialogue or, you know, whatever the, like, role is that is implicit in the element.

The ARIA live version of that allows you to leave the role as it Wes, but also add this live region functionality. So that's why you have both Oh, okay. The roles and the properties.

And, yeah, there's all different settings, and sometimes they work differently depending on the platform. So take that take that with a great resolved.

JS there any other, like, ARIA attributes that are either neat or under underutilized or your favorite?

Rianne. Well, I guess the ones that I'm usually looking at, I I pull up the ARIA up the ARIA spec to make sure I use them correctly, because there's things like ARIA selected or ARIA pressed, that depend on what roles you're putting them on. So, like, I just did a code review of someone's pull requests, like, in the last, I think, the last day of the job I just finished up.

And they had put aria selected on something, but it didn't have the rest of the pattern that went along with it. And so that stuff's really easy to miss in reviewing it. You'd just be like, oh, yeah. That's interactive element. It's got ARIA selected on it. Cool. Ship it. I actually did pull up the ARIA spec to make sure that because I I confused those. So I guess my tip would be, like, double check.

Double check that you're using it right, that you've got all the parts. Like, what are the allowed roles for an RU property or state? You know, can I use this on any element? I'm not I don't remember.

I have to look that stuff up all the time. Just I'd rather get it right. But sometimes those, attributes can be handy for indicating the state of something, like ARIA expanded, or ARIA has pop up, I use a lot. Some of them don't really work that well. Like ARIA controls, unfortunately, doesn't work that well. I guess another tip would be to look at, gosh. What is that? It's like the can I use for accessibility?

Yeah. I was just gonna ask about this. Yeah.

It's a one one y support dot I o, and it's a community driven, like, can I use for accessibility, basically? That's neat. So you could contribute to it. That would be awesome, because I think it JS, like, you know, like any community effort.

That's where the data comes from. So Node everything will be covered in there, but sometimes that can give you a sense of, like, oh, this ARIA attribute is in the spec, but it's not actually well supported at all. So

it might not hurt anything, but it might not do what I expect either. Can I ask now I'm just turning this whole podcast into my own personal, I the only reason I invited you on is because I wanted free information? So you have a field set. This is something I do a lot. I I have a group of fields that Wes the form is submitting, I wanna disable it so people can't resubmit it or or change some data while it's loading. And I've been told that you shouldn't use that, you shouldn't pop it disabled on a form while it's loading because it I don't what I don't know what happens. Is is that not a good thing to do? I have heard that as well.

Yeah.

I I think enough people have said it that I definitely sort of like some some thought to that feedback. And I think there's other ways that you could, like, make it so you can't double submit the form. Like, disable the callback function that's attached to like, if you're doing a client rendered form submission, just, like, do it in another way where you're not relying on the disabled attribute. Because I think it does have, potentially and I have to test this. But it might have effects on the accessibility tree, where, like, all of those elements are not readable, or you can't tab onto them anymore. I know that for a fact. Yeah. And if what you're trying to do is prevent submissions,

then maybe there's some sort of, like, a flag you could set that's like, hey. Is it it's submitting, like, a state variable that, like Yeah. Once you've clicked that, it's submitting, so you can't like, the callback will just bail out after that. Yeah. Awesome. Well, I like that answer a lot because it it sort of cements the whole, like, tools over rules is Mhmm. You Wes it. You know? Yeah. Yeah. A lot of these accessibility things are just rules that people like, mantras people have, and that's good to a point, but you should also test it to see if that's actually true.

Totally. Yeah. I know. And even mantras I've had for a long time, I have to go test them again because browsers improve, tools improve. Mhmm. So screen readers improve. Like, you have to go test it again and make sure that's still true.

Yeah.

Like, don't use placeholder text was one for a long time. You know? Yeah. But, I'm pretty sure again, we should test it, but I'm pretty sure play a placeholder text without a label

is fine or, like, a hidden label maybe. Yeah. So that is an area where the tools improve because there were so many form labels that weren't label or form controls that weren't labeled, but they had placeholders.

It was kinda net gain for users to expose something. You know? It's like it had a placeholder on it, so why can't that be the label? Yeah. I don't love that, but I am happier that a lot of form controls, you can at least figure out what they're for now. And so what they did is they made placeholder part of the accessible name calculation specification, which is very geeky spec on, like, how does for how does, like, a form label like, does that win out over an ARIA label attribute? Or, like, how does placeholder factor in? Like, there's a there's a ranking of which one will win.

And my favorite tool for testing it is in Chrome Dev Tools, the little accessibility inspector. It's in, like, the elements pane over by styles and computed, like, down in that corner.

To kinda go into that toolset, there's an accessibility pane, and it will show you accessible name calculation, like which thing won, or is there an accessible name at all? So that tool like, whenever I show that one to people, they're it's like, woah. I didn't know this was here, and it is so useful.

Oh, wow. So you didn't Node about I knew about that tab, but I didn't know about the accessible name.

Yeah. So now you'll see placeholder. It's in there because they they added it to the pnpm. I I guess to deal with the fact that, like, so many inputs had placeholders but no labels.

Oh, yeah. So I just went to Stack Overflow. I inspected their input, which does not have a label for, like, the search. Right? Mhmm. And then it says Node, search. And then it it says okay. Well, obviously, it doesn't have a label, but it it says search. And it says, well, there's no ARIA label by, but there is an ARIA label called search. And then it goes down and shows there's no label, there's no title, there is a placeholder, There's no ARIA placeholder, and there's no title. So it's what? There's probably 6 or 7 possible ways that it could derive the name from.

That's neat.

Yeah. And they can like, sometimes you don't know which one's gonna win. So that's where standardization and specs come in, JS they give some order to this chaos of, like, it could be different in every browser or every screen reader otherwise.

So that that makes it a little more, predictable.

So we had talked a little bit before about job market stuff. And I I'm curious because being an accessibility expert in this role, what does the job market look like for folks wanting to get into accessibility work?

I would say, honestly, your best bet right now is going the general track and just having accessibility skills. Like, you can make an impact.

It's a really tough job market out there, and I've seen a lot of accessibility experts get laid off. I mean, a lot of people have been laid off in general.

If you're on that path of, like, trying to choose between, like, do I go the specialist route or, like, I really like development. Should I stay in general development? If you have the option, I would recommend general.

That's a personal choice, so it's really hard to say that's gonna work for everyone. But it's just tough. Like, that's how I've managed to stay in the game JS by getting better at my general development skills, because that's those are the kinds of jobs that I wanted and that I could get.

The job I ended up getting is actually an accessibility position. But at that point, I Wes, like, just I put so much effort into becoming a stronger developer in general that I was applying for general jobs and getting really close Yeah. Missing out on, like, the people who Yarn who are winning were like, they had more experience in the exact thing that that employer was looking for. And so there's just so many of us that have been looking for jobs that it's really hard to have the perfect background and the perfect experience for every single one.

And there's just not as much, like, opportunity for the a company to take a chance on you right now. Yeah. So you think the accessibility

stuff is a nice addition? It's a nice legitimizer into potentially getting considered for better roles?

Gosh. It's just so hard to, like, generalize for this, because it's so different for everyone. I just know that, like, so different for everyone. I just know that, like, I've seen a lot of accessibility specialist positions get cut in favor of tooling. You Node, people want to build more accessibility tools for some reason.

That's a very crowded space already, yeah, I guess I would pose it as a question. Like, if you're looking to get hired as you know, for a job, like, look at what's out there. Like, what even is available? Like, for some reason right now, I'm seeing a lot of design systems designer roles, but not engineering.

So, like, you have to kinda survey, like, what's out there, what are the trends, and then, like, figure out how you're gonna play that that game. Like, how are you gonna ride that wave? Because I have pivoted multiple times, and accessibility is something I just care so much about. Like, I can't turn it off. But at some point, I personally, I made this choice that, like, I don't wanna get too far away from actual UI engineering because it's what I love. And there's just I have I have work to do in building UIs, and so accessibility is, like, part of how I do my work, but I kinda corralled back from specialization and even from DevRel into engineering. And it was it was hard to pivot. Like, I was kinda the underdog in a lot of cases, but I persisted. So, like, don't give up. That's kinda Yeah.

It's kind of emotional thinking about it because I honestly almost gave up.

Yeah. I can help you. Me. Like, I have so much to say and so much to do, and I almost gave up. Like, it was so hard.

I had 2 back to back job searches, because the company I joined was great at first, but they got acquired.

And just yeah. It's super, super tough, and I know that people are getting knocked around. And in some cases, like, it's Node in in everyone's potential, it's survival. Like, you have to pay your bills. You gotta keep your house. You gotta feed your kids. Like, all that stuff. And so it's stressful.

So, like, what helped me was just really focusing on my North Star. Like, what am I gonna be the best at? What am I gonna, like, get out of bed every day and love? And I just I just kept laser focused on that, and it was super hard because I got rejected a lot. But I ended up getting a role that I'm really excited about. So just keep on it. You know? Like, really look deep in your heart. Like, how much do you have in the tank and in the bank to keep it going? Because it's tough, man. So, yeah, my heart goes out to anybody in that position. Awesome. Can you tell us where your your so you just got a new job. Can you tell us where you're about to start? Yes. I am joining Khan Academy on their front end infrastructure team.

With John Resig?

Yes. With John Resig, creator of jQuery.

Wow. We just had him on. He is awesome. He's the best. Wow. You know, I'm thrilled. Like, I congratulations.

That's great. Thanks. Yeah. I'm stoked. Like, the front end infrastructure team there, it's something that John created. We hear a lot about infrastructure teams. You kinda think about DevOps. Mhmm. But he created a front end infrastructure team that supports, like, across the company.

And so accessibility is a really great place to put that. So, like, I was really going for, like, design systems, front end component library type roles, because I could Yeah. Insert accessibility as just, like, a commonplace way of working.

Turns out Khan Academy actually is really putting a lot of effort into accessibility in the next few years.

So it ended up being this really good fit for me and sounds like for them, and so I could not be more thrilled.

Man. Yeah. Khan Academy JS, increasingly one of the I don't know. They've they've always been a cool company, but it just seems like they make great choices. So congrats. Yeah. Like, that seems like a neat gig because, like, not only is it a massive,

like, platform, but it's also multiple languages. Right? So you probably have to think about, like, how do languages and how do different regions Mhmm. Play into this.

Totally. Yeah. The last one I was just working on, I was working on some localization stuff, but it was in Adobe Experience Manager. So, like, very different tooling, but similar, like, thinking about the user. I was writing some custom implementations to, like, handle redirects and, like, you know, what happens in your, like, localization drop downs? Like, all those details were fun to work.

So it's interesting going into Khan because I'll be working on things that it could be in any part of the web application, so I'm pretty pumped.

Man, even math as well. That was one of my, my very first hot tips was using the ampersand times HTML entity as an x to close a modal dialogue instead of using an actual x because I like the angle of the x. Yes.

But a screen reader reads it out as multiplication sign. You know? Oh, yeah. You have to you have to make sure you put the the correct labels on it so that Oh, yeah. It is read aloud. It says, close the modal and not multiplication sign.

Yeah. That's where red aria label winning out might be what you want because you can Exactly. Yeah. That that was it.

Yeah. And then trying to localize that. Like, how then how do you localize your aria labels? So Yeah. Oh, yeah.

Man.

Cool. It goes deep.

Yeah. Well, let's move into the last section of the show we have here. I'm sure we could talk forever. There's there's one thing I'll tell the audience is Marcy's Twitter has a whole bunch of van life stuff, and she's a gnarly van that you you live out of or you sorry. You go on adventures on?

I've had multiple vans in my life. There was a Ford van that you might be thinking of that was in a past chapter of my life, and that one Wes, like, a a Wheeling Ford Econoline.

That thing was nuts. It broke down a lot. So I have a Sprinter van now.

I got tired of being stranded and having to buy a new transmission. So I'm in a totally different phase of life now with a Sprinter van and a toddler and a husband. So Oh, man.

We really, really like going out to wilderness areas and just, like, dry camping, riding mountain bikes and hiking. And yeah, that's one of my passions.

Yeah. I gotta get out there. I I live in Colorado, so camping is is something that we just keep talking about doing. We don't have a a Sprinter, but our friends do. So maybe we can borrow that and get out there sometime soon. It's so nice when you're laying in bed in your van and you hear the rain come down, and you're like, Yeah. We are dry in here. We don't have to put away a wet tent tomorrow. Yeah. Like, it's just I live in Washington Scott, so it really extends the time of year that you could be out doing things. Mhmm. And I I love that so much.

Sick.

Beautiful. Alright. Last section we have here is sick pick and shameless plug. Did you bring come prepared with either of those?

Oh, a sick pick or a shameless plug. I did not come prepared with those. I apologize.

It's okay. We'll tell you. So a sick pick is something you pick that is sick. It can be an item. It can be a movie. It can be anything in your life. Doesn't have to be development related. It can be a chocolate bar that you an object that you really enjoy, and then a shameless plug is just a plug.

Sure. Okay. So my sick pick, it's very top of mind, would be my electric mountain bike.

Oh. It's a Yeti 160 e, and I rode it, 41 miles and 6,000 feet of climbing this weekend. Wow. Almost killed the battery, but it survived. That was the game. It's Node how long can I make this battery last? Oh, man. Yeah. The e the e mountain bike. If you can ride bikes, the e Vercel. I was kind of a holdout, but I just it is the most fun I've had on a bike ever, yeah, for the bike people. It's a a Wes mountain bike, and I just adore it. So that's my sick pick. I guess a shameless plug would probably be for ESLint accessibility Scott, my online courses.

Beautiful. Yeah. Those are awesome. Wow.

Alright. Everyone, go buy the course right now. Obviously, you've you've heard from this entire, interview. Marcy's a real one. She knows what's going on, and, this is fantastic. Thank you so much. I I learned so much about accessibility on this one, and I felt like I had a pretty good handle on it. So I appreciate all your all your expertise here, Zane. You're so welcome. Yeah. There's always more to learn and, yeah, be nice to each other. You know? We're all in this together. I feel like I saw you ask a question on Twitter, and it just like I'm like, oh, man. Yeah. I just stay out of those Node. Because I just I how do you wanna spend your energy? You know? I wanna just Yeah. Do the work and not be talking about doing the work quite as much. It's it's a funky space because I've always asked God about this, and, like, you you can't necessarily say it publicly, but I guess here we will. It's like, there's a lot of people in the accessibility space that are not nice.

Yeah. And they take their aggression on or shaming of a website for not doing it. And then, like, anytime I ask about accessibility things, people are fighting nonstop in their replies. It's not good because it makes people not want to ask questions about accessibility because they come out slinging. Yo. Do you hate blind people? You know? Of course not. So they don't say that, but, like, that's the kinda the vibe I get from some of these people.

Yeah. And it's hard because these people care so much about making the web accessible to everybody, and it's it's a very important thing, but

can also be a bit of a turn off to to some people when you you come on too hard. It totally can. Yeah. I I have been there. I've been frustrated. I guess the best advice I ever got was, like, if I was shaming a website, someone said to me, it's not unique to them.

And I was like, no. Then I kinda, like, released my clutches.

I'm like, oh, you're right. And, yeah, I just tried to be more, I don't know, measured about it because it's just I don't know. I just kinda maintain a happier life myself that way and try to influence people in ways that, like, they feel good at the end of it and not, like, they've been scolded.

Yeah. Agreed. Yeah. Marcy, I read a a book called Supercommunicators,

and that, like, unlocked a lot for me in terms of, like, how you talk to people to impact change. And it's like, what doesn't impact change, and what shuts people down, and all that stuff might be an interesting read. But, definitely,

changed my perspective on things as well. That sounds useful. Yeah. It's not always easy. Like, in work life, I feel like I'd have do a pretty good job of it. I Node to do it, like, in the rest of my life too. I know. Yeah. Frazzled and dealing with toddlers and all of that stuff. Toddlers. Yeah. That's the problem. It's it's the toddlers. The toddlers. Yeah. I would Wes know that.

I was I was telling my wife that the other day. I was like, I can spend all day being polite to strangers on the Internet, but, when my kids are melting off to me, man, that is the hardest part of my day.

Yeah. Kids are crazy. Yeah. Like, forced smile that I do that just, like it changes everything. I'm like, I'm smiling. I can't you know? That's just the only thing that I can that comes out. So that's my device. That. Keep keep things positive.

Yeah.

That's great. Alright. Well, thank you so much. Appreciate it. We'll catch you later. Awesome. Thanks, you guys.