00:00:00.000 --> 00:00:00.000 If you want to go on mute. I'm going to start and then I'll wait a few minutes and they'll start talking. 00:00:00.000 --> 00:00:30.000 Okay. 00:00:37.000 --> 00:01:07.000 Good morning and good afternoon everyone. Thank you for joining the webinar today, we will begin momentarily as people start to sign in. 00:01:36.000 --> 00:01:43.000 Alright, good morning, Good afternoon, everyone. My name is Mike Mooney I'm the digital marketing manager at TPGI. 00:01:43.000 --> 00:01:52.000 Thank you for joining us today really exciting about this excellent topic structuring accessible forms with Rachele DiTullio. 00:01:52.000 --> 00:02:02.000 I have a couple of housekeeping items I want to go through before we get started. First off this session is being recorded and we will email everyone the recording after the event. 00:02:02.000 --> 00:02:18.000 We have live captions available so feel free to use those as needed. And if you have any questions you would like answered during the webinar please use the q and a box or option that zoom provides, and we will get to meet as many of those as we can, 00:02:18.000 --> 00:02:26.000 after the presentation. And with that, I will let Rachele get started. Rachele. 00:02:26.000 --> 00:02:28.000 All right. Thank you, Mike. appreciate it. 00:02:28.000 --> 00:02:42.000 Welcome everyone to our talk today structuring accessible forums, I'm Rachele DiTullio I am an accessibility engineer with TPGI. And I'm also a certified professional in web accessibility. 00:02:42.000 --> 00:02:51.000 So, let me just tell you a little bit about my background, so you have an understanding of where I'm coming from. 00:02:51.000 --> 00:03:02.000 I have a picture of myself here on the screen in addition to the video, I'm a white woman with short brown hair. I'm non binary and use the pronouns she and they. 00:03:02.000 --> 00:03:10.000 I've been working in this industry for a while, I got my first job as a front end web developer back in 2000. 00:03:10.000 --> 00:03:27.000 And I worked in software development and website development for for several years before deciding to go to graduate school, to pursue a Master of Science degree in Information Studies, where I had a specialization in user experience design, and I really 00:03:27.000 --> 00:03:33.000 started to hone my interest in usability and accessibility. 00:03:33.000 --> 00:03:55.000 So after grad school I returned to doing UX design work and front end software development, but with more usability accessibility skills in my toolbox, I started to learn as much as I could, on my own about accessibility and testing and WCAG, and I 00:03:55.000 --> 00:04:08.000 decided to pursue some certifications from the International Association of accessibility professionals and in 2019 I got my first one the web accessibility specialist credential and then in 2020. 00:04:08.000 --> 00:04:17.000 I got the Certified Professional and accessibility core competencies, which leads to the certified professional web accessibility credential. 00:04:17.000 --> 00:04:34.000 And with that, I decided, earlier this year to switch from software development to being an accessibility engineer, and helping what I do on a day to day basis is help companies, understand what accessibility issues might be present in their code, and 00:04:34.000 --> 00:04:37.000 what they can do to fix it. 00:04:37.000 --> 00:04:40.000 Alright so let's look at the agenda for today. 00:04:40.000 --> 00:04:49.000 First I'll start with a little bit of an overview about web accessibility and what we mean by accessible forms. 00:04:49.000 --> 00:05:01.000 Then we are going to look at an example form and looking at in five different ways First we'll look at creating our form fields. Next we will look at grouping similar form fields. 00:05:01.000 --> 00:05:04.000 Then we'll look at marking required fields. 00:05:04.000 --> 00:05:16.000 Next we'll look at validating data formats. And lastly, we'll look a bit at handling any form errors that may occur. 00:05:16.000 --> 00:05:25.000 Alright, web accessibility. So, this is my definition here but web accessibility is the extent to which your website or web application can be used by disabled people. 00:05:25.000 --> 00:05:43.000 And what I have on the screen is a spectrum, basically a continuum from less on the left hand side two more on the right hand side. And I find this model, particularly helpful to think about with accessibility and disability that you know it's not a matter 00:05:43.000 --> 00:05:46.000 of is it all or nothing. 00:05:46.000 --> 00:05:52.000 We're really not likely to ever have a completely accessible site that never needs future work. 00:05:52.000 --> 00:05:59.000 We can always do a little bit more a little bit more to make our site more accessible as we get feedback from our users. 00:05:59.000 --> 00:06:11.000 But we can also certainly have a much less accessible site if we haven't put any effort or help into trying to make our sites accessible in the design and development stages. 00:06:11.000 --> 00:06:13.000 So just something to keep in mind. 00:06:13.000 --> 00:06:23.000 Just really considered concerned about the user experience and how well, someone who has a disability can use our website or web application. 00:06:23.000 --> 00:06:44.000 And with that, the best way that we know how to approach that is to try to use semantic HTML semantic HTML is a mix of a couple of things. First, we have our native HTML elements for a form you might have a label element here it says label, email, or 00:06:44.000 --> 00:06:51.000 you might have a link to another web page so I haven't a triple equals t PGI calm. 00:06:51.000 --> 00:06:58.000 And there are times when we need to actually extend those native elements, a little bit with Aria. 00:06:58.000 --> 00:07:09.000 And we can do that with some special attributes that we'll talk about in this presentation how we can sprinkle Aria through our native elements to improve the experience. 00:07:09.000 --> 00:07:21.000 So, I've got on the screen for Aria examples we have an input type equals text, and we have the ARIA dash required attribute with a value of true, and we'll talk about what that means a little bit later. 00:07:21.000 --> 00:07:38.000 And then I also have an example of a button control so it's a button, it's an ID equals menu, it might be for expanding your mobile global site menu, and it has an aria dash expanded equals false attribute, and this is another one that we can use to denote 00:07:38.000 --> 00:07:40.000 the state of a control. 00:07:40.000 --> 00:07:48.000 We won't be using that one in our example today but it is a very commonly used one so I wanted to call it out here. 00:07:48.000 --> 00:08:05.000 So what you're seeing now on the screen is a screenshot from a test website that I created for this presentation, it's called register your cat. It's a short form with a variety of different form field types input types and a Send button at the end. 00:08:05.000 --> 00:08:25.000 Mike if you could please paste the link to the code example Yep, so you can go to tiny URL. com slash register cat to reach this example or you can click the link in the zoom chat window, and we'll be looking at excerpts in the presentation from this 00:08:25.000 --> 00:08:43.000 full code example, but I just wanted to give you kind of a mental model of what we're going to be discussing code wise if this is what the, the end result would be alright so with that let's uh let's look at this form, in a little more closely. 00:08:43.000 --> 00:08:50.000 So the first thing that we would need to do is actually create some form fields and forms for form fields. 00:08:50.000 --> 00:09:07.000 I kind of use it as a shorthand to mean the two kind of basic elements of a form of a form field which is the label. And then the actual input. So labels, provide visible and accessible names to those inputs. 00:09:07.000 --> 00:09:22.000 And not only do we need to have those elements but we need to link them programmatically. And the way that we do that are with the four, and Id attributes which you can see here on the screen so I'm going to read out the code example so we have label 00:09:22.000 --> 00:09:32.000 for equals name, And that the name and then are visible labels cat's name and then we have the end label tag. And then we have input type equals text. 00:09:32.000 --> 00:09:49.000 Then we have ID equals name, and that name ID attribute matches the four attribute. And that's how those two fields become programmatically links. Now I want to call out another attribute that we have in our input and that is the name attribute, it's 00:09:49.000 --> 00:10:03.000 a little confusing because I also named this this in this input and label name, but basically name, the name attribute is required to actually send form field data. 00:10:03.000 --> 00:10:09.000 When you submit your form, and it's, you know, the ID and the name and the fourth. 00:10:09.000 --> 00:10:21.000 They don't all have to match it, or I should say the ID and the name on your input don't have to match but it is best practice or convention to just have those two attributes have the same value, and it makes it easier to kind of maintain your code and 00:10:21.000 --> 00:10:26.000 make sure you know what, what's related to what. 00:10:26.000 --> 00:10:31.000 Alright so let's look at our inputs A little more closely. 00:10:31.000 --> 00:10:43.000 As you might know, there are various input types and we've already looked at the, at one the first example here we have input type equals text ID equals name and name equals name. 00:10:43.000 --> 00:10:57.000 And we have a couple more examples that are actually in our example field so there's also a type equals email and we'll be using type equals, radio, and type equals checkbox to create each of the different input types that were looking for and what this 00:10:57.000 --> 00:11:15.000 does is it helps people who are filling out the form, enter the correct information, and know what kind of control is actually being used. So when someone who's using assistive technology encounters a text field that will tell them type equals text. 00:11:15.000 --> 00:11:25.000 If they enter the email field that will tell them, email, when they get to a radio button it will define itself is radio button and a checkbox as well. 00:11:25.000 --> 00:11:37.000 I've got a link, Mike if you could put the link to the input types in the chat there, there's a whole bunch of them. There's not just these few these are just the ones I'm using in this form. 00:11:37.000 --> 00:11:45.000 Some other types that you, you might encounter, or the search type URL or even tell for telephone. 00:11:45.000 --> 00:12:05.000 And these, In addition to identifying the input type for sister technology will see in some examples that it does the modern browsers will try to do a little bit of form validation based on on input type so for example if you had input type equals email 00:12:05.000 --> 00:12:17.000 and you didn't actually have an email type format and input in that form field, then the browser would would say please, please match the correct type and what will see an example of that later as well. 00:12:17.000 --> 00:12:20.000 So those are our basic input types. 00:12:20.000 --> 00:12:31.000 Now there's one other one that we have on the form that is it a little bit different format and that is a single Select menu or you might have heard it called the combo box or a drop down menu. 00:12:31.000 --> 00:12:47.000 This is an input that has multiple options and can be controlled using a keyboard and the down arrow or you can hit the enter key to expand the list and see all of the options and then select an action with an arrow key. 00:12:47.000 --> 00:12:59.000 Just like our input elements we have a label. And we have a four element in this case it's for markings because the name of our field is cats markings. 00:12:59.000 --> 00:13:08.000 And then we have a select element, and that select element has our ID markings that matches the for attribute in our label. 00:13:08.000 --> 00:13:24.000 And then we want to have various options in this combo box or drop down menu and we use the option element for that. And the reason I'm calling this out so specifically is these drop down menus are single select menus are often a point of contention in 00:13:24.000 --> 00:13:30.000 frameworks that folks are using to make that make their development easier. 00:13:30.000 --> 00:13:44.000 They're often kind of convoluted made out of non native elements trying to be marked up with Aria and it's not that that's necessarily wrong. It's just more complicated, and you do have to do more testing to make sure that you're, you have the proper 00:13:44.000 --> 00:14:01.000 keyboard controls the enter key. The space key, the arrow keys to navigate your widget. And a lot of times those things get forgotten so if you just need a single select drop down menu your best bet is to use a native select field with an option with 00:14:01.000 --> 00:14:18.000 option elements. And then you can do validation based on whether we can see that our default select an option has a value of know, so we can do our checking on whether there's a value selected for this, select box or not. 00:14:18.000 --> 00:14:21.000 And that's a pretty easy validation to do. 00:14:21.000 --> 00:14:22.000 All right. 00:14:22.000 --> 00:14:31.000 So, there's one other attributes that I want to call out that we actually need to put into our form fields. 00:14:31.000 --> 00:14:47.000 Depending on the type of data they are so it's the autocomplete attribute and let the autocomplete attribute allows you to do is it allows the browser to look at information that has been previously submitted in the browser with similar form field names 00:14:47.000 --> 00:15:05.000 or types and offer those as suggestions, so that folks with mobility impairments early just anybody doesn't have to spend the time typing out like your email address for example, most of us use the same 123 email addresses across the web and it can be 00:15:05.000 --> 00:15:18.000 really helpful when we come to a website that has an email field, and if it has autocomplete equals email it can offer us previous suggestions that we've entered in the browser and saves us some typing time but that's particularly important for for folks 00:15:18.000 --> 00:15:23.000 who, who have mobility issues and might find typing, to be arduous. 00:15:23.000 --> 00:15:30.000 We can look at an example of what that might look like. So this is the Firefox browser in dark mode, just so you know why it looks like that. 00:15:30.000 --> 00:15:47.000 So we've got a form field here your email, and inside the text box we have the letter D typed. And what we see below it is a an expanded list and autocomplete list with three different email addresses that all start with the letter D, and that makes it 00:15:47.000 --> 00:15:56.000 really simple I don't have to type out my full email address, I can just pick which of these is the correct one assuming it's one of these is what I want to use. 00:15:56.000 --> 00:16:11.000 And that saves me a lot of time and filling out a field is filling out a form, especially if you're using these, the autocomplete in multiple ways. So, one, you can have an autocomplete attribute value of. 00:16:11.000 --> 00:16:27.000 Yes. And you can put that on on any input text input, and it will the browser will attempt to offer a suggestion. Most people don't want that. But you can you can certainly enable autocomplete on any field that you want the ones that are most, the ones 00:16:27.000 --> 00:16:41.000 that are important and required for accessibility are the ones that asked for personal information. So you can see in the chat. Mike is his posted the HTML autocomplete attribute link, and this will show you all the different pieces of information that 00:16:41.000 --> 00:16:55.000 are considered personal information that you should allow the browser to store and offer as a suggestion. Email is one of those we also have name, which would be for a full name. 00:16:55.000 --> 00:16:59.000 there's also first name and last name. 00:16:59.000 --> 00:17:14.000 Then we have things like telephone number, credit card number of there's a large list of these autocomplete attributes, and it's a good thing to check against this list when you're creating a form to see if any of those any of the fields that you're creating 00:17:14.000 --> 00:17:19.000 might benefit from having an autocomplete option on it. 00:17:19.000 --> 00:17:27.000 Alright so that's the basics of creating our form fields. Now let's look at grouping similar fields. 00:17:27.000 --> 00:17:43.000 Similar fields are usually, things like a group of radio boxes or a group of checkboxes, but it doesn't have to be. It can be any group of related fields such as the form fields can comprising shipping address you might want to have those in a, in a legend 00:17:43.000 --> 00:17:45.000 in a field set for some reason. 00:17:45.000 --> 00:17:59.000 But mostly, mostly you always, you need to do it for groups of radio buttons and checkboxes so that they get a label name and a group name in addition to their individual label name which might not make sense out of context. 00:17:59.000 --> 00:18:14.000 And the way that we do that so we use a field set element and you can see here on the screen so fields that groups related fields often radio buttons and checkboxes, and then we give that field set a legend element and a legend provides a label for the 00:18:14.000 --> 00:18:15.000 group's controls. 00:18:15.000 --> 00:18:30.000 And in our example here we have a field set then we have a legend that says cats colors. And then inside the rest of the fields that we would put our checkboxes for the type of colors that we want to offer our user. 00:18:30.000 --> 00:18:41.000 Let's. So let's look at radio buttons and checkboxes a little more closely in their field set and how we make sure that they're actually grouped together properly so radio buttons. 00:18:41.000 --> 00:18:58.000 So on the screen I have a code example we have a field set has a legend, which says is your cat altered, meaning is it spayed or neutered. And then we have three possible radio button options we have Yes, we have no, and we have maybe. 00:18:58.000 --> 00:19:15.000 And what's important to note here is just like we looked at in are creating the form fields we have a label for Yes, and then we have an input for Yes. 00:19:15.000 --> 00:19:33.000 or control that was labeled No, that's really not enough context to understand how to provide an answer or an input for that question. So, when we use the legend, the browser will actually announce the name of it will announce that you're entering a group, 00:19:33.000 --> 00:19:51.000 it will announce the group name, and then we'll announce that name for the various inputs, so I'll say is your cat altered yes radio button is your cat altered no radio button, and then it will also provide the, the number of controls in the group so 00:19:51.000 --> 00:19:55.000 it will say radio button, one of three. 00:19:55.000 --> 00:20:02.000 It will let you know which one you're on and the number of the group so we know that there are three radio buttons and we're on the first one. 00:20:02.000 --> 00:20:18.000 So those are all things to consider when you're creating a group of buttons now, because radio buttons only allow for one selection you can't, it's not like checkboxes where you have multiple selections you only have one selection. 00:20:18.000 --> 00:20:33.000 We also have to use that name attribute that we talked about earlier, remember we had a name on each of our inputs, well for radio buttons you use the same name on each of your radio button inputs in order to group them into a single group. 00:20:33.000 --> 00:20:49.000 It's different with checkboxes it's not, not the same. Their checkboxes have their own values, but to group radio buttons you want them each to have the same name attribute, and that will that will allow a single selection, when the data is submitted. 00:20:49.000 --> 00:20:51.000 When the form is submitted at the end. 00:20:51.000 --> 00:20:55.000 Alright so let's, um, let's look at checkboxes then. 00:20:55.000 --> 00:21:12.000 So again, we've got our field set, we have a legend that says cats colors. And then we have various checkbox input types so again we have a label that says, black, we have an input type equals checkbox, with an ID and the name says black, and it has a 00:21:12.000 --> 00:21:28.000 a visible label of black. But again, black on it, its own if you just came across that input name would not necessarily provide enough context so that's why we have the legend, you know, it gives you a context for Oh black is part of cats colors white, 00:21:28.000 --> 00:21:32.000 brown, etc. However many options that we want to have. 00:21:32.000 --> 00:21:44.000 We can use a checkbox for that. Now, because multiple checkboxes can be selected. You want to have a different name for each one a checkbox is kind of like a text input in that case and it's the same. 00:21:44.000 --> 00:21:52.000 It's a single select on off you're either submitting a value or you're not. So you want to make sure that each of your checkboxes selected has a different name. 00:21:52.000 --> 00:22:11.000 And that again is purely for the form submission aspect of it. And again, it's, it's not required that the name and ID values match for your input, but it is best practice just to keep track of data and make sure that things are named properly. 00:22:11.000 --> 00:22:32.000 Alright, so now let's move on to marketing your fields as required fields. This is really important and it's easy, it's easy to get messed up and not quite understand what's what's necessary here so we're going to talk about both the visual aspect of 00:22:32.000 --> 00:22:50.000 marking required fields and then the programmatic aspect. So the first thing you need to do is provide some visual visible indication that a field is required for example using a star or the asterisk character is is a pretty commonly understood visual 00:22:50.000 --> 00:23:00.000 indicator that field is required, but that doesn't really have any semantic meaning for someone who's using assistive technology to understand that the field is required. 00:23:00.000 --> 00:23:13.000 So in order to do that, they're actually attributes we can put on our input on our select or text area to get that field announced at state as required. 00:23:13.000 --> 00:23:19.000 and that we have two options. First is the HTML five attributes required. 00:23:19.000 --> 00:23:34.000 It doesn't take an argument you can just put the word required. And then there's also Aria dash required with the value of true, both of those things will announce a field is required to assistive technology, but there are some other differences between 00:23:34.000 --> 00:23:40.000 the two that we need to discuss, and why you might want to use one over the other. 00:23:40.000 --> 00:23:43.000 I just want to point out at this point to. 00:23:43.000 --> 00:24:01.000 When it comes to radio buttons and checkboxes, there's not a real good way to make to have those announced as required. There is a method for radio buttons, but the best, the best practice for radio buttons, is to just have an option pre selected So in 00:24:01.000 --> 00:24:14.000 our example, we had the MIT, the not sure. Is your cat altered we had the not sure radio button checked by default so that forces, an answer. The user can obviously change it. 00:24:14.000 --> 00:24:17.000 That's why we made our default answer I'm not sure. 00:24:17.000 --> 00:24:21.000 They can change it to yes or no but that forces the response there. 00:24:21.000 --> 00:24:38.000 When it comes with checkboxes, there's there's not a native way to enforce selecting one or more checkboxes so what we have in an example form is our checkbox field name or legend actually says, choose at least one option. 00:24:38.000 --> 00:24:51.000 So we, we make that requirement known, but then we have to use JavaScript or some kind of service type scripting to enforce, an actual selection there's not there's not a native way to do that. 00:24:51.000 --> 00:25:04.000 Alright so let's talk about that required attributes. So we have, again we have our cat's name field, we have our input type equals text ID equals name name equals name, and then we just have that required attribute like we said that doesn't have to say, 00:25:04.000 --> 00:25:10.000 equals true or anything like that just required. And what that. 00:25:10.000 --> 00:25:30.000 What that does is it provides modern browsers. A, most of them will do some level of validation on that required attribute natively without you having to put in any kind of server side scripting or JavaScript or anything to do field validation if you 00:25:30.000 --> 00:25:45.000 mark a field is required, and someone submits the field with that value empty that field empty, you'll see, you'll see some kind of message like the one on the screen here so again this is from Firefox and dark mode, and we have the cat's name field is 00:25:45.000 --> 00:25:49.000 blank, and it says please fill out this field. 00:25:49.000 --> 00:25:53.000 So you you'll see some kind of error message, like that in the browser now. 00:25:53.000 --> 00:26:00.000 I just want to talk a little bit about why you might not want to rely on this. 00:26:00.000 --> 00:26:17.000 Well, we can get into that a little bit later but this is is not necessarily dependable and all contexts, so that's why we're going to talk about the ARIA dash required attribute as well, it basically does the same thing as, as the required attribute, 00:26:17.000 --> 00:26:25.000 except it doesn't provide any of that browser, modern browser form field validation on Submit. 00:26:25.000 --> 00:26:39.000 It's purely a programmatic distinction that you can use when you're creating your own error messages and you can say you can also use CSS and things to define things on whether they're true or false. 00:26:39.000 --> 00:26:49.000 So we really recommend using that Aria dash required equals true and we'll talk about that when we look at our form field error handling at the end. 00:26:49.000 --> 00:26:52.000 But just keep that in mind that there there's two ways of doing it. 00:26:52.000 --> 00:27:10.000 One is not necessarily better than the other but don't use both use one pick one and code to that standard, and you should be good, I, I want to point out one other Aria attribute that we can use it's very very powerful. 00:27:10.000 --> 00:27:20.000 So be careful. Remember the first rule of ARIA is not to use Aria if you don't know what you're doing. But there, there's a very useful attribute called Aria dash hidden. 00:27:20.000 --> 00:27:33.000 And what this will do is any element that has Aria dash hidden equals true will be hidden from assistive technology assistive technology and you might wonder why why would you hide anything from this screen reader. 00:27:33.000 --> 00:27:50.000 Well, if it's something that's purely decorative and might not make sense, and being spoken aloud by a screen reader other assistive technology. You might actually want to hide that and and that is the case for the asterisk that you use to denote a required 00:27:50.000 --> 00:27:51.000 field. 00:27:51.000 --> 00:27:56.000 When a screen reader announces this field it would say cat's name star. 00:27:56.000 --> 00:28:12.000 And that. Well, most screen reader users would probably figure out what that meant. It's not the same as programmatically requiring the field, using Aria dash required equals true, in which case the browser will actually the screen reader will announce 00:28:12.000 --> 00:28:27.000 that the field is required is as it state, it will say you know cat's name type text edit required. And you, and then someone who's using assistive technology will know for sure that that's what that means they don't have to guess what the star meant 00:28:27.000 --> 00:28:29.000 was that a typo. 00:28:29.000 --> 00:28:34.000 So we try to hide, you know, anything that's like a star like that or decorative elements. 00:28:34.000 --> 00:28:50.000 Sorry icons that you use to denote things like maybe a telephone number or something like that, you can use that Aria dash and equals true but just be very very careful with it you can see I have it on a in a span tag here it's it's around one little 00:28:50.000 --> 00:28:53.000 piece of text, it's it's very contained. 00:28:53.000 --> 00:29:00.000 You know you can easily hide your entire website from a screen reader if you put equals true on the body tag, you wouldn't want to do that. 00:29:00.000 --> 00:29:12.000 So just be very careful with that but know that there are contexts where you want to use it because you're hiding those decorative elements from assistive technology users who don't need to encounter it. 00:29:12.000 --> 00:29:30.000 Okay, So let's look a little bit at validating our data formats. And this is a little, little convoluted, you might not have a use case for this but but I do want to point it out because I think it's an interesting attribute that you you have access to. 00:29:30.000 --> 00:29:45.000 It's called the pattern attribute. And you can add the pattern attribute to an input element and use a regular expression for example to define the data format, for example, the format that you want a date and. 00:29:45.000 --> 00:30:03.000 And then in addition to defining that pattern programmatically. We would have some visible help text that alerts the user what the required format is they have to be told what what format to enter the data in, and not just be left wondering like, what 00:30:03.000 --> 00:30:04.000 did I do wrong. 00:30:04.000 --> 00:30:19.000 So, we can see here in our example, we have an input type equals text and we'll have a pattern that I'll show you in the next screen and then we're going to talk a little bit about how we programmatically. 00:30:19.000 --> 00:30:25.000 Let assistive technology know what that format is for for data entry. 00:30:25.000 --> 00:30:32.000 If they can't if they're not seeing the visible text on the screen. 00:30:32.000 --> 00:30:44.000 So for example, in our forum, we have a field for cats birthday, and the required format the required date format is month, month, day, year, year, year here. 00:30:44.000 --> 00:30:57.000 And you can see here in our input, we have the pattern attribute and then I've highlighted the regular expression that would enforce that date format you don't really need to know. 00:30:57.000 --> 00:31:03.000 Regular expressions or how to write them natively there, there's a link to a website. 00:31:03.000 --> 00:31:18.000 Actually, I'll put it. 00:31:18.000 --> 00:31:31.000 Also you know the pattern doesn't have to be a regular expression, it can be literally anything you could say, you know, you could put the exact date that you wanted in there not that you would but you know there's a lot of different ways that you can 00:31:31.000 --> 00:31:42.000 use the pattern attribute it'll, it'll match whatever you put in there. It's just very helpful that it can be something like a regular expression so it doesn't have to just be matching on a specific string. 00:31:42.000 --> 00:32:02.000 So, and now I've got a screenshot again from Firefox and dark mode showing our cats birthday field, and the format I have is 2019 dash 05 dash 26 so it's a new year month day, but we know from our required format that it needs to be in month day year. 00:32:02.000 --> 00:32:16.000 So what the browser has done the browser will do again some of that rudimentary form field validation for you modern browsers, and it will try to see if the data entered into the field matches the correct pattern. 00:32:16.000 --> 00:32:23.000 And so in this case it doesn't, and the browser shows a little message that says please match the requested format. 00:32:23.000 --> 00:32:40.000 But, you know, saying please match the requested format doesn't tell you what the format is. That's why we have to also include that formatting requirement, both in text and then we we relay that programmatically to users of assistive technology so let's 00:32:40.000 --> 00:32:57.000 look at what that might be like, alright so this is the ARIA dash described by attribute again a very very useful attribute basically it announces some text at the end of an input providing, whether it's an error message or help text, but just additional 00:32:57.000 --> 00:33:04.000 information about that field. So here we have our input type equals text it's our birthday field. 00:33:04.000 --> 00:33:15.000 And in the input we've added another attribute it's Aria dash described by, equals. And then we have a value of, help one it's basically a unique ID. 00:33:15.000 --> 00:33:33.000 And what that unique idea of references, is if we look below our input we have a bit of text that says birthday format, month, day, year, and we put our ID that helped one that unique ID on that, that text element of birthday format month day year, and 00:33:33.000 --> 00:33:50.000 that will get in, get announced to users of assistive technology. After everything else about the text field so it'll tell them it's it's text edit birthday format month day year and it'll tell you tell them that that's required format. 00:33:50.000 --> 00:34:09.000 As part of the, the full field name and state name role value, state, and we'll hear, I'll actually have a video at the end for you guys to experience this, because I know it's a little, a little hard to just follow code examples, but you'll have the 00:34:09.000 --> 00:34:11.000 slides to reference to. 00:34:11.000 --> 00:34:19.000 Okay, so let's talk about our last segment which is actually handling those form errors. 00:34:19.000 --> 00:34:32.000 So, as I said, you know, the browser can do some rudimentary form, handling but there are other things that we need to do to really make it as accessible as possible. 00:34:32.000 --> 00:34:47.000 And there's a couple of things there first and anytime there's an error in a field we want to provide a visible error visible persistent text error message and programmatically link it again using that Aria dash described by attributes so that after the 00:34:47.000 --> 00:34:55.000 field, the required field is announced it will tell them what the name of the error messages such as this field is required. 00:34:55.000 --> 00:35:10.000 The other thing that we can do is after the form has been submitted if it comes back with errors, we can use JavaScript to include the ARIA dash invalid equals true attribute on any field that say the cat's name field was left blank, we can say, or a 00:35:10.000 --> 00:35:22.000 dash invalid equals true because blank is not a correct correct format. In addition, say someone, we, we have our type equals email, but someone types. 00:35:22.000 --> 00:35:34.000 They don't type in a properly formatted email address the browser again we can put that already a valid equals true, and it will let the user know hey, what you entered was invalid. 00:35:34.000 --> 00:35:47.000 And here's the proper format. So, again, we've got our production value equals true and Aria dash described by those two attributes. So let's look at this a little more closely. 00:35:47.000 --> 00:35:50.000 Alright so the ARIA dash invalid attribute. 00:35:50.000 --> 00:36:05.000 Like I said, it just goes on your input so here's our fully qualified input with type ID name autocomplete are your dash required equals true. And now it's come back and errors that we have Aria dash an invalid equals true, and we have already a dash 00:36:05.000 --> 00:36:13.000 described by, equals error to, that's our unique ID and if we look below the the input field again we can see. 00:36:13.000 --> 00:36:19.000 I haven't highlighted our, our error messages email format is email@domain.com. 00:36:19.000 --> 00:36:34.000 And so that will get read to the user, when they come back to this email field that will tell them invalid and it will tell them email format email@domain.com so they understand what the required pattern is. 00:36:34.000 --> 00:36:53.000 And then I want to point out one other little thing that can be useful again it's using that orientation equals true we'll see in our example that we've used a little icon to also to denote an error message is just another way to flag something as being 00:36:53.000 --> 00:37:08.000 an error text. And we, again we're going to hide that icon, using Aria dash hidden equals true so you can see we have a span here with our icon class, which creates a little warning sign a little triangle with an exclamation point, but we put orientation 00:37:08.000 --> 00:37:28.000 equals true on that span so it doesn't get announced to assistive technology, you, you know, some folks will try to put in icons decorative, things like that using CSS, but modern browsers are starting or screen readers are starting to announce some of 00:37:28.000 --> 00:37:45.000 that injected content that's done with CSS so it's something you you definitely need to test if you want to inject it with CSS instead of in line. We certainly, we recommend putting your icons in line and using orientation equals true just to be sure, 00:37:45.000 --> 00:37:59.000 but just make sure that you you test how that works in your particular situation. So let's let's review what we need for error messages. So here's an example of what our error message looks like we have our your email field. 00:37:59.000 --> 00:38:13.000 What's been entered in the field is the letter D is the letter D three times so it just says DDD, it's not formatted like an email address. So what we've got below our fields, when it came back and error, it says email format, email@domain.com and we've 00:38:13.000 --> 00:38:33.000 got a little icon, denoting it as an error message. So, I said what we were going to talk about why we don't want to rely on browser verification and error messages and it comes down to, to this those messages when you have an error message, those messages 00:38:33.000 --> 00:38:45.000 need to be visible, and they need to be persistent. And they also need to be accessible to assistive technology and the problem is usually one of those things is missing. 00:38:45.000 --> 00:38:55.000 When you're using the browser based form validation, either. The message will disappear when they start typing. 00:38:55.000 --> 00:39:10.000 So they're not persistent, or they're not visible, or the, the message might actually start to change, you know, you start typing a valid email address and the message might change from email is required to email format is the email domain. 00:39:10.000 --> 00:39:17.000 com but that doesn't necessarily get re communicated to assistive technology. 00:39:17.000 --> 00:39:32.000 The other thing is, if you look across different browsers and how they handle these automated text message or form field validation errors. It's an inconsistent experience. 00:39:32.000 --> 00:39:44.000 So you you can't be sure that someone who's say using your forum on an iPhone is going to have the same experiences someone using Chrome on a desktop. 00:39:44.000 --> 00:40:00.000 They're just different ways that these browsers implement those messages, and there's no really no way to style them. There's no way to increase the font size or do anything specific you don't have a lot of control over that, of what the browser is doing 00:40:00.000 --> 00:40:03.000 so you're going to have the inconsistent experience between browsers. 00:40:03.000 --> 00:40:13.000 So just make sure we suggest doing your own error messages. In the end, like most folks do, and then just make sure that those messages are both visible and persistent. 00:40:13.000 --> 00:40:19.000 You don't want to rely on color alone to indicate an error message. 00:40:19.000 --> 00:40:24.000 If you may have noticed I did not use read for my error messages I use green. 00:40:24.000 --> 00:40:42.000 Just to kind of hammer that point home error messages, should not rely on color. Additionally, you don't want to just say, turn the background color of your form input read to indicate that that the field is an error, that's again that's relying on color 00:40:42.000 --> 00:40:46.000 alone. you want to have 00:40:46.000 --> 00:41:00.000 visible persistent error message you and then you also want to have that error message, either in context of the form field like I'm showing here or you can put all of your error messages at the top of your form. 00:41:00.000 --> 00:41:12.000 Just the one place you don't want to put your error messages, after your Submit button. Users are very unlikely to find that or if you put them at the bottom of the form, they're very unlikely to find those error messages. 00:41:12.000 --> 00:41:20.000 You want to put them at the top or you want to put them in context with with each element that's an error so they understand what is required for that field. 00:41:20.000 --> 00:41:36.000 And then lastly, like we talked about if you do use some kind of icon to denote that something is an error or a warning or whatever you doing your display, go ahead and use that Aria dash and equals true on that in line icon and hide it from assistive 00:41:36.000 --> 00:41:38.000 technology. 00:41:38.000 --> 00:41:52.000 Alright so you, I've got a resources slide here, we've got again I we posted the link to the actual text code example in code pen, that's here again it's tiny URL. 00:41:52.000 --> 00:41:55.000 com slash register cat. 00:41:55.000 --> 00:42:01.000 And then I'm going to show a brief video of a screen reader jaws. 00:42:01.000 --> 00:42:16.000 In the Chrome browser actually trying to navigate this test form that that I created. Just so you can get an idea of what required field sound like what invalid might sound like what a radio button in a group might sound like. 00:42:16.000 --> 00:42:31.000 And I've captioned, that it's pre recorded so that hopefully you can you can follow along, or go back and reference that video if you want to understand how something should should hear or sound like as it's read by assistive technology so let me just 00:42:31.000 --> 00:42:36.000 go to that video, 00:42:36.000 --> 00:42:39.000 and I'll go ahead and start the video 00:42:39.000 --> 00:42:55.000 rapping to the top register your cat heading level one main region cat's name metadata required invalid every cat's name was required to type in text your email letter required invalid entry email format email@domain.com, type in text. 00:42:55.000 --> 00:43:13.000 Cats birthday edit birthday format mmm DD selected I type in text is your cat altered. Not sure radio button checked. Three of three change this election press up or down arrow, no radio button checked, yes radio button check 123 cats market he's combo 00:43:13.000 --> 00:43:21.000 box required, select an option to change this election use the arrow keys, solid multi color. 00:43:21.000 --> 00:43:39.000 And her expanded required list with eight items multi dash color to move to an item press the arrow keys taxi or accessible forms cats market he's combo box required menu tuxedo. 00:43:39.000 --> 00:43:48.000 Cats colors M dash select at least one black checkbox not check the check press spacebar plus f space checked. 00:43:48.000 --> 00:43:52.000 Like check box not checked, check press spacebar plus F. 00:43:52.000 --> 00:44:06.000 Brown checkbox checked, check press space orange checkbox not yet great check box not checked. Check press Send button to activate press enter. 00:44:06.000 --> 00:44:24.000 Alright, so that gives you an idea of what it kind of sounds like to a screen reader user navigating a form. That's not necessarily the order or process that they would use to navigate the form but that is an example of what those controls would, would 00:44:24.000 --> 00:44:28.000 sound like with, with the screen reader in Chrome. 00:44:28.000 --> 00:44:38.000 Again, it's helpful to test and multiple screen reader and browser combinations just to see if anything is a little bit different in a different environment. 00:44:38.000 --> 00:44:48.000 Alright. So in conclusion, let's just go over what we talked about when we're creating our form fields we want to verify that each input element has a defined type. 00:44:48.000 --> 00:45:03.000 We have an ID attribute. We have a name attribute and then if needed. We have an autocomplete attribute. And we link that input to the label with the four equals the ID that's on our input. 00:45:03.000 --> 00:45:14.000 Next, if we have related fields like radio buttons or checkboxes we want to group these related fields using a field set and legend elements to give that group. 00:45:14.000 --> 00:45:18.000 the role of group, and also a name. 00:45:18.000 --> 00:45:29.000 And then, we want to mark are required fields both visually with something like an asterisk and programmatically using either the required or Aria desk required attributes on our input. 00:45:29.000 --> 00:45:42.000 And then we also want to include help text that identifies the air and provides input instructions as needed if there's some way that we, we can tell our users, there's a required format. 00:45:42.000 --> 00:45:59.000 Next, if, if a user submits a form and it comes back in error, we want to add that Aria dash invalid equals true attribute to any fields that are an error, and this will help programmatically link or identify required invalid fields to users of assistive 00:45:59.000 --> 00:46:08.000 technology and then we also if we have any error text we want to also programmatically link that using Aria dash described by. 00:46:08.000 --> 00:46:19.000 And then lastly, if you do have any specific data formats that you're trying to enforce, you can use something like the pattern attribute on your input to. 00:46:19.000 --> 00:46:28.000 And also we want to let us know what the pattern is but that will help the browser reinforce whether or not that that data is is valid. 00:46:28.000 --> 00:46:34.000 Alright so with that I think we have some time for questions. 00:46:34.000 --> 00:46:39.000 Mike, do you want to let me know what they are. 00:46:39.000 --> 00:46:44.000 Yeah, so there's a bunch of questions so we'll try to get through as many as we can. 00:46:44.000 --> 00:46:59.000 And so I'll start with the q amp a. The first question is from Reginald. Sounds like you're creating these forms manually. As a blind person who doesn't know HTML, can I create my own forms easily and affordably. 00:46:59.000 --> 00:47:06.000 What about retaining the same visual structure that people have vision one, wanting their form. 00:47:06.000 --> 00:47:15.000 That's a really good question. It's not something I have, you know first hand experience with, as I am cited. 00:47:15.000 --> 00:47:20.000 I know that you, you know, certain 00:47:20.000 --> 00:47:26.000 places that offer forms, whether it's something like WordPress or some kind of plugin. 00:47:26.000 --> 00:47:44.000 Check if they have an accessibility statement and see what what their requirements are unformed or maybe you can check the internet to see, like, what, find out what the accessibility of it for of a particular form tool is but I don't know anything offhand 00:47:44.000 --> 00:47:54.000 that I can suggest and say like this is absolutely accessible you're right I am creating these manually by hand so that we can look at those individual attributes. 00:47:54.000 --> 00:48:00.000 But maybe that's something we can look up for you, and get back to you on a suggestion. 00:48:00.000 --> 00:48:01.000 Over. 00:48:01.000 --> 00:48:12.000 This next one from Mark Matthews is a sound, understanding of JavaScript in particular scripting, the DOM key to implementing Aria most successfully. 00:48:12.000 --> 00:48:15.000 No, Not, not necessarily. 00:48:15.000 --> 00:48:30.000 Everything that we use Aria wise in our demonstration here doesn't require any particular scripting, other than that Aria dash invalid equals true attribute being added after the form is submitted. 00:48:30.000 --> 00:48:33.000 That can be done server side as well. 00:48:33.000 --> 00:48:37.000 So you know there are server side ways to do this, if, if that's the concern. 00:48:37.000 --> 00:48:57.000 But there are there are JavaScript out there that you can, you know, adapt to your form and to get the error messages to display, when you want them to my boat most of my experience that was doing it on server side and not scripting in the DOM but you 00:48:57.000 --> 00:49:08.000 certainly you can do that a lot of people do do that, you know in in context form field validation. Some people find that really useful. 00:49:08.000 --> 00:49:16.000 But yeah, I wouldn't say that it's required. There's a lot of what we did today that you could do without any scripting. 00:49:16.000 --> 00:49:23.000 But when you do get into those more complex interactions around valid invalid data on required fields. 00:49:23.000 --> 00:49:27.000 Yeah, you probably need some scripting for that. 00:49:27.000 --> 00:49:39.000 Alright, next question is from Jeff Rogers, with the attributes of type ID and Name, which of these will be the accessible name, read by the screen reader. 00:49:39.000 --> 00:49:49.000 The answer is none, none of those. What will be read by the screen reader if if we're talking about those attributes on an input. 00:49:49.000 --> 00:50:04.000 It's the label, so that label attribute, and if you have the, you have the four on your label and that links it to the ID in your input so when a screen reader accesses the input that label will be read automatically they don't need to go to the label 00:50:04.000 --> 00:50:18.000 node separately, it's, it's read in context of the input. So that's what the for an ID attributes do is make that programmatically link for you directly. 00:50:18.000 --> 00:50:27.000 Alright, next question is from Mark again will all complete fail to work as intended at the browser cache is cleared. 00:50:27.000 --> 00:50:44.000 Um, yeah, it depends on whatever is stored in the browser, it's not like pulling from your Google account or something like that is purely based on the browser that you you're using at the time and what data has been submitted in that browser in the past 00:50:44.000 --> 00:50:47.000 so if you were using someone else's computer. 00:50:47.000 --> 00:50:59.000 And there was autocomplete on a field it might suggest that person's email address, it wouldn't necessarily suggest yours. It's based again yeah you're right on but browser caching browser data stored. 00:50:59.000 --> 00:51:05.000 Not like an account where you're signed in or anything like that. 00:51:05.000 --> 00:51:18.000 This next one's from anonymous. Is there any downside to always using field set and legend by default, even with a simple form example, a form with one radio type input. 00:51:18.000 --> 00:51:30.000 Um, that's a good question if you had one radio button you wouldn't need to group field so you'd be safe night not using it builds on a legend but as soon as you had a second one. 00:51:30.000 --> 00:51:46.000 You definitely would, but yeah if you, you don't need to use fields that and legend like all over the place on absolutely, you know, for example, another place where you might have a checkbox at the end of a forum right that says I agree to these terms. 00:51:46.000 --> 00:51:57.000 Again, it's a single input it's a single checkbox so you don't need to use fields that and legend to group those just when you have multiple of the same inputs that are related. 00:51:57.000 --> 00:52:11.000 So, next one is, if Aria support is not completely equal between platforms screen readers. Then when hiding the star on a required field that really be the best choice. 00:52:11.000 --> 00:52:24.000 Yes, so we know that orientation equals true is implemented pretty standard Lee across browsers. Everything that we looked at today is is fully supported by modern browsers. 00:52:24.000 --> 00:52:41.000 There are there are attributes that have differing levels of support that's why it's important to look at, like the W three C's wi Aria suggestions for things like a combo box with an autocomplete or something like that. 00:52:41.000 --> 00:52:46.000 You would make sure you want to look at what the standard is and how does your best supported. 00:52:46.000 --> 00:52:59.000 There's a website out there, I can look it up and we can post it in the chat that will tell you what the browser support is for a particular Aria attribute but in this case with Aria dash hidden that's well supported so you don't have to worry about that. 00:52:59.000 --> 00:53:07.000 All right, next one. What tools do you suggest using to check our audit your websites accessibility. 00:53:07.000 --> 00:53:17.000 Ah, well I believe we have the art tool kit that you can download. do you have a link to that Mike, is that something that we can. 00:53:17.000 --> 00:53:24.000 Yeah, I can grab a link and add that I can send an email to everyone, but I can also add it to the chat. 00:53:24.000 --> 00:53:26.000 Okay. 00:53:26.000 --> 00:53:37.000 Oh thanks Todd he posted a link to Can I use. com. 00:53:37.000 --> 00:53:39.000 All right, next one. 00:53:39.000 --> 00:53:53.000 Can a like RT scale I might be I'm not understanding that you might know what that means more than I do but kinda like RT scale question type be rendered acceptably for screenwriters. 00:53:53.000 --> 00:54:07.000 I have seen the advice that is not accessible so use a different question type but if it's available as a question type, people are going to use it and there are reasons people may not need to use this question type rather than a radio button format. 00:54:07.000 --> 00:54:19.000 For example, it seems that Google Forms has figured out a way to do like Artie questions excessively, but I need some advice for our developers as we have a survey builder within our platform. 00:54:19.000 --> 00:54:32.000 That's a good question. Um, so I would imagine if you have a scale that you're using radio buttons. So I'm not sure if if there's a different technology that you're suggesting is being used. 00:54:32.000 --> 00:54:47.000 Because if you did just have a group of radio buttons with a field set and legend for for each question. I think that would be fully accessible, you just make sure that that your your your question is the legend and then each of your, your radio buttons 00:54:47.000 --> 00:54:52.000 like one through seven would reference that question. 00:54:52.000 --> 00:55:06.000 And then people would know which number one is related to which question I think that's the most difficult part when you have multiple groups of controls that have similar names we just, that's where the fields and legend really is helpful because it 00:55:06.000 --> 00:55:09.000 gives that group and name. 00:55:09.000 --> 00:55:14.000 I hope I answered your question. 00:55:14.000 --> 00:55:19.000 Yeah and Scott actually helped me out with how to pronounce that it's like her. 00:55:19.000 --> 00:55:22.000 like you're learning something new every day. 00:55:22.000 --> 00:55:33.000 Next question, how would you handle errors for radio and checkbox groups specifically, where would you place the order described by attribute 00:55:33.000 --> 00:55:48.000 for radio and checkbox group so I guess it depends what you're trying to do. I'm trying to understand is that like you have an error message for a group of radio buttons or an error message for group of checkboxes. 00:55:48.000 --> 00:56:07.000 In that case, I mean I would probably put it at the beginning of the selection, so that they encounter it but you would also use that Aria dash described by as you say to you could put that on the legend, you can say Aria dash described by. 00:56:07.000 --> 00:56:20.000 And then, whatever your error messages, you can definitely put that attribute on the legend. If it's for a group of controls and you want to say, you know, please select one of these controls, something like that. 00:56:20.000 --> 00:56:34.000 So we have a few minutes left so I want to try to get a few more in. Would you be able to describe the ID thing again when it comes to the are described by, equals true attribute. 00:56:34.000 --> 00:56:51.000 Sure. So, are you a dash described by always takes an ID as an argument so not not true or false, but you're going to point to the exact text that is your error message or your, your formatting information so let's say, let's say your error messages in 00:56:51.000 --> 00:57:03.000 just a p a p element, you would put an ID on that piece so say ID equals error, one. And then you have your error text that says you know this field is required. 00:57:03.000 --> 00:57:19.000 Then on your input you would use Aria dash described by to point to that Id so error one. And when you do that, that error message will get read at the end of all of the information about that form field. 00:57:19.000 --> 00:57:22.000 Awesome. 00:57:22.000 --> 00:57:36.000 Good, good question. I think is applicable to everyone. I create lots of PDF forms I struggled with the visible label reading as well as the form field tool tip reading the same content, can you recommend a way to not have repetitive screen reading. 00:57:36.000 --> 00:57:40.000 And this is obviously related to PDF forms. 00:57:40.000 --> 00:57:41.000 Yep. 00:57:41.000 --> 00:57:52.000 I'm not as familiar with, with PDF forms, but if you have a tool tip, in addition to a field name, it's good. And it's announcing both. 00:57:52.000 --> 00:58:07.000 And I guess the question would be, do you need the tool tip if if the text is exactly the same. If it's different texts, then it's a good thing and it's being announced by assistive technology, but I guess I would need to see this specific example to 00:58:07.000 --> 00:58:15.000 any real help there. All right. 00:58:15.000 --> 00:58:21.000 thoughts on the use of disabled on form elements. 00:58:21.000 --> 00:58:25.000 Yeah. So there's a couple couple things to think about their. 00:58:25.000 --> 00:58:42.000 One, it just kind of established best practice not to disable say the submit button on a form to enforce proper data entry on the form that can be confusing for users of assistive technology. 00:58:42.000 --> 00:59:01.000 And this is because if you're being totally accessible you don't want disabled form elements or disabled elements to be in the focus order so user shouldn't be able to tab directly to a disabled field or a disabled button. 00:59:01.000 --> 00:59:07.000 But most people leave that in place so that can be a little bit confusing. 00:59:07.000 --> 00:59:24.000 If you are just so if you're disabling something take it out of the focus order, and I would just, I would urge you not to disable the submit button on a form field that there's just a lot of evidence out there that's confusing for folks, not just users 00:59:24.000 --> 00:59:36.000 of assistive technology but even cited users if if a control is grayed out. When a control is disabled, it doesn't have to meet contrast requirements like text and non tax contrast. 00:59:36.000 --> 00:59:40.000 So, user could just simply not see it. 00:59:40.000 --> 00:59:46.000 Because of the the poor contrast of disabled elements. 00:59:46.000 --> 01:00:02.000 Yeah, so it's okay to use them but you do want to use our your dash disabled equals true rather than the disabled attribute, if you want to look that up and see, see if that works for you. 01:00:02.000 --> 01:00:03.000 Awesome. 01:00:03.000 --> 01:00:14.000 Well, we're almost at time here. One more that might be I think fairly quick for the combo box shouldn't read each option as you scroll through when the box is expanded. 01:00:14.000 --> 01:00:27.000 Oh, yes. So you may have noticed in this in the video that it wasn't reading, each one and that's just because I wasn't pausing on it. If you paused, it would but I was once I got through the first couple of examples. 01:00:27.000 --> 01:00:40.000 I was just having to the last one and then it announced that but yeah if someone were just, you know, slowly tapping through option, it would definitely read it, that out and that is something if you're using if you're creating a custom combo box, you 01:00:40.000 --> 01:00:49.000 want to make sure that your list box is announcing each option to the user as they navigate with the arrow keys. Yes. 01:00:49.000 --> 01:01:12.000 Awesome.