Video details

JavaScript Marathon: Developing Accessible Websites & Web-Based Apps with JavaScript

JavaScript
03.24.2021
English

"Developing Accessible Websites & Web-Based Apps with JavaScript" with Nicolas Steenhout
In the past, some accessibility experts would turn off JavaScript to test a site and deem it inaccessible if they couldn’t use the site. Things have changed. Assistive technology, including screenreaders, have come a long way and can interact with JavaScript, if accessibility has been kept in mind. Surveys consistently show that over 97% of screenreader users have JavaScript enabled. Not to mention people with disabilities that don’t use screenreader software and also have JavaScript enabled. Planning for (and maintaining) a noscript solution is not going to make a page accessible. If you develop websites or web-based applications and use JavaScript, this training is for you!
LEARN MORE at https://labs.thisdot.co/trainings​

Transcript

Hello and welcome to JavaScript Marathon, a full day of free online courses in some of the leading Web development technologies and concepts. I'm Sarah and I'm with the state labs and I will be your marathon host. Before we get started, we wanted to send a big shout out to our sponsor today, sinc Fusun, if you are looking for UI component suite, you should check out their essential studio platform. It includes over sixteen thousand components that were built from scratch. With performance in mind. They're lightweight and modular. The platform is really user friendly and devs find it quick to learn. It offers pixel perfect, built in themes that are available in material, bootstrap and fabric designs and an accessible, high contrast theme which, speaking of accessibility, all sync fusion controls are touch friendly and render across desktops, phones and tablets, which makes it a great tool for those using adaptive technologies. So if you want to make your devs lives easier and you're working with JavaScript frameworks, ASP.NET Flutter Blazer just to name a few, I definitely recommend checking out sinc fusion by visiting sinc fusion dot com. We have a ton of upcoming events, State of Angular is live next week, Thursday, April 1st. We have graphed you all contributor day is coming up on April 13th. And modern web state of application monitoring is live April 20th. Our monthly mentoring for Women in Tech returns on April twenty. First, for more information, subscribe to our newsletter, The Low Down for weekly updates or follow us on Twitter at the state labs. JavaScript Marathon is back in May, we have another round of incredible sessions with experts in the deaf community coming back on May 19th. Stay tuned for updates at JavaScript Marathon dot com. Our next session features Nick Stenhouse, welcome, Nick, to JavaScript Marathon. Hi, guys. Pleasure to be here. And hopefully it's going to be as fun as I think is going to be. I think so, too. Nicholas, how is an independent accessibility consultant? He will be presenting developing accessible websites and Web based apps with JavaScript. You can find Nick on Twitter at the Vroom. And with that, I'm going to let you take it over, Nick. Hello, everyone, so the first thing I want to say is that this is really an introduction to accessibility, an introduction to some of the things you can do with JavaScript and some of the caveats that we need to to keep in mind when we're doing that to get you started on this accessability journey. I want to tell you a story story about me going down the sidewalk. About two years ago, my service dog was pulling me. It was sunny and I had dark wraparound sunglasses as I came by a patio and outdoor terrace. There were a couple people talking to each other and one said to the other, Isn't it sad he's blind and in a wheelchair? So I stopped, turned around and I said, Yeah, yeah, yeah. But I'm not deaf. The thing is, most people seeing a service dog assume it's a guide dog because we don't know that there's different types of service dog than guide dogs, especially with the dark glasses I had on. It's it's an easy mistake to make when we're not familiar with. Disability with service dogs with all the wonderful things service dogs can do for us, whether it's a hearing dog, a seizure dog, a guide dog, a mobility assistance dog, so when you're going on your disability journey, keep in mind that there are things you know that you don't know and there's things that you don't even know that you don't know. And this is OK. The learning about disability is a process. You're not going to wake up tomorrow and know everything about it. If you do, just let me know how you did it, because that would be a wonderful thing to know. So a bit of background on me. I've been doing accessability for well over 20 years. I've been around the block a few times. I've done a lot of work in opensource. I was part of the core development team of Joomla. I've worked with WordPress and for the last 15 years or so I've been doing accessability consultation with large and small organization, typically auditing and a lot of training and a lot of planning, strategic planning. I run a podcast, strangely enough, about accessibility, and that's at a one on one. Why are you Élysées dot com? It's accessibility rules. I'm on Twitter a lot and I invite anyone who has questions after the session to send them at me and I'll be happy to answer later on. But first, let's talk about accessibility, a one one why you probably have seen that mostly as a hashtag, sometimes in domains and sites name. And if you don't know why, a one one why or ally stands for accessibility, it's because it's a numeral. Erm so we take the first, the first letter and the last letter and then we count the number of letters in between and there's eleven so we have a eleven Y for accessability. I've heard it say that a one one why is not very accessible, which is a fair comment, but it's also going back to the days of Twitter when we had 140 characters to say what we had to say. And it's kind of like grown and it's mostly adopted now. So we're talking about accessibility, but when we write about it, we'll see it shortened very often. Accessibility is good for everyone, but primarily we're looking at focusing accessibility on four primary groups of people. First is people with hearing impairments, whether someone is deaf or hard of hearing. There is a series of things we want to consider when we're doing accessibility. We're also talking about people with visual impairments, whether they are blind or have low vision or any range in between. We're talking about people with mobility impairments. So maybe somebody is paralyzed after a football injury or they had a stroke or any number of things. They may not be able to control a mouse easily or they may have tremors. That means that fine motor control is really difficult. And the final group we're talking about people with cognitive impairments, whether it's learning disabilities or dyslexia or dyscalculia or maybe it's a traumatic brain injury, maybe that kid that got injured playing football didn't get paralyzed. But they may have lifelong problems with concentration, with migraines, with memory issues. So there's a whole range of things that impact. Their ability to interact with the Web. We're also talking about every device, whether it's on a phone, on a tablet, on a desktop, but also on other devices, that maybe you and I are not as used to seeing. Folks who are blind often use a Braille touch device, which is like a small computer, like a laptop, but it doesn't have a screen. And either the output is through audio or through a strip of refresh, refresh Braille dots. There's a whole range. There's even people that surf the web on their TV and they may have accessibility issues there. So we want to keep in mind that when we build things, they're not all going to be on desktop with eight hundred gigabyte connection on a nice color, calibrated screen and all that. We're we're not developing things for ourselves. We're developing things for people. And I guarantee you that they're going to use and access your your assets, your websites, your applications in ways you never considered before. A large part of accessibility is making sure that build works for assistive technologies and perhaps the one you've heard most about is screen readers. Screen readers are complex applications for people with vision issues primarily. And as the name implies, it reads what's on the screen. It does a lot more than that, though. It allows interaction with the entire computer, whether it's it's logging in. It's booting up software, creating new documents, interacting with forms. It's a whole range of. It's a tool that allows people with disabilities to use computers, more and more people with dyslexia are relying on screen readers. So that's a different dynamic when you can see the screen, but you're interacting with the screen reader to it. So that creates another layers of of having to consider how are we doing these things? We have the keyboard is probably the one assistive technology that you are familiar with that you use every day. It started the first keyboard was in 90, in 1850. In the late 50s, someone who was the director of a school for deaf folks wanted to create a method for them to communicate with hearing people as quickly as hearing people could communicate. So that was the first iteration of a keyboard. And since then and now there's been about 50 different format until we have the keyboard, we know and love and sometimes hate as well. We're also talking about speech input, things like Dragon, naturally speaking. You may have heard if you heard a squeak, that was my dog that stretched and can't hear. So he's all right. But Dragon, naturally speaking, is a speech and put software. It does more than just we talk, it types. It's control and command the computer again, we're talking about being able to open applications, create documents, interact with the whole computer. If you don't have use of your arms, we're talking about sip and puff switches. So a method of controlling computer by puffing or sipping in in certain patterns in STROZ connected to a computer switch. We're talking about eye tracking. So you may have a camera mounted on top of your monitor. And depending on where you're looking on the screen, it will know what you want to do. If you blink your eyes, you might use that as a click on an interactive element or you may be able to control. Online, on screen keyboard, so there's a whole range of ways people interact with our applications, our websites that we have to kind of think about, and we're not expert in all these things. So what we have to take it back to is according to the standards, according to semantic HTML, and trying to keep in mind a few things that we're going to talk about during during the rest of this presentation. I should say that people are by far the largest minority on the Web. If we were in person, I would take a few minutes and ask you, how many people do you think have disabilities in North America? But we're not in person, so we don't have that. So I'm going to give you the answer, the latest report from the CDC council. Twenty six percent of people with disabilities with a significant disability in the United States right now. That's one in four person. That's a lot of people. Does that mean everybody on the Web right now that has a disability experiences barriers? The answer to that is no. There's. Probably not. Twenty six percent of people on the Web right now that have disabilities, that have barriers, we we won't argue that, but we don't have metrics. We don't know who comes to our website with screen reader. We don't know who comes to our website resizing their their browser window. We don't know who uses only a keyboard. We don't know these things. So the question we ask ourselves is, why should we spend time making our apps or our application or our Web pages accessible since we actually don't know? Typically, I ask people this, what's the oldest browser you support and what's the percentage of people coming to your website with that browser? And the answer is often 11 and less than one percent. I guarantee you, even though there may not be twenty six percent of people that have accessibility barriers on your website, there will be a lot more than one percent. So we don't know the numbers, but we do know that they're significant enough to make a difference. And besides that, it's the right thing to do. It's also probably a legal requirement for your clients to have an accessible website, but. Online barriers aren't just for people with disabilities. One of the things we talk about a lot is making sure that our sites have sufficient contrast so that the foreground contrasts well with the background. And we're talking typically for regular text, a contrast ratio of four point five to one. That means great text on green background is a no no. That's really important for people with vision impairments. It's also very important for us when we're looking at our website, at our website, on our phone outside in bright sunlight. If the contrast is not sufficient, we're going to have a problem finding it. We're talking about making sure that we create enough target space for checkboxes because people with tremors might have difficulty tapping, tapping. It's the same thing if you're trying to fill out a form, you're in the bus or in a subway and everything's moving and the target is tiny and you're trying to tap it is going to be difficult. So accessibility really is good for everyone. But let's talk a little bit about JavaScript, because this is JavaScript marathon, so we want you to talk more. We've got a brief overview about who it's important for, why it's important. Let's look at a few things around JavaScript. A long, long time ago, and maybe you weren't there then, but a long, long time ago, we used to say that JavaScript actually was not good for accessibility. In fact, a lot of the other stuff we were doing, the first thing we do is we turn off JavaScript and see if we could work the website. And if we couldn't, we'd say, hey, we are not going to even go further than that because your site relies on JavaScript and its board. It's not working. The fact is, today, 97 percent of screen readers actually support. JavaScript and this this is done through a survey of off screen reader users that's actually quite, quite important. It's run every 18 months, two years, something like that. So we have up to ninety seven percent of people with disabilities using assistive technologies, particularly screen readers that are, quote unquote, JavaScript enabled. This means we can actually use JavaScript to increase accessibility, we have to think a little bit about. What we're going to do, how we're going to do it, but we can provide additional information, we can provide warning for time responses, we can provide additional time instructions so we can do a whole range of things that provide more information, that control how the interface. Reacts and behaves in ways that are going to be more accessible. This is really, really cool. I think some of the things we can do is we can have progress far. But when we're doing a progress bar, we have to make sure we're indicating the progress and text. And this is where JavaScript becomes interesting because we can refresh the data fairly easily. So as the as the progress bar progresses, we can also change the data so it can be twenty five percent or 50 percent. And as it moves 60 percent. So that's going to provide information in a text based format that is available for screen readers to to actually know what the processes we have to think about focus management. So. When we're doing things like dynamic content to expand and collapse, or maybe we're we're using a single page applications where a lot of the interaction is driven by by JavaScript, we also want to use JavaScript to manage where the focus goes, because sometimes we place the focus in one spot visually, but the actual text focus is somewhere else entirely. So the. Experience becomes a little bit strange, especially if you're sighted and you rely on screen readers, then you don't know what's happening because you're seeing one thing, but the text analysis is very, very different. One of the things that. Is very important, is around keyboard navigation and. A lot of us developers are power keyboard users, we use the keyboard extensively when we're quoting when we're developing, but when we start using the web, we revert to using a mouse and keyboard. Navigation is super important for a whole range of people. Including screenwriter users, including people that may have tremors or prefer to use a keyboard because it's it's faster or less painful. Maybe you have RSI, you have problems with your thumb because you've used a mouse too much. So there's a whole bunch of stuff, probably, you know, that to move forward on a page, you use the tank to go backwards on a page, you use the shift tab to trigger interactive elements, whether it's a button or a form or checkbox, you would use either the enter key or the spacebar. And I have a challenge for you, probably not today, because today is a whole day of sessions and marathon and all that. But tomorrow spend an hour surfing the web without your trackpad, without your mouse using just a keyboard. And once you've done that, come back and tell me on Twitter, how was the experience? Were you able to get through all the elements? Were you able to actually see where your focus was everywhere? Were you able to just function relatively easily without frustration, without wanting to throw your laptop out the window? And if the answer is no, which it likely isn't. Then think about what you can do as a developer to make that keyboard experience better. Some of the things we want to look at is making sure we're using elements that have native focus. So focus on all elements, things like clinks buttons, forming elements, eye frames. There's a long list of them on the. Alija, I there's a link on the slide. So we want really to make sure we use these native HTML semantically meaningful elements. Unfortunately, we have a lot of framework, whether it's react or angular or view or the flavor of the month that actually will create elements using divs or span's or the element or any number of basically semantically non meaningful elements that we have to actually build to to make it work. So where am I going with this? Well, the first thing is wherever possible we use native element, but sometimes we don't have a choice and sometimes we need to be able to provide focus to keyboard users. And sometimes we need to be able to put programmatic focus on something. So. Providing keyboard access means if you use a different set of a link and you're coding it to behave like killing, one of the things you need to do is you need to make it keyboard flexible. To do that, you would add the TAB index attribute and you would put a value of zero on the element. This is super important. Don't build fake buttons or fake links or fake interactive elements without making them focus at all, because otherwise nobody relies on a keyboard, on a switch, on a screen reader, on speech input. Nobody will be able to interact with your element. The other time is, as I said, when we're focusing on managing focus in. CPAs or dynamic content or all that we need to be able to using JavaScript, put programmatic focus on an element, and in order of making that element focus programmatically again, we use the TAB index attribute and we give it the value of minus one. So those are the two values. What you want to use either zero for keyboard or minus one for programmatic focus. If there's one thing you remember from this presentation is do not use positive type index. Don't use that index one or two or three or God forbid, like I found on another last year type index four thousand three hundred and seventeen. Because what happens when you do that is you mess with the natural order on the page. And when you start doing that, you need to actually apply a tab next to every single element to give them the order and force that specific order. And that can create a very frustrating experience for assistive technology users and keyboard users. But it's also extremely difficult to get right. It's so easy to forget or skip one or maybe in six months. There's an update to the page and the updates. We write something and it breaks everything. So don't ever use positive tab indexes anywhere. You may think it's good. Think again. It's not. One of the things we can use JavaScript with is to improve the accessibility of modal windows. We don't have a lot of time, so I can't give you a live demo, but I do have a code been linked from the slide that actually demonstrates that. But some of the things we have to think about with more Windows model dialogs is they don't typically appear in the normal type order. So we make them appear or disappear depending on what happens with user interactions. It must capture to keyboard until the dialog is dismissed by the user. This is important because if you're using the de tab on your keyboard and you tab out of the model window, then you are interacting with the content behind the modal window on the page underneath. And coming back to the model is really difficult. So it's especially tricky for keyboard users. It's also tricky for a screen reader users. When the model opens, you want to set focus on the heading and you want to be able to close it with either the escape key or close button. So there's there's a few things to to think about. For example, you would create an event listener for the escape key. So on key press, when it's escape, you close the model. Which brings me to this idea of event handlers. We have two primary types of event handlers typically around, you might argue that, but basically we have device dependent. So something happens when you're interacting with a mouse or you're interacting with keyboard, and then you have the device, independent handlers which work with mouse and keyboard and whatever other means, whether it's speech input or sip and puff and this. This is important to think about, because when you're creating a device dependent handlers, then you have to think and do the heavy lifting twice. So wherever possible, use device, independent event handler like that, you will make your applications, your websites a lot more friendly to people that interact with it in many different and wonderful ways. Sometimes you're going to have some events that. You don't have a choice. There is no equivalent of things that do independence, so you would have to compare the the closest event handler possible. So, for example, you would pair on miles down with on key down and you would make your code work with both those events. This this becomes important because if you're doing something for miles only then you're excluding all the keyboard only users. And if you're thinking, oh, well, I'm going to make this accessible for keyboard users, but then it doesn't work for most users, then it's it's a little bit of a problem there. As you're looking at these events and everything like that, think about the purpose of what you want to do, not the mechanics. It doesn't matter if two different people approaching your site from two different devices and in two different. Needs of excessive excess assistive technologies. Doesn't matter if the method is slightly different, as long as the purpose, as long as they're able to complete whatever it is that they need to do, whether it's signing up for a product or getting information or reading a tutorial or whichever it is, think about the purpose rather than the mechanics of the action. One of the things you want to avoid is modifying default behavior. We do that, we have to do that when we're making a div behave like a button, so we're going to modify the default behavior because basically a div does not have a default behavior. It's inert. So we have to build it. We have to give it to roll. We have to give it. Next, we have to give it all kinds of things to to make it behave like a buttonwood so we can do that. And sometimes we do that on elements that. Aren't like this, so, for example, maybe we create and heading and we want it to behave like a button, so we will start marking it up like H2 with the rule of button and the TAB index and all the things that make it behave like a button. And suddenly when you're a screen reader user, when you rely on assistive technology, get to that to H2 and you're getting conflicting information. Is it a heading or is it a button? And what's happening? You're much better to use. Semantically meaningful HTML. So you would put an H2 unless the button in it, you still got what you need to do to get it done, but semantically it makes sense. And if for whatever reason, your JavaScript isn't coding, then you know it's still going to work. Dynamic content, some of the things we do a lot, whether it's expand and collapse, whether it's search results, whether it's any kind of content manipulation that is dynamic on the page. Going back to this, you've heard me talk about keyboard a few times. So the question is, can you trigger. The content with the keyboard, so can you expand and collapse only using the keyboard, and is the content that you're delivering dynamically, is that one itself accessible? Because often it's not. So we have to make sure that all the layers of what we're creating is accessible. Now, some of you probably have heard of why area, and if you haven't, you probably have been living under a rock or you've been using it without realizing it's called why area. And the reason it's called why area is because it is put together by the Web Accessibility Initiative. That's a branch of the W three C and area stands for accessible rich Internet application. It's a technical spec, it's available online, you can look it up, it's actually fascinating read if you're into standards and it came out before HTML5. It is a series of elements that allow you to make things more accessible. Now, HTML five, a lot of what we created in an area actually became superfluous because HTML five took a lot of of these ideas in with that in mind. I would ask you, but it's a bit difficult, but I think for a second, what do you think the first rule of area is? This is actually quite important, we we can recreate a lot of behavior change behavior, we can do a whole lot of things with area that really we shouldn't do. There was a report a couple of years ago put by an organization called Web AIM, and it's the Million Accessible Website Report. And what they did is they crawled the homepage of the first one million results on Google, and once they had that, they did an automated test for accessibility on that. And one of the things they realized is that when you had an area on a page, the page was sixty one percent more likely to be having accessibility problems. So here's a technology developed specifically for accessibility, which over the years has been used in such a way that it actually causes accessibility issues. So. In general, don't sprinkle area everywhere just to make it more accessible. Think about what you do. Some of it really comes back down to semantic no HTML, there's there's this thing that's going around in the accessibility community that a four year old knows about. Three hundred words in their maternal language. There's not even two hundred important HTML tags, so no HTML at least as well as a toddler knows their maternal language. That's that's really a basic skill. And when you start with that, then you understand the semantics and you understand how to use the different elements. A button is a button, a definitive why use a div instead of a button when you can use a button and you get all the heavy lifting of accessibility for free? It's all built in. There's another code pen that you can have a look at later on. It's that bit that Allawi force button hyphen div and it shows you the difference between using a div, using a button and all the things you need to do to make a div behave exactly like a button. You need about 80 percent more code than more markup to do that just from the female perspective. So that means that using semantically meaningful HDMI is good for accessibility. It's also good for performance. You can save maybe 60, maybe 70 percent of your pages just by using semantically meaningful HTML. I think that's when. But that said, we have we have ways we have reasons to use area to improve accessibility, and some of these things are to define rules. For example, if you have a search form, you can give it a role of search. And then suddenly that information will be accessible to screen reader users who are looking at the different form on a site, on a page. They will immediately know this form is the search form. If you're using tool tips, you can give it to all give a deverall of tooltip. Again, that's going to impart semantically important information. You can use rollover of alerts or roll of slider. The slider we had early on with the the the green bar we can use area to inform that equivalent in text. So there's a whole bunch of rules we can apply. We can rule button rule heading rule. There's a whole lot area is also. Giving properties and states to element, for example, if you have an input, you can define area required attribute and say whether it's true or false. So you can use that now in HTML five, we have the required attributes. So some people say just used required attribute. You don't need area required. Unfortunately, browsers and screen reader technologies, the way these things have been implemented, especially around for validation, it can have an impact in this case, using the area required attribute actually is better. We can associate error messages with inputs using the area described by attribute. And then we use an idea of of whichever paragraph has the error message provided that we're using a a unique ID on that. When we're talking about expanding collapsed content, we would put an expended attribute on the button that triggers that. So someone using a screen reader comes to that button. They immediately know whether there's extra content that can be expended. When they activate the button. We're able to hide specific things from assistive technologies using area hidden. Generally speaking, we don't want to do that, we want to provide the same content to sighted users and screen reader users, but there are some situations where this becomes actually important. And finally, we're talking about area life. You probably have seen that. You probably have used that as an area live is providing what is called a live region. So when content changes in that block of content that has area live on it, it is announced by screen readers. Live regions are really, really important for controlling dynamic content and letting screen reader users know something changed on their page. There's three values for it. There's area off. So typically that's not used very much, but it's something you may want to use. We have our live assertive, which is used a lot, but it is a problem in general. You don't want to use Arieli sort assertive because it interrupts anything the screen reader is doing to announce whatever it is that's changed. So one of the ways I've seen it used a lot is in in forms for validation, especially when you're doing online validation. You check that the email address is correct. And every time there's going to be a check on that until the email is properly form, you're saying, well, this this is not correct. So I have a sort of would interrupt the user typing in every single letter that they put in. So you're much better to use are your life is polite. This is really the best approach when you're looking at that. So. Let's open it up for questions for anything else at this point. This was a whirlwind presentation to give you a few ideas of things to consider and think about. So any questions out there? Thank you, Nick. This is an awesome presentation. We do have a couple questions. Let's get to the first one blue supergiant. Are there automated tools to utilize positive DTAP index? Would such a tool Maktab Index attribute better? I'm not sure I understand a question about automated tools to use positive type index, but really what it comes down to is don't use positive type index, just don't do it. It's it's really creating a mess for a whole bunch of users, particularly those who rely on keyboards. So just don't use positive type index. That's very good advice. Our next question comes from Amy. So if there's a semantic meaning or default behavior, don't add your own behavior as clarifying question. That's correct. So if if you're using an element that have built-In semantic meaning, whether it's a button or link, an input heading or any of these fairly typical HTML element, you do not want to add your own behavior to that because because as an assistive technology user coming to the element, you expect a certain behavior. So you come to a table, you're going to be told, hey, there's a table, there's seven columns, there's 15 rows, and you're going to expect a certain way to interact with this table. If you're changing the behavior of that, for example, you're using the table for layout instead of using it for a tabular data, then all that expectation is changed and you've increased the cognitive load of the user. It's making the page harder to use. Good advice. Another question from Amy, would you say that an auto suggest component that changes the number of elements that match based on text input would be a good use of assertive? Or would you still use polite? I would still use polite because. The assertive value of the region really means that the screen reader is going to interrupt what it's doing. So imagine someone is typing in your search box and a screen reader is giving feedback about what is being typed. So maybe I'm typing dog, but instead of dog, I wrote to God. It's important for me as a screen reader user who can't see what's going on a screen to get that feedback from from my for my technology. If the developer uses assertive, it's going to interact with every single key press. What's going on so suddenly it becomes difficult to know what you've typed. If you're using polite, it's going to wait until the user is finished. So maybe they'll type one letter at a time, wait to see what is being exposed in your search results or to complete. But maybe they just want to type the whole thing, the whole word really quickly. You don't know what that's going to be. As a rule, it's rather rude to interrupt people. And I know a lot of blind screen reader users that say the same thing. Don't interrupt my assistive technology because it throws me off my pace. Makes sense. Great. I think that's all the questions that we have at this time, but if anyone is watching this in replay or you have any further questions, we did drop Nick's Twitter handle in the chat. So go ahead and follow him. Let's continue the conversation there. Also challenge everyone to do the keyboard challenge. So try to navigate the web using keyboard only. And let's talk to Nick about it on Twitter again. I also dropped all of this code Penn links in the chat as well. So if you have any other questions with that, just keep the conversation going here or on Twitter. And we're so happy that everyone came. Also, we wanted to shout out from the chat that Nick's jacket is exquisite. Thank you. I have to second that. Your jacket is exquisite. Thank you so much, Nick, for being a part of JavaScript marathon. We really loved having you. We will be back. So we're coming back with Dustin Goodman. He's going to do a presentation on Geographic. Well, so don't miss it. Come back soon. We will be back soon. Have a great day, everyone. We'll see you soon. Cheers. Bye.