Episode 11
Kendall: it's definitely a process, like even I'll get designs and I think that I'll be able to implement them.
And then I get halfway through the design and I realized that, something's going to cause an accessibility issue and I have to go hash it out.
Andrew: Hello, welcome to the devtools.fm podcast. This is a podcast about developer tools and the people that make them I'm Andrew. And this is my co-host Justin.
Justin: Hey everyone!
Andrew: Today we have a great guest. We are joined by Kendall Gassner, an engineer that has primarily worked on design systems at companies like Intuit and Spotify.
During her tenure as a design systems engineer, she's participated in many open source projects, even creating her own and has become one of just a few hundred web accessibility experts in the world. Kendall, would you like to introduce yourself a little bit and what you work?
Kendall: Yeah. So I'm Kendall. I've been in the industry for about five years now. I'm currently working at Spotify on the anchor platform. So podcasts land, this is very familiar to me. And I am the creator of eslint plugin, no explicit type exports and accessibility snippets.
Andrew: awesome. So what got you into developing front ends? Why'd you choose that part of the stack?
Kendall: I guess front-end wise it's mainly because it's visual, I like being able to show off my work and have people in my family who maybe aren't tech savvy to still be able to understand what I'm doing and be able to see the contributions I've made to projects and be able to understand it.
Andrew: yeah, me too. Being able to show off a project has always been a love of mine. And then when I'm stuck in the back end for a while, people ask me what I'm doing. I'm like, ah, I can't really tell you. It's it's a little bit of wasted time.
Kendall: Yeah. It's weird cause like even sometimes friends. I'll explain it to my mom and she'll just look at me kind of dumbfounded and just smile and shake her head. But for the most part it's a lot easier to show them if you create a button on a page show it working and show that it's styled well.
Andrew: Yeah, our audience might not know how much work has gone into creating buttons, but me and Kendall can attest it's years worth of work.
Kendall: yeah, for sure.
Justin: a lot more complicated and people think.
Getting Started in A11y [00:02:12]
Andrew: The first thing I want to focus on is either get the work you've done with accessibility. Why is ally important to you and why do you think other people should care about it?
Kendall: I guess it just goes in line with inclusion. I think if we are able to create websites and products that anyone can use why wouldn't we make it possible for everyone to be able to use. Accessibility these days is pretty well-rounded and there were a lot of different tools that you can use to integrate into your website and make it understood by people who are blind, maybe use screen readers or have motor disabilities.
Just being able to add inclusion in areas that aren't often thought about. Nowadays too, we have so many products and websites that are saving the average person so much time.
If you look at turbo tax, taxes nowadays take like an hour to finish versus back in the day when they probably took two days to complete and by leaving out a subset of people we're not allowing them to complete those tasks faster and we're making their lives more challenging and they're already facing challenges.
Why would we not want to stop?
Justin: good to note for people out there too, that if you're not building accessible websites, you could be at a legal risk because I mean, technically you are supposed to make, some measure of accommodation regardless. So it's a good baseline.
Kendall: Yeah.
Andrew: I find it interesting that the same law that makes it, so businesses have to have like a ramp out front. So people in a wheelchair can get into their business is the same law that saying that your website needs to be accessible for people
Kendall: Absolutely. Yeah, that's always like the good way to get accessibility, the topic going at a company that might not see that as their immediate business need legal issues. But also I there's, I think one in five people in America with a type of disability and that's a huge group of people.
So, 20% of the population you're leaving out and could be your customer, if you make your product accessible.
Andrew: Yeah. And not only people with disabilities benefit from it, like just being a front end engineer and implementing keyboard navigation. Like I use my keyboard to use a website a lot more now. And if I see that a website doesn't support that I kind of question it.
Kendall: Yeah. My favorite story of that was a couple years back. I was working on a select component in a design system and I left out a feature where if you start typing letters, it will automatically scroll to that item and select it. And the amount of developers at the company that sent me direct messages saying, "Hey, I can't use your input or your select anymore."
Was kind of crazy. So you're right, it's definitely used by a wide range of people and it just makes everyone's lives easier to be honest.
Justin: what about the areas that are like harder, maybe not harder to test, but less obvious. So I feel like the keyboard usability thing is a good thing that developers generally will be able to catch, but things like how a screen reader acts on a site is almost its own sort of unique experience.
Right? You have to think about usability of this thing because it's one thing to say, "Hey, yeah, it says stuff on the screen." But it's another thing to have it make sense and actually a pleasant experience. What's your experience been with that?
Kendall: I definitely think it's harder at first to grasp.
One of the things that I see a lot of people do is over for it, you get developers, writing aria labels that are so explicit in what the button does when usually a button should, if it says submit.
And maybe someone who doesn't use a screen reader sees the submit on the website. It's very clear that button is going to submit the form. And then sometimes, when you're developing forms and submit buttons, you would think, okay, now I need to say this will submit this form in the aria label.
When all you need to really say is submit, you don't need to overthink it and use different labeling than visual users. So that's definitely one of the issues I think is harder to understand is just how that type of user, a screen reader user or keyboard nav user is working with the product.
And maybe the best solution for that is being able to do take me home with them and see them actually using the website and what they aren't being able to interpret versus what they are.
Andrew: I think a big part of that is a lot like accessibility tooling in general is kind of intimidating. Like I think most people, when they're building out the speech version of their UI, most of them are probably not using the built-in screen recorder. And then most of them probably don't even realize that the built-in screen recorder.
Isn't what people who use screen recorders actually use.
Kendall: Yeah, no, it's interesting. I think the most widely used screen reader and it could have changed, but I believe right now it's NVDA with a Chrome browser. But NVDA and then the second being jaws is they're only available on PCs. Not apple and most developers are developing with Mac books and using voiceover to actually go through and screen read check So, that's definitely something that's a problem. One thing that I've, I usually do in my day to day is I actually will keep certain Certain accessibility features on, on my computer. So I keep the reduce motion button on one, I just don't really like looking at loading spinners all the time, but two it's great for catching bugs.
I know. Again, a job instance we had a dot on the page instead of a moving loading button. So like, as you can imagine, if someone has reduced motion on and the loading spinner just looks like a dot. They're not really going to be able to tell that's a loading page. Maybe a better idea would just having the text say loading and not showing any animation at all, but definitely playing around with those features and trying where you can to get a VM and try jaws.
And NVDA out is always good too.
Andrew: yeah, you really have to treat them as almost like separate browser targets. Like you should be testing and Firefox safari and Chrome, but you should also probably be testing in the most popular screen readers too.
Kendall: Yeah and phones, I can't say that enough. Just with the sliding around they can pose their own problems. Yeah. So being able to turn on voiceover on your iPhone or oh, I don't know. I can't think of the name of Chrome's a screen reader for the Android phone, but being able to check those.
Andrew: yeah. Have you checked out Firefox is accessibility browser, it's the same as the elements panel, but you can go over to the accessibility tab and actually see what the computer might be seeing on the page. Have you ever.
Kendall: Yeah. So I think accessibility tools for browsers, my favorites AXE for sure. Just being able to run an ax test on your website page and see what the violations are. That's the best .Firefox I love it. I like the accessibility tree. It makes everything very clear and you can see what labels are attached to what and what aria attributes are attached.
That's also really nice. I gotta be honest though. I ha mainly developed in Chrome.
Andrew: I've actually switched to safari since going to my new job. I
know it's, it's, it's, weird. I don't know why I did it, but I definitely found a lot of bugs, so it's nice to develop in a different environment than your coworkers might, and you're definitely gonna find bugs.
Kendall: Yeah. mean,
IAAAP Certification [00:09:34]
Justin: So, you're accessibility certified. what does that actually mean? Who gives that certification? why are there so few people that are certified. in this and was there anything interesting that you learned in that process?
Kendall: yeah, so the certification I got was a web accessibility specialist and it's given to me by IAAAP, which is the international association of accessibility professionals. I honestly was surprised when I found out the number of people who have that certification.
I didn't realize that it was so few, but to be honest, I think it just is a lack of knowledge that there is a certification available. The certification itself I found it to be challenging. It goes over a lot of topics. You have to be able to find accessibility violations in maybe a code snippet.
You have to know the. The accessibility laws written by web content accessibility guidelines. You have to know some of the a tag rules, which is just another set of guidelines, a tag stands for authoring tool, accessibility guidelines, and you have to know how to use screen readers, all of them and all of the shortcuts, which was also very interesting, a lot of Quizlets that I went through for that. But it's been pretty cool, being able to learn all the Web content accessibility guidelines has been helpful in general, for determining which compliances we have to follow by law.
And then also knowing screen screenreader shortcuts helped so much just knowing how to like stop the screen readers from talking and all different readers and be able to, being able to navigate through a page has been really nice and helpful. But yeah, the test itself took me probably five, six weeks to study.
I went through a deque course, which was really helpful. It's actually a course written by I think the IAAAP people themselves. So it's pretty good for studying up and wanting to pass, but it was a cool course and it gave me a lot of ideas into how to fix some of our accessibility problems or even find accessibility violations that I didn't know were Errors at the time.
And then it also actually led me to create accessibility snippets because essentially after going through all the aria attributes, which is also something you have to know, so all the rules in our attributes associated with them and when to use them I realized they're really complicated and there's a lot of them.
So being able to make snippets for developers who maybe don't have the time to go through and, take the deque course or learn all of the aria attributes can easily add them to their code without putting too much thought into it. But yeah, it's a pretty cool course. Her certification, there's a couple out there. There's the web accessibility specialist and then there's also, I think a couple more general ones where if you're not a developer.
Because the web accessibility specialist one is geared more towards development. You can take a couple of the other certifications and still get certified in an accessibility area.
Andrew: so, since so few people are a part of that, like it's probably an unknown thing. What led you to wanting to take that challenge on?
Kendall: I first heard about the certification at, Intuit. And what Intuit does is they've created a way to help onboard people, onboard employees onto accessibility and help create ways for different employees to get involved and learn about accessibility. Ted Drake, he's the leader of accessibility at Intuit.
He basically has a system called accessibility champions where you can go through and complete different tasks and then get rewarded and get to the next level of accessibility champion based on the efforts that you've made at the company to help accessibility there's three tiers, it's accessibility champion one, two, and three. One is really a pretty simple it's reading about accessibility, learning about what kind of customers you might find when dealing with accessibility problems, and making your first accessibility bug fix or writing your first bug in JIRA.
Accessibility champion two is a little more complex. It involves teaching groups about accessibility. Becoming a leader in a certain field in way that involves accessibility. So like for me, it was the leader of accessibility in a design system. And of course, other things I know there's also outreach that you have to do.
And then accessibility champion three was more complex, but one of the things you had to do to become the accessibility three champion is complete the web accessibility specialist certification. So it's cool. Ted knew about the certification. He wanted people to be aware of it at the company and it encouraged a lot of employees to take the test and become certified.
Andrew: Yeah. For those who don't know him, Ted Drake is Intuit's accessibility expert and he is like, he's like the patron Saint of accessibility he's been doing it like literally for 20, 25 years started out at Yahoo and his only prerogative at Intuit. It was for a while before this accessibility program, literally just go from team to team and call out all their bad accessibility.
Kendall: Yeah he's amazing. He's opened a lot of doors for me and accessibility and will help you in any way you can. I know one day I was working on making a design system carousel that Andrew approved the designs for, and then left me to do no shade there. No, but I did, I was working on a carousel and I could not figure out the best way to make this design system carousel able to be plain enough to use in various parts of the product, but also accessible. Because having a carousel, you accessible, it has to be very specific and explicit in what it does. So he stayed up till like 10:00 PM, one night working with me for no reason. Like he had no name on the JIRA ticket, it wasn't his problem, but he really does try and help in any way you can.
Justin: That's awesome.
Kendall: Yeah,
Justin: I really appreciate the whole structure around that because I mean, for better or worse. Depending on, I think it probably really depends on the field that you're in too. Like how much you think about accessibility, but I mean, it is important as we build software, having empathy for our users and not leaving people out is an important part of what we do, but for better or worse, it can often be a thing that a few individuals come in and it's like, Hey, we should do this.
This is important. And then, it turns into sort of a grassroots effort. but it's nice to hear about a sort of, a structure for developing sort of accessibility, maturity in an organization. Probably something that a lot of other organizations that I know of could adopt
Kendall: You can be so good at accessibility, but at the end of the day, if you're one person at the company there's 30 other people merging code, you're not going to cover all your bases. You're not going to be able to review every single PR and things are going slip. So I think being able to teach others and make it easier on yourself and not have to review so much. It's definitely necessary, but I liked the approach Intuittook because there's, it's a reward system really. So it's motivating people to be able to learn about accessibility and then they, at the end, get a badge or achievement.
I think there might be like a t-shirt involved, but just those like small things really motivate , the beginning of learning. And then once someone first dives into accessibility and learns a little bit about it, I think it's hard to stop them from wanting to learn.
Andrew: yeah, they did the same thing with open source where Intuit has this badge system internally, that lets you game-ify whatever you want. So the accessibility learning tracks were gamified as well as the open source.
Kendall: Oh yeah. Any time you can get a little achievement next to your name little badge. It's always good, right?
Inclusive Design [00:17:26]
Andrew: So, you obviously know a lot about design, but what about the designers you work with? Has, have you had to help educate them in building inclusive design?
Kendall: Yeah, I think I honestly like carousel was a good example. That was a lot of back and forth because it's not so easy to be able to understand why, I guess with the carousel example one of the issues that came up was in a design system, you want the component to be flexible. So in some cases, maybe you want only one card to display on the page.
And then in some instances, maybe you want one card to show up on the page, but then you want a little like quarter of the next card showing to really signify that there is cards coming up and you can keep moving through the carousel. The hard part about that. Without having displayed none on a card, if you have focus elements inside each card.
So say you have a button inside the carousel, which I don't think is honestly technically a good use of a carousel to have interactive elements. But if you have an interactive element in a carousel and you don't have display none on the next card, then your focus indicator, your tabs going to move to that next interactive element.
And then everything's going to look funky. Cause all of a sudden you're going to be on like, like outside of the page on the right and nothing's going to be under your carousel anymore because you focused on this kind of hidden button. So explaining things like that are was definitely something that I had to do with design just because it's not something that they totally understood why it's, I don't see the button on the page.
Why, if it's not. Showing on the page and my tabbing to it. When we're just, hiding it off the page.
But just those things that are more focused on development and not explicitly a design problem, I can't think of another use case right now besides the carousel one, but it's definitely a process, like even I'll get designs and I think that I'll be able to implement them.
And then I get halfway through the design and I realized that, something's going to cause an accessibility issue and I have to go back to design and we have to hash it out. The nice part about the designers that I work with is when a problem like that comes up, they're flexible. If I'm able to explain the situation and show why it's not going to be usable at an accessible level, they're pretty good about wanting to switch the designs and make it better for everyone.
But yeah, just being able to show design or show anyone really what the problem is, and allow them to come up with a different solution. Or maybe if you have a different solution, explain different options.
Andrew: Two big examples I can think of from when I worked on the design systems team was the use of color. There's been multiple huge initiatives to make all the colors and all the contrast work at the various ratios. I think we even went from doing like AA certification to AAA certification recently.
And then the other big example was just focus states in general. Like for the longest time, we had this friction with the design team where like, we, you're not designing the whole thing. Like there's this whole focus pattern that we need to think of because that's like one of the main uses of our product.
Kendall: Yeah. With the color initiative I think one of the ways we got color contrast to be more at a design level and have design want to strive for different. A compliance or AAA compliance is by adding a color contrast or inner storybook. So we, what we did was we just took all of the Intuit colors and had to drop down menus and set and showed what the colors would look like next to each other.
Or we, you put typography inside a box and have one of the box outside color. And then the typography color and just put a red line through it and say, does not pass compliance too. We're really showcase that. But that was it tool because it's visual so they can easily go check the design themselves without having to ask us, or have having to go on Google and look it up themselves.
And then it just allows you to play with different colors and see them together.
Andrew: Yeah, that was a really good tool.
Kendall: It was cool. I mean, it's also nice to be able to know the exact compliance levels and a little fun math equation.
Justin: An interesting thing I've experienced over my career is that. Especially when you're developing a design system, you can tend to do it in small bits and pieces, but the overall sort of information density of a page can make things really hard. And, drive designs to have like smaller and smaller font sizes.
And, if you have a lot of information and you start leaning on color to distinguish things, and that's when, in my experience, color contrast starts becoming more and more of a thing. So that tension of like, well, we've built accessible like components for a design system, but then we like start smacking everything on the page and do custom things.
And, it starts getting less accessible, as the whole experience comes together, which is kind of a challenging.
Kendall: Yeah, I mean, you definitely don't want to draw attention to a certain component solely based on color. If it's a component that should be featured on the page and the main part of the page. It needs to be depicted in ways other than color. It needs to be very big on the page, your keyboard navigates immediately to that page.
Having a skip to NAF buttons, always good for that. Her skip to main content button, sorry. But yeah, I think another interesting issue that's come up in accessibility is having pages have too much content where we start to get into certain rules where it's really hard to gauge what is compliant, color contrast is easy.
It's 4.5 or 7.5 based on a text size, but when you're getting into readability of a page or complexness dyslexia comes into the mix making sure a page is easily understandable. Isn't always, cut and dry and it's not something you can use ax to test. It's going to be something that you have to really think about.
And it's is my page simple enough that your eyes are drawn right to the component that I want them to be drawn to or are different ads or navigation menus is getting in the way. And are they distracting to use.
Design Systems Foundations [00:23:38]
Andrew: So now having worked at multiple counties. So now having worked on multiple companies, design systems wha what do you think has worked and what hasn't? Are there major differences in the way Intuit's approached it versus Spotify? What are some common problems that you've seen?
Kendall: Things that I really like to think about, and I think should be thought about when first creating a design system is, think about making a project like you're open sourcing it, or like various companies might one day use it. think a common issue I see is flexibility with design.
I know that sounds funny because design system, you want to Create a component and have it be a certain design and not flexible. So people can just bake it into their projects, but sometimes one product's color choice might be different from another products color towards, or maybe there's things like border radiuses that need to be, slightly less sharp, but then another products.
So having the flexibility to to edit certain features is always good and not making a component to Finite, I guess, things like props, spreading always good. So being able to use native HTML element prop spread those native HTML props is great. You're thinking of things like on change handlers on blur handlers that you get for free without having to write all of those props yourself.
Designed tokens. When I'm thinking about using various styles and being able to work with different product styles, I can use design tokens and easily take those tokens and replace them with other tokens per product. I, if you're not familiar with design tokens, they're essentially variables that you can throw into CSS and then replace them with different values.
As you see fit. It's a really nice way to theme your products and theme your design system.
Andrew: It's a great place to introduce variability into your design system without adding too much variability because the class, the classic argument of the two ends of the design system spectrum are, I'm not going to allow styles or class names, and I am going to allow styles or class names and the design tokens get you in a bit of a happy medium between the two.
Kendall: Yeah. And I'm one that I do, like class names within reason. You still want to ensure, for example, things like color, contrast and ensure that those roles are being provided by, but you do want flexibility. You don't want someone to create a whole new component just cause they don't want to follow your border radius.
Another thing that I think is important is slotting. I feel like I said that word funny. But using components slots. So if you have a button, maybe you have a text slot, so you can have any text added and it will show up in your button at the, in the area that you specify, but you can also have an icon slot.
So then you can say, I want my icon always to be the L on the left-hand side of the text. So instead of passing in children and having our using children and having the the developer using your design system component to decide where the icon is shown. If it's in front of the text, or if it's behind the text, you're actually explicitly saying that the icon slot is always going to be in front of the text.
I think being able in that's the opposite with what I said with CSS and having a lot of variability with CSS, but with slots, you're saying that a container component, like a button or a card, it can't have everything. It can have this subset of things that I specify and I'm going to place them where I want place them as the design system developer, but I'll allow you to optionally add them in. I guess like a, yeah, like a good use case of that is, is just a card component. Like maybe you want a title, a description, a subtitle, but you don't want, in some case, I don't know why you wouldn't want this, but you specifically don't want an image.
Andrew: Yeah, for a little more context. The slot system we developed for Intuit's design system. We w when we were developing it, we wanted people to use children more and more because that's the great part about react. You can just use components ensure you could have those as props, but what's really nice to have this HTML structure where you can, you still see the tree and can nest things how you want.
And that's what slots really give you the ability to do. So, going back to Kendall's card example, you'd have a card dot title component that you put as one of the children of your card component. Then it gets placed into the slot. The slotting feature is like something I think would be so cool to bring to react because it's actually part of the Dom already. With web components.
I'm pretty sure you can define slots in your web components and people can use them in much the same way you would have used ours.
Kendall: Yeah. I mean, I personally, I hate adding components through props. I think it's weird as a developer, when I'm using a component, I always want to add them as children. And also it makes props just in general, harder to read when it's all, when it's too much content, what like three or four props in my component.
And then I want the rest to just be children. But yeah. So in general it was easier to develop. I think using a component when it's slotted versus having the specific items come through as props, but you're still getting that, that feature where you're still limiting what is being put inside of your component.
Andrew: Yeah, I think the word you were looking for a minute or two ago was composability like
being able to compose all of the components is super powerful and that builds off the idea. You just mentioned where instead of having. A hundred top level props. You can have all these sub-components where their props are, their own props.
So you might only have like three or four on each level.
Kendall: Yeah. And then I think I mentioned this already, but another thing that I think is crucial to a design system is using native HTML elements where possible it, it goes hand in hand with accessibility. You're getting all of the accessibility features for free. You're not having to use as many aria attributes and you get a lot of functionality baked in for free.
So like with a select component, which I know has an ugly dropdown menu you still are getting all the keyboard typing and arrow navigation for free, which is actually pretty complex and not fun to code yourself.
Andrew: Yeah, I think selects are like one of the hardest UI components to code. And I, if you picked out a hundred UI developers, they probably wouldn't all say that, but it definitely is.
Kendall: It might be for me now that I've done carousel, I would say it's select and carousel. They're pretty close when you're thinking of a design system reusable, very robust carousel. If it doesn't have all the freedom and flexibility, it might not be as hard as select, but select you're thinking of for react portals, you're thinking of keyboard nav,, if you're having to implement like that tool tip feature where it's, it sticks right under the select box itself. You're having to think of a lot and develop a lot for such a small component.
Andrew: And acting different on mobile to like a
Kendall: Oh my gosh. Yeah. I didn't even think of that. So yeah.
Justin: I think, Devin Govett and some people at Adobe recently released or wrote this article about, select boxes. That was like pretty interesting. I'll include that in the show notes. But like Daniel Lu and some other folks.
Andrew: Yeah, one thing's for certain is I will never build one again. I will either reach to Adobe's implementation cause it's already open source or I think Radix UI also has a pretty good one.
Kendall: yeah. Didn't reach UI try and make one.
Andrew: I don't think reach ever got to that point.
Kendall: Oh, for those of you who've don't know, I guess, reach you eyes. A design system that has very bare bones, accessibility components that you can add to your own design system and add a different styling around it. I think they're a great way also to get that all the accessibility features without having to do them yourself.
So I know I've used them often in my design system at Intuit or our design system. And it's a really nice tool to have in your back pocket.
Maintaining Open Source Projects [00:31:41]
Andrew: So Kendall, you were one of the first women engineers at Intuit to contribute to open source projects. And you even created a few of your own what was your approach for you making that happen? Like what gave you the idea to go out and do that? And , what projects have you made?
Kendall: Yeah, I'm going to expose myself a little on this, but essentially it's on a team with four other developers. When I first made my, or when I made my first open source project. And what was happening was where you were in a tight script repo. And our design system was used by people who were writing in both TypeScript and JavaScript repos.
And we. Typically wrote our components in ways where we would have, a button TypeScript file. And then right after it, we would have the index file. And in the index file, we would export everything that we've created props functions, the component itself, anything in that folder for the component, we would expose in the index file.
And what I kept doing was I kept importing all of the types that I wrote, and then later exporting them in that file, which is fine at a TypeScript level. And won't show up as a bug in your code. But when someone who works in a JavaScript folder file wants to go and use your TypeScript file, they actually will end up getting there that says, if you had written code that said import. X from types and then export X later on, they'll say X doesn't exist. If X is a type or an interface what's this variable and we aren't seeing it. This code doesn't make sense. And that's because TypeScript will actually, when it compiles down to JavaScript, it extracts all the type imports, but it'll leave all the exports.
So if you've imported a type and then later exported it You, you will get the error, but it will only show up once someone's actually installing your package. And the first time I did it, it was one of those things where you just fixed. And then when it came up the second time, it was like, okay, there needs to be an excellent rule or something because I'm embarrassing myself in front of all my other peers.
And they're, there's not a good way to deal with it, but I was the only one that was exposing this problem. And after looking for a day, there was no ESPN rule that was created. So that's when I decided to go ahead and make an ESPN plug-in myself. I think justification for that is one.
We're not going to have people think our design system is not reliable when they're using our components, but to where you're learning ESL in and out, you're learning how the TypeScript tree works. They as tea tree you're learning what goes into making it ESPN and plugin, how ESPN is going through it, your own code in a file.
And you're actually becoming well-rounded in that realm. So you're able to easily add IES, lint packages and figure out how to do different rules later down the line. But that was a really cool project. I have a soft spot for ASA. It is tea trees but Yeah I enjoyed that project.
It was a different area that I had been I was working in mainly designed system land and react side. And so it was fun to be able to mess with something new and do a more backend of the front end side, I guess. So that's how I got into my open source world actually, where accessibility snippets came into play.
The idea technically came up after taking the certification, but it came from a mistake as well. I was looking through a code base and I realized that I used aria checked for saris in a spot that I think I was supposed to use already selected just by not knowing that there was both of those. And I was thinking how many people don't know?
When do you use already selected when you use already checked? I mean, do they know that there's like an aria. I think there's like an aria drag and an aria drop. I might not have said the exact name. Right. But all of these aria attributes, there's got to be like 70. I doubt most people know them all and when to use them.
So I wanted to make a open source project that made that easier. As well as reduce motion and CSS, which I think is the best part of that package. For you check it out. There's a little snippet that every time you type a media query for motion it'll automatically add the reduced motion line, but Yeah.
So I guess essentially it just came from not wanting to make mistakes in front of people, but I think the biggest takeaway is if you see a problem, don't just continually fix it. See if you can find a way to avoid the problem. And that kind of goes more with ESL, current rules and things like that.
But also don't be afraid if you see a problem in an open source project to go and make a PR because I'm sure the code owner rather have you make a PR than make it themselves.
Justin: Yeah, for sure. Have you gotten many contributions to any of your projects yet?
Kendall: Yeah. So one of the cool things that I've I did actually a couple of weeks ago was, at Grace Hopper is open source day. This year it's two days actually in the year, but I had my Repos open with issues tagged on that people could go and contribute to the accessibility snippets one was really cool.
Cause I thought that by adding snippets for new aria attributes and roles, people were actually learning a lot about those specific roles. And then the eslint plug and I actually got a PR added today, which is really cool. It ended up being importing X as different name from file. That was not thought of when I made that that specifically eslint rule.
It's cool to see people contribute. I'm pretty quick actually on reviewing too, because at my current job, I am working on my GitHub account. So I'm always looking at reviews and requests. If anyone ever wants to contribute.
Andrew: Don't open those flood gates. Kendall.
Kendall: know, Hey, let's work for meat. Well, lots of reviews, but let's work for me in the long run.
I don't know. I mean, it's still at that point where at least with the snippets projects, it's not that hard to review, but maybe the slim plugins, a little harder.
Andrew: Yeah. The power of ASTs are really fun once you stop being afraid of the word AST and like what that entails,
Justin: Yeah.
Andrew: power you unlock is really cool.
Justin: Yeah. I did some really bad things with post CSS, but had a really fun time doing it.
Andrew: Oh yeah. Post CSS. The team we worked on produced a package called post CSS themed, and that one holds a special place in my heart because literally every person on the team had contributed in some major way to this open source project.
Kendall: Yeah, it does. I mean, it also just feels good when your picture comes up on like GitHub, open source project and your names under it as a contributor.
Andrew: Cool. I think that about wraps it up for all of the questions. That was a great conversation, but now it's time to move on to tool tips.
Tooltips [00:38:16]
Andrew: My first tool tip of the week is something called flight control.dev. This is I don't know if it's a startup, but it's a product coming out from the people who have been developing blitz JS. And for those who don't know, blitz JS is a full stack react framework. So it has all you need to create back ends and front ends.
It's built primarily on next JS, but I think they recently moved away from that and have their own flavor of next JS going around. But what really makes me excited for this is one thing that next JS walks you into is serverless development. And while serverless development might be good for a lot of project, there's a lot of projects that still could benefit from also just having a server around. Flight control works out of the box is blitz JS and next JS, and lets you control your backend a lot more. Whereas with Vercel you're locked into how they want to configure all the AWS services.
You have a little bit more freedom to do what you want with this. It's still in pre-launch. I don't think anybody really has access yet, but I'm pretty excited for it because a few of the websites I have currently run on serverless and I've been getting some big bills lately and I hope this could help a little bit with that.
Justin: Yeah, that's pretty cool. It's nice to see more, hosting providers out there. I'm still a fan of like railway and some of the others that are like coming out. but yeah. Nice to see.
Being that we were talking about design systems and stuff. I figured I would pick out a few interesting ones. I stumbled across this Daisy UI, recently, so it's a set of components. That's very compatible with tailwind. so you get a lot of nice benefits from this. If you're already using tailwind.
For example, if you change the theme, the tailwind theme, it'll like update, colors and stuff that go along with this, which is nice. I was actually poking around for something like this because I am starting to get more and more into the elixir ecosystem. and I mean, elixer components are still largely like template driven.
It's not as component ties as like a rack UI. So you need some like more flexible. Daisy is a good way to co-opt some nice UI. if you want to. yeah, just, it's got a nice lot of cool components works well toe to. toe one, two, so that's fine.
Kendall: That looks really nice. I like their color scheme too, actually. It's interesting because both your guys' tool tips have like very much purple UI and I'm starting to realize that purple and dark mode is like the new norm.
Andrew: it does go well with dark mode.
Kendall: It does.
Justin: Yeah.
Andrew: you gotta get that like glowy neon effect. I think that's what they all strive for.
Justin: Yeah.
it almost seems the defacto like purple or blue.
Kendall: Think it's big in the crypto world, too, that kind of like color scheme. All right. This is like less beautiful to look at, but this is this is actually something that Andrew wrote back at Intuit. It's an open source project. Well, we all wrote it, but this specific hook that I want to bring up use keyboard nAV is really good or use keyboard navigation is a really cool hook to use in your design system or just in your front end project.
But it'll actually tell you if a user is navigating through the keyboard or if it, if they're navigating through the mouse and it will update as a user switches, but by doing that, you're able to hide focus, indicators, focus, rings, or show them. So if design, maybe doesn't want that focus ring to show up every time a user clicks on a component, but you still want that accessibility feature when a user navigates to components.
So they know that they're at the component and in the right spot, you can use this use keyboard NAV hook to be able to turn off that focus ring, or turn it on and please both parties.
Andrew: yeah, th this does exist as a built-in thing to the browser. Some of our listeners might know about focus visible, but the thing about focus visible is it's not supported in safari. And if you use focus visible in a style that also uses focus, your focus CSS is now broken. So this is a nice cross-platform way.
And then it also gives you a little bit more control because when you use focus visible, you might be surprised that there are still some focus rings around things, and you can't really control. So there's just lets you take control of all of it.
Kendall: Yeah.
Andrew: Lots of good little hooks in here. I'm excited that Adam and the team open-sourced it so
Kendall: Yeah.
Andrew: use them again.
Kendall: Another hook that's worth mentioning is used reduce motion. So most of the time you can use a media query in CSS to be able to toggle motion, but every once in a while, you'll want that feature specifically in your components. So you can show maybe different, like again, with the loading animation.
Maybe you want to show the loading spinner or show like a loading message. So having the ability to use a hook and determine if a user's preference for reduced motion is turned on, is it a pretty nice way to be able to cater to both needs.
Justin: It's awesome. And that's part of the design system CLI package,
Kendall: Yeah, it's in Polk specifically, but it's yeah, it's pretty nice.
Andrew: My last one for the day has nothing to do with design systems and is barely a developer tool. But it's a Cindra storehouse Mac app called lungo and I didn't think I needed it for the longest time, but once I bought it, I now use it all the time for various different things. What lungo does is it's a little toolbar app that lets you make it so that your computer won't go to sleep for a specified amount of time.
It could be an hour, it could be six hours. So things I use this on is like when I'm doing video processing stuff, if my computer goes to sleep during that time, it's going to stop all the video processing stuff or various different little things. And then looking at the website here, you can also use it for scripting.
So if you want to write a shell script and then make it so that your computer didn't go to sleep during a certain part of that script, you could do it with lungo.
Kendall: That's cool.
Justin: nice. Yeah.
Andrew: And you got to pay it forward to Sindre he's built like at least a third of the JavaScript ecosystem,
Justin: Yeah. Yeah. Single handedly responsible for a significant amount of like things that are running on the internet. That's crazy.
Andrew: And apparently the, same as in the, in swift now, too, he's a like a big swift guy and is even petitioning apple to change swift things. So he's always there
Kendall: Oh wow
Andrew: The unicorn
Justin: The unicorn indeed. Yeah.
So, we talked a little bit about design system components, making them open and making them public, can be hard to do that. Well, there's some tools out there to like help you display your design system, but lately storybooks got really good at this. and I ran across this component library from company a, but the components called medley. I don't know if that's the company name or if that's just the component Librarl name. but it's a really solid, it's both, it's a really solid representation of how to present, a design system within storybooks, and pretty well architected, component library. so if you're looking for inspiration, if you're in, we're wanting to build something, this is one of many out there, things to look at. I really like how they organize their components. things are really nicely co located. It's all very clear logical structures. Nice. be really interested to see what they did on accessibility.
I have not checked, but
Andrew: Yeah they use the same pattern that we were talking about earlier, where you use the children and like exposing components within the component. It's it's nice to see.
Kendall: Yeah, that is.
Justin: Yeah, I do think First-class support for slots to be interesting and react because like vue svelte web components, most of all the other component frameworks out there support that sort of
Andrew: thing.
Yeah. And it's not fun code to write like
Kendall: Lots of types,
Andrew: Yeah. It's the generics for that one we're not fun to get working.
Kendall: but correct me if I'm wrong. I think we open source that as well.
Andrew: Oh yeah. We, if you want to use the way we do slots, I think that's actually a part of design system utils that we released. So yeah. Anybody could use it if they wanted to.
Kendall: also code. I wouldn't want to rewrite, so.
Andrew: Yeah. Yeah. The next one I'm hoping that our former team open sources is fly out because it has no design system stuff baked into it. And it's just so useful.
Kendall: Yeah. We use react portal, I think on that, but it just it's streamlined. I find that a lot of people are still using z-indexing to overlay components. And I don't know, I think the fly out just does it really well.
Andrew: Yeah, portals are great.
Kendall: All right. Okay. This one's mine. So yeah, I touched on this earlier, but reach UI it's a design system written in react and just it's really clean for being able to add accessibility and kind of add your own CSS styles and just get that functionality for free. I think This is the, probably the only design system that I've seen that solely created for the purpose of accessibility in mind.
Correct me if I'm wrong or if you guys know of any
Andrew: there's a, there's a few other, like we mentioned earlier, there's one from Adobe called I think react aria, which is more like hook it's more like hooks that you use in your own components to make them more accessible. And then there's rec I think they also provide a component part of it. So you can mix their components with their hooks and get like accessible components for your company.
Justin: It's react. Spectrum.
Andrew: Reach is like the first one in public that I think happened. And I think it inspired a lot of the other ones.
Kendall: I'm a big fan. I think they do a lot of things. Well, and they really don't add any components without them being like thoroughly accessible and have all features implemented.
but yeah, I'd definitely recommend using them and they're really just base components for your own projects. So you can do a lot with it.
Andrew: yeah. They come out of the box real ugly, but that's so you can make them pretty for your company.
Kendall: They're not meant to be pretty, they're meant to be restyled.
Andrew: Yeah. My favorite one that they include and I've seen it in a few of the children design systems that have come out of this is visually hidden. Like it's just nice, super low level way to get a screen reader only text on the screen without having to worry about aria attributes or like IDs or any of that.
It's just like, it's just there for the people who need it.
What's your favorite from the set Kendall?
Kendall: I I think alerts really nice. The ones that I've used a lot is dropdown menu. And also I'm a huge fan of a skip nav link. I ended up implementing my own at the previous design system, but that I worked on, but any time that a website has skip to main content button, if you're not familiar with it, it's actually a hidden button that when tab two will show up on a page visually and allow users to skip and bypass all the navigation menus directly to the main content of the website.
So if you imagine you're a keyboard user and You're navigating through a lot of websites having to go through every single navigation menu is really tedious and tabbing through it and just to get to the main content of the webpage. So being able to add a skip to main content button at the top of your page can save a lot of time and save a lot of frustration.
Andrew: I agree.
Okay. Well, I think that about wraps it up for this week's episode of dev tools, FM. It was a lot of fun having you on here, Kendall. This was a great conversation.
Kendall: Thank you. was great being here.
Andrew: Be sure to follow us on YouTube and wherever you consume your podcasts. Thanks for listening.
Justin: Thanks everyone. Thanks Kendall for joining. Yeah, really appreciate it.
Kendall: Thank you.