 Welcome to another episode of GUI challenges where I build interfaces my way and then I challenge you to do it your way because with our creative minds combined, we will find multiple ways to solve these interfaces and expand the diversity of our skills. And today's GUI challenge, we're building a pick list that I call it that because it's a list and you pick from it. One of them is a checkbox group and the other one is a radio group. We're going to study the markup that it took to get here, the interactions that you get through the keyboard and screen readers, and then of course how to throw a nice little coat of paint on there. But first, that intro, dun-dun-dun-dun-dun-dun-dun-dun-dun-dun. Look at this lovely interface, isn't it just so inviting to the 1990s version of you? I I really don't like lists like this. They just while they're super functional and, you know, very accessible. They're got all sorts of good qualities about them. They just don't look that great and they're about the most boring way to collect information from users. Okay, let's let's bring in some coat of paint. That's nice. And so now we can style and give something a modern appearance. We still have all the relationships in our in our elements that are really good. And let's move forward with talking about how we can have our cake and eat it too. We can have strong markup and get the information from this with JavaScript and also make it look beautiful. So first off, I have everything wrapped in a form and that's a lot of reasons to have things in a form, especially because a lot of the web, a lot of like what we're building today is your website probably drives someone to a form. Almost every website I've ever built for any client drives users to a form where we need to collect information about them and we need to know their choices. We're giving them some sort of service and they have to indicate what parts of it that they want so that in this case, they can select multiple. In this case, they can only choose one at a time. And these two particular input modalities, like they cover a huge majority of the form and inputs that we're trying to collect from people. And so we should make these really nice. So you can see that, like, I can click the entirety of this area to select this item. I don't have to aim for the super tiny little square that's, you know, appearing in there. And I think that's really nice. Same thing with down here. I can click anywhere inside of these. I can also use my keyboard. It's really important that your keyboard can move through these things and it makes sense. And there's information there for the screen reader and keyboard users to make their choices. Like, look at this little label. You wouldn't know what you were choosing here if there wasn't a little title that said flavor profile, choose many. So what's the right way to make this HTML so that we can support the interactions that we want from our users and make it pretty. So that's what today's GUI challenge is all about making these pick lists. And I'm just, yeah, they're a list that you pick from. They have different appearances and then different markup. The sort of facilitate different types of interactions that we want. So first off, I chose a field set. I love the field set element. I feel like it's one of the most underused elements in HTML. It has some really cool features. You can disable a field set, which will disable all the children inside of there. You can listen for events on a field set in JavaScript and it will bubble up all the choices. Like, look, you can either put a listener on all three of these input checkboxes or put one on the field set and just know which one is chosen because it bubbles up to the field set. There's a container. This is an input group. So of course, the group can receive the inputs and the events for it. It's just all makes sense. Plus, it's got a really rad element that goes inside of it called the legend, which who doesn't want to be a legend. If I was this element, I'd be like, I'm the coolest of all of the elements. Plus, I'm waiting for us to get an element called dairy. Oh, here, let's see dairy, you know, and then we could do legend dairy. OK, maybe that joke is not good. You have to see how I met your mother to even know what that joke is. OK, whatever. So the field set and legend, I really like this because first off, we get the cool events and the cool kind of grouping and handling from the field set. We get this legend that can inform anybody about what this input group is asking from them. And I think the only bummer about the field set and legend is that it comes with some kind of weird styles by default. Like, let's go back to looking at those. Like, I think this is what initially turns people away from the field set legend is like, oh, I hate that border. And what's this floating little label thing? And then it's maybe kind of hard to style at times. And I don't know, I just think that like there's this hesitancy from the past of dealing with the field set. And anyway, you can get rid of it. It's totally just a style thing. It's a coat of paint thing. But the semantics of it are totally rad. OK, so next, if I've got a field set and a legend and the legend saying a list of items to select, I have a label here. And when I put an input inside of a label, what I'm doing is I'm creating an implicit relationship. There's two different types of ways to associate a label with an input. There's implicit and explicit. Implicit is when the input is inside of it. And that means they're naturally connected. The label and the contents within it will be associated with the input to a screen reader. And that sort of information is really helpful for mouse users also. Because look, I can hover over the text and still select the element, the input that's inside of there because of the implicit relationship. The explicit relationship is one where you choose an ID for your input and your label says it's for that particular ID, which we do in the tag list. Tag list is an explicit relationship. We have an input with an ID called light tag tag list checkbox floral. And the label says it's for that particular item. This is something where a framework can be really nice to do for you. Is kind of manage these relationships. You just program at once and it always stays attached. But anyway, that's implicit versus explicit label and input relationships. And I think those are really cool. So first off, I chose to list to do mine here in an implicit relationship. So my input is inside of there. I don't have to give an ID. It does have a value and it has a name. Now what's critical about making a checkbox or a radio group is the name. They all are going to have the same name as you can see here. Light pick list. So now as I interact with these, these are all toggling values that are going to be able to be retrieved as a group based off this name with a radio group. So let's close out this one and check out the pick list that's a radio. Again, I've an implicit relationship. The only difference here is type radio. Same thing. We have a unique name for all of these items and look at what a radio group does. That is pretty cool. It automatically unchecks the previous one, maintains all the state for you. And that is pretty cool. Now that's not all that you get with these. The keyboard interactions are also really interesting between a checkbox and a radio group. So I'm going to tab into my multi-select checkbox group here and I can just toggle these on and off with spacebar. Really nice. And if I tab again, I'm going to leave the group. That is not how a radio group works. If I hit tab again, you may expect it to go to choice too. But that's probably because you don't use a radio group with the keyboard very often. The actual interaction that you do here, I'll show you if I hit tab, I bounce. I bounced down here to the next input that could receive focus. But what's interesting is if I go shift tab and go back up, I use my arrow keys to make my selection. And that is how you choose with inside of a radio group. You can also hold the arrow key button and it stays trapped. In this case with Chrome and I believe in Firefox also, they are cyclical or if I hit the end with my arrow key, it sends me back to the beginning. That's really, really cool stuff. And it's also really annoying to build in JavaScript. All sorts of different factors to consider if you're building an interface like this. And there's also one more cool thing that you get with the radio group. So the state is maintained by the browser, blah, blah, blah. I mean, there's all sorts of cool stuff. But if I tab out and I tab back in, I'm put right back to where my focus was on my last choice. This means that the state, you could build like a carousel out of radios, things where a position that a user has made and interacted with something is persisted through the lifespan of this group. Really, really cool stuff. And then we can take that same markup. And well, I showed you that it's very similar markup. Instead of an implicit relationship, I've done an explicit relationship down here. And I have a checkbox group. I can go through and mark all these items. And then if I go into the radio group, of course, hitting the arrows is going to be how I navigate my way around. And I get that cyclical. I mean, that's just kind of cool. It's like roulette. I wonder if I could like let go and have it go tick, tick, tick, tick, tick, piney. Ah, then it's like a wheel of fortune chooser. So anyway, let's go back to the markup about this one. So we're looking at a label. This is our checkbox. Let's look at our radio group again. So this time I have a div inside of the field set, which is totally a great way to separate and divide your items. It's called tag toggle, and it has an input and a label. Now, if we look down here, the input and the label, well, I don't even see the input. Do you? You shouldn't. But it is there. And if I tab down here, what I'm actually tabbed into right now is the input, not the label. So even though they're right next to each other, and even though as a sighted user, I really only see the label and don't see the input. The input is what's focused. And it's the thing that I'm interacting with as I toggle it on and on. So there's a checkbox behind the scenes here, holding this state as I toggle this in and out. And that's really, really cool that I don't have to manage that. That's just, again, built in there. And I can retrieve the values when I'm ready to submit the form. And if I go down into the radio group, the same thing, I have an input and a label that are being stacked on top of each other. And so let me show you how I stacked these, because I really like this layout technique. So if I pop into here, I look at this particular item. So I've got an input and a label inside of this tag toggle. Tag toggle is set to display grid, and everything inside of it is set to grid area one. And so if I hover on both of these, look, you can see that they're stacked on top of each other, no position absolute, intrinsically sized. So if I extend the side, like the text in here, peachy, keen, and rad. Everything comes with it. The input is still spread across the entirety of that space, and I can select it and deselect it. So it's kind of cool. I like that grid pile technique. You've heard Yuna and I talk about it. It's in a ton of my demos. It's one of my favorite ways to put things on top of each other these days is with grid. And in that simple little grid area one to one technique, you're saying, hey, go into row one and column one. And if everything is going into the same row in the same column, you really only have a single cell and they stack on top of each other. Super cool little feature. Okay, so we've got the markup here for these. It's looking good. The implicit relationships, the explicit relationships. We had the IDs and the fours. Let's talk quickly about getting your values out of this form here. So let's see, I've got my console down here. I've named my form or I've given it an ID of pick list. So check this out. Did you know that everything that has an ID can just be referenced by like window pick lists? You can just give it the window name. In fact, you don't even have to write window. You can just say pick lists. And there's my form element. Pretty cool. I can be to hover out here in the console and it highlights the entire element. But here's what's cool. If I say new form data and then I say pick lists, this is my form element that will go grab all the data for that. And then I can say this is the cool one liner get all. And then what is this name of this group here? Here, this particular group is called light tag list. So I'll say light tag list. And I see all of the choices that have been made in that particular group. So not only did we get a really nice presentation, we're getting our data out of there. The browser is managing all the state. We've created a form that screen readers and all sorts of things know how to use. And that is cool stuff. So okay, what we're going to do next is we're going to go into the debugging corner and we're going to see how different browsers treat this form a little bit differently. So you can see what kind of like conveniences and things to browsers bring to the table when interacting with a checkbox group or radio group. The debugging corner, I love being in here. This is such a cool spot. Look at all the different ways that checkboxes look. We've got different looks for radios. In fact, one of the things I like is see how that scaled up as it focused in. And then as I hold a spacebar, it squishes down to sort of indicate with focus that this thing is being toggled. It's acknowledging your interaction. I totally got it from video games. And you can come down here and see it in these ones. Let's see, we'll get down into these. Again, you see it expand. I can hold spacebar, hold spacebar. Super cool. You don't see it with mouse, which is totally fine. It's just a spacebar interaction. But notice over here in Firefox, I don't see that animation. They don't really apply it to the inputs there, but they do inside of these ones. Different browsers doing things differently all good. And then if I go into the radio list, I can hit the end and go back to the beginning, just like in Chrome. Cool stuff. And on Safari, we get similar but different behaviors. So if I tab into these, you can see that we don't get that scale. We don't get the scale. If I do a radio group, they don't cyclically go back to the beginning. So if I hit my arrow all the way to the left, it's just going to kind of bump its head at the end of the focus group here. And then over here, it just kind of bumps its head at the end. I don't know if that's better or worse, but that's just how they do it. But it is still focus trapped, which is still cool stuff. And if I tab out and tab back in, it will restore that selected state. Then then we can see down here, these ones do bounce. And the offset is even like a little more exaggerated for some reason, like the offset of the outline. Anyway, kind of cool stuff. Boom, boom, boom, making selections nice and fun. And then down in Chrome, we got those different focus states. We can see the bounce on the different sort of buttons we have here, and then the cyclical roving UX that we get inside of here. And it's nice on Android and stuff, where even on iOS, where you've got like a really large finger that needs to tap those little checkboxes, it's so much nicer if someone allows you to tap the entire area. So be that developer that instigates that they have good hit areas to make your selections, because I think that's important. Okay, cool. Let's see. What else do we got to cover in here? I think that's about it. The color scheme properties, what allows these radios to be dark in this theme and light in this theme, and I think that's kind of cool to see it in there. And that's kind of it for this GUI challenge. I think it's mostly about seeing the structure of a radio list and a checkbox list, knowing what those interactions are like, being able to see the results of how these things work with your keyboard versus a mouse. And in fact, let's go look really quickly at the accessibility inspector tools and Chrome DevTools, just to see a little bit of what a screen reader might see when it's looking at these form elements. All right, I'm going to hit Command Option I to bring up the DevTools. I've enabled the Accessibility Tree tool here, and you can find that in the settings. Let me twirl this open so we can see what we've got here. And look at this. So imagine, here, let's just squeeze this so much, you can't even really see the UI anymore. You should be at least decent enough familiar with it to imagine it in your mind, but let's map it back towards the information that we've baked into the markup itself. So in case someone isn't going to use the styles and isn't going to, and of course, there's no JavaScript here, this is just the HTML. What are they hearing and what are they experiencing in terms of the content here? So the first one is that group. A list of items to select is going to be what's announced to the screen reader user. The legend is what informed that group. So the group is the field set, the legend kind of bubbled up its information to name the group. And we have our label text, and it's going to be read out to them as checkbox, item one, supporting line, text, lorem, ipsum, dollar, sit, whatever. It's going to read that out, but it's going to say item one, supporting. Notice how it took our text in here and kind of squished it into one big long sentence. There's probably some better ways to inform users about the different types of meta information you're providing about that particular label. But labels are a little picky. Labels will take any HTML that you put in and you're not supposed to put a div or any block level elements inside of a label. So I put spans and B tags to sort of bold the text or to have the text be just kind of free floating and then used display grid to sort of make them look a little bit more like block level elements. But anyway, that's an important thing to know is that inside of a label, you need to be using inline elements exclusively so that you can pass the validator, the HTML validator. I'll go down here to the next one. And the next one, a screen reader, these static text items, a screen reader can navigate across static text. So the user could find themselves on the check box and then move their virtual cursor over to associated text elements and hear those individually. So it's going to be on them to navigate as they want through this thing. Let's close this group. So that was the check box group. Here's a list of choices to make select one. Notice also it is a radio and it's going to be read out to the user as a radio. But it is nice to tell them in that label to select one. And that's something that as a sighted user, it's probably really obvious. You can see the radios, you can see the radio unchecking the previous one and checking the previous one. And it's, but it's nice though to articulate that to a user through the legend. And notice also that that legend is there, but I've hidden it on these particular elements. So let's focus on this one again really quick. Let's go back to our regular view. And here we have a legend. It's in the DOM, but as a sighted user and a keyboard user, I don't have access to it. And that's because I've given it height and width, zero and overflow clip. So it's visually hidden, but it's still present in the experience of the document here, which is kind of cool. I like this accessibility tree view. It's not bulletproof, but it's a great way to double check work. But again, always use a screen reader to go through your interfaces and learn at least one screen reader. I think that's a really healthy thing to do. So anyway, we can see that we've got more lists, more groups to go through. They're labeled a user could navigate by group. They could jump around. They have lots of cool ways to jump around a document, but it's nice when they're labeled. Well, you have good legends and you have good labels and regular inputs, and you're going to be pretty safe as you move your way into getting a user to convert into somebody who's going to pay. You got to make sure you can take their input from their their their fingers on their tiny glass screens, their keyboard, their desktop with a mouse, whatever way it is that they're viewing this, you want to make sure that you've built an easy to use, nice looking capture mechanism so that you all can go about building your businesses. So that is it. I'm going to uncheck the accessibility tree. I'm going to close out of this and I'm going to say goodbye. It's been nice this GUI challenge and I'll see y'all in the next one. Take it easy.