- [Anthony] Good morning and good afternoon, everyone. My name's Anthony Priore. I'm the digital marketing specialist at TPGi. We'll just wait one minute as people sign in and we'll get started briefly. While we wait though, if anyone would like to share in the chat where you're logging in from, that would be, I'd love to see where people are checking in and joining us from. It's awesome seeing how a session like this can bring so many people from across the globe together. We have people coming in from everywhere. I still do see a few people trickling in though, so we're just gonna give it one more minute, and then we'll let Alicia and Carolina get started. Okay, so thank you everyone for joining us today for our webinar, The Accessible Forms Checklist, with TPGi's Alicia Evans, Senior Accessibility Engineer, and Carolina Crespo, Accessibility Engineer and Audit Lead. So before we get started, I do have a few housekeeping items to let you know about. Firstly, this session is being recorded, and we will email everyone the recording after the event. Secondly, we have captions available, so please feel free to turn those on and use them as needed. Next, we will have a live Q&A at the end of the webinar, so please use the Q&A box to send your questions in, and we'll answer as many as we can at the end of the presentation. And I encourage you to use the Q&A box, because sometimes, messages can get lost in chat on our end. So just to ensure that we see it, please use the Q&A box. I'll still be monitoring the chat, but it's a little easier if you use the Q&A box. And lastly, if anyone needs any accessibility support, training, or usability testing, we will send out an email with a link to schedule a time to speak with one of our experts. So with that, I will let Alicia and Carolina get started and provide introductions for themselves.

- Hi, everyone. This is The Accessible Forms Checklist. I'm Alicia Evans.

- Hi, I'm Carolina Crespo.

- And we're just going to take a second to hide our faces. We will come back to you at the end at Q&A, but let's go on. All right, so this is a really big topic, so we thought we'd start with what we will cover and what we're not able to cover today. So what we will cover is a high-level view of WCAG 2.x, and in this case, that means 2.1 with a look ahead to 2.2, level A and AA success criteria as they apply to forms. And if that doesn't mean anything to you, don't worry. You don't have to have a deep level of WCAG to get good information from this talk. WCAG stands for the Web Content Accessibility Guidelines. We'll also be talking about examples for how to fix common accessibility issues in forms, and we have a lot of great CodePen examples for you. So slides that have a CodePen example will have a link to the CodePen in the heading for the relevant slide. And so for what we will not cover, there is no way, unfortunately, that we can cover every single thing that can apply to forms because we have a limited amount of time today. So we have a checklist available for you, the Accessible Forms Checklist, and that will be linked on the next slide. And we're able to cover the majority of things on that checklist minus the last two. So we decided to focus on the things that we see the most often when we are auditing forms, and the last two have really great information in the understanding documents, or you can feel free to ask us questions about them, either in the Q&A, or you can feel free to just email us and ask us whatever questions that you have. Also, though, beyond the checklist, there are a lot of things that are relevant to forms that we just didn't include on the checklist. So for example, if you have a form that is not keyboard accessible, you have a really inaccessible form, but we don't have keyboard accessibility on our checklist, and that's because with some of these success criteria, like keyboard accessibility, you should be checking that for every single thing that you audit. This checklist is really designed for forms specifically, because what we've found is that when new auditors, or when developers or designers are trying to look at their own forms, there are a lot of things that sometimes fall through the cracks. So this checklist is really to help you make sure that you're uncovering a lot of those things that sometimes get lost. And unfortunately, we can't cover any of the WCAG AAA success criteria, and again, if you don't know what that means, don't worry about it, that's the last time we'll talk about AAA success criteria. So here is our agenda, and the checklist, the actual Accessible Forms Checklist is linked in the CodePen in the heading. And so we'll be talking about text contrast, non-text contrast, input purpose, required fields, both visual and programmatic, visible labels and accessible names, and the difference between those, label in name, descriptive labels, grouped controls, and then for errors, we have error in text, errors programmatically associated, and error suggestions. And from there, we'll take a look ahead at WCAG 2.2 and talk about target size, accessible authentication, and redundant entry. And with that, I will pass things over to Carolina.

- [Carolina] Thank you, Alicia. So first, we are starting with the text contrast. The related criteria is 1.4.3, Contrast Minimum, and it applies to all the text that we have in a form. So labels, instruction, placeholder, error text, and status message. Basically, we have to make sure that the color contrast ratio between the text and the background is at least 4.5 against one. So if we move to the next slide, we have a form on the left side, we have a form on the right side, we have a table with all the color contrast. We have the color of the element, the color of the background, and the contrast ratio that it gives you. So we can see, we have on the form, we see a light gray for the placeholder for the instructions of the legend, we have a light blue for all the labels, and we have a pure red for the error. I chose on purpose very bad one for the labels especially, the placeholders, you barely can see. And that was to make also a point of accessibility is not only for people with disability, but for everybody, we just need a different context. If we were in a room, people at the bar won't see anything. Even though I highly doubt like people can read it properly. You really have to make sure that you are close to the screen. Sorry, I forgot. So the color contrast between the placeholder, between the placeholder and the background, it is 1.5 against one. The labels, the light blue label, they are 1.5 against one. The error message there are four against one, and the legend is 2.8 against one. So we see like we don't get the the 4.5 against one that we were looking for. So how do we fix this? We move to the next slide. Easy, easy fix. We only need to change one line in the CSS. So we go from this light gray to something like darker gray, which is now we have a 7.3 against one. I changed all the light blue for black, now we have 21 against one. And we darkened a bit the red, and now we have 4.8 against one. And for the legend, or the label, we have 7.3 against one. Again, just darken, we make the gray darker, and we get all the result. So how something that is, because I don't know if you know, but this is one of, we have a very easy fix, and yet this is the most popular issue in accessibility. We find in the all out there, like 80, like most of, most of the issue, like almost 80% of the issues, they're related to color contrast issue. So now, what we do with non-text element on the form? So they are covered by 1.4.11, Non-text Contrast. And what we are aiming is to have a color contrast ratio of at least three against one between the element and the background. The element that we are gonna look at are the border, the focus indicator, the selected or unselected state, and the graphic that we find in a form. So we go to the same form, and we see on the left side, we have again the form, on the right side, we have the table. We can see the light gray for the input. We have, oh, one sec. If you see the focus indicator for mobile number input, I removed the vertical bar. In order for this to be a fail, I needed that. The only visual indication was the focus indicator, and not the vertical bar, so I removed the vertical bar, and I used the yellow against white. So the color contrast is 1.1 against one. Same for the arrow down that we have in the select, yellow again. And the selected state of the radio button, again, yellow. So we have mostly like 1.1 against one, but the border, that is 1.6 against one. Same thing, we move to the next one. Alicia, yeah, there you go. So we changed, we make everything in black just for the example, and everything passed, like 21 against one, easy fix, again. I also add, I re-added the vertical bar, just because it feels like we are used to, but also it's easier to follow in which input we are. Now, we are moving to the autocomplete. The related criteria is 1.3.5, identify input purpose. If we move to the next slide, we see that some input, they have a purpose, they serve a purpose. So we can click on the link, input Purposes for User Interface Components, we have all the lists and the attributes that we have to use. But we are gonna be focusing on the name, the address, like credit card, the country, the birthdate, what we do with this input. So what we have to do... Alicia, next, thank you. So we only need to use, we only need to add the autocomplete in the input. So for the name, we use autocomplete equals name. For the email address, we use autocomplete email, et cetera, et cetera. Why do we do this? This is to help people with cognitive disability or mobility impairment, but also, again, this is for all the user. We will avoid typos, and we don't need to like free type everything. You just click, and you will have whatever you already used on your computer without, for your name, or for your email address, et cetera, et cetera. So just until now, I don't know... Who said that accessibility takes a lot, right? So far we have one change, and one small change, and we are making the form accessible. The last thing that we're gonna talk, it is the required fields. So we have two criteria related to this topic. One is 3.3.2, Labels or Instructions, and 4.1.2, Name, Role, and Value. So 3.3.2, we're gonna be focusing on how the visual, the voice, the visual inform... How we are communicating the required field visually. And the 4.1.2 is gonna be focusing on like how do we communicate this information to a screen process technology or screen reader. So we have an example. We have a form in this slide, and I wonder like if someone on the webinar can tell me which input are required, which are not. So I guess, nobody say anything, so again, we cannot tell anything right now, because there is no visual indication, or we don't know if we have any ... If it's communicated to the screen reader user. But yeah, so, if we move to the next one, Alicia, thanks. So there are different ways of doing this. I'm gonna present three options, how to make this visually and programmatically accessible to screen readers. So the first thing that I will do is like visually, I'm gonna communicate this, just adding the required word to the label. So now, that is, sorry, so that is communicated visually, so we can move to the next one. So what do we do to communicate this to the screen reader? So we use aria-required=true, and I'm gonna make a, I'm gonna communicate something here. Why we choose aria-required versus the required attribute. So the required attribute, it is a valid HTML attribute, but the form validation of this one is not always accessible. So in order to avoid this to be a problem, like with the validation, we make sure that we use the aria-required true, and we don't have any other issues. So yeah, so we put the required on the label. Now we have the aria-required communicated, when screen reader goes to the input, it is announced as a required. Next, now, I don't wanna go too deep on this one, because I know Alicia have a slide explaining this, and have an example with a CodePen. But if we don't wanna use the aria-required, we can also use, we can the label with the input. So because we have already the required in the label, if I link the label and the input, it would be announced. So how do I link these two elements is with the for and id. I will give the same value, and then it will be announcing, once I navigate in the input, it will announce full name required, email address required. If I use the for id technique, I will not use the aria-required one, because otherwise it's gonna, it's gonna repeat require, require both, twice, and it would be two by both. We move to the next option. So another option, it is to communicate this visually at the very beginning. So if I tell you all the fields are required, but the one that there, marked as optional, so the only optional one, it will be Hobbies at the bottom. Again, in this case, because we don't have the required on the label, we we will use the aria-required true. Moving to the last option. And I think this is the one that we all know, and we are more used to this one. So the asterisk. When you have an asterisk, means that it is required. But we need to communicate this at the very beginning of the form, saying that the asterisk means that it is required, because it's not, like it may be for us, it's obvious, but it's not obvious for, like it's not something universal that all the people know. If you have experience with the web, probably you know, but it is not the case for everybody. So make sure that you explain what they actually mean, otherwise you will fail. It will be a fail of 3.3.2, labels and instructions. And then, in this case, we can use the for id or the aria-required technique to communicate this to the screen reader. And now, Alicia, you can go ahead.

- [Alicia] Okay, and with that, we come to labels and names. So the difference between a label and a name is that a label is what is visually indicating what an element is for, and a name is what is programmatically associated or what is programmatically identified as the name. So it's what assistive technologies are using to name a control or an element. And the related WCAG success criteria for labels and names are 3.3.2, Labels or Instructions, Level A, 4.1.2, Name, Role, Value, Level A, 2.4.6, Headings and Labels, Level AA, and 2.5.3, Label in Name, Level A. So we'll start with visible labels, and I've stolen a quote from the Benefits of WCAG SC 3.3.2 Labels and Instructions documentation. And it says, "Providing clear and unambiguous labels and instructions helps all users, but particularly those with cognitive, language, and learning disabilities to enter information correctly." So here I have an example. It says Date of Birth in text, and below that are three input fields. And whoever put this together probably assumed that users would decide that the first input is for month, the second one is for day, and the third one is for year. But this is a problem, because you should never assume that users will intuitively know something. You should make your visible labels explicit. So someone from Europe, for example, might assume that day goes in the first input, month in the second input, and year in the third input, and they could inadvertently be putting in incorrect information. One way we see people try to address this is by adding placeholder text to each of these inputs, month for the first, day for the second, year for the third. And this is better than not providing any labels. The problem is that once you start to type into the fields, all of that labeling information disappears. So this is especially a problem for users with short-term memory loss, because if they don't remember what the label said, they then have to clear out all of the information to see what the label said in the first place. So visible labels must be present, but they also must be persistent. You should be able to access them at any time. Okay, now for accessible names. So for this, I've added to our date of birth example. I've put month, day, and year labels on our input fields, which makes this much clearer for visual users. But to make sure that this is really accessible, we have to make sure that the following are true: that the inputs have accessible names, that the accessible names contain the visible labels, and we'll be looking at both of these in our CodePen example in just a moment, and that the visible labels and accessible names describe the purpose of the inputs. So if I had, instead of putting month, day and year, just put date of birth, date of birth, date of birth as my visible labels, then yes, they would all have visible labels, but the labels wouldn't identify the purpose of each of these inputs, it wouldn't describe it clearly enough. So you need to make sure that you are labeling things in a way that makes sense for users. And for this one, we're going to look at our first CodePen example. So this was linked in all of the slides, the last few slides, two slides that we just looked at. This is our Accessible Labels Demo, and it has the examples that we were looking at. So if I scroll down to, Fields have visible labels but no accessible name, we'll see the example we've been looking at. So date of birth with month, day, and year visible labels. If I inspect this input, so I'm using the Google Chrome browser, and if I, I right clicked and pressed inspect, but there are also hotkeys that can open this. If I click into the input element, I can go to the Accessibility pane. And this is great, because it gives me all of, or a lot of information that will be communicated with assistive technologies. So in the first disclosure, there is an Accessibility Tree, and if I expand that and find the text box, this is the input that we're looking at. It's announced to screen reader users as a textbox, but there's no accessible name associated with it. If there were an accessible name, it would be listed next to the textbox, just like this group ahead, or above it, has the accessible name Date of Birth listed right beside it. If I go to the Computed Properties and expand that, here, we have name, and the computed name is an empty string, because we haven't provided an accessible name for this control. And below the name are all the different ways that we could have provided a name, and all of them are listed as not specified. We have aria-labelledby, aria-label, From label, title, placeholder, aria-placeholder, and title again. So if we look at our accessible example and inspect the month input, now if we go to our Accessibility Tree, we see that the text box has the name Month beside it, so it has an accessible name. And in Computed Properties, we see that the month name comes from the label coming from the for attribute. So within the code itself, I can see that this input has an id value of month4, and that the label element that contains the text month has a for attribute that also has the value month4. So for equals month4 on the label, and id equals month4 on the input. And these matching values are programmatically linking the input with the label, which provides the name for the input. So this is the native HTML solution for naming inputs specifically, and whenever there's a native HTML solution, that's the solution that we generally recommend. But that's not, as we can see from the name, computation is not the only way that a name can be provided, although it is the best way for sure. If we go up to the visible labels and accessible names don't match example, and inspect the month, and click on the input, now we still have the name month, but it's getting that month from an aria-label attribute. So on the input, we have aria-label="month", and that's actually doing fine. The visible label and the accessible name match, and there are no problems here, it's just not the way that we would recommend naming this element. But if I inspect the Day input, now we see that the name is date, and it's getting that name from the aria-label attribute. So this aria-label="date" means that this input is called date instead of day, which is the visible label. And the problem with this is that if a speech input user is trying to access the day input user, the speech input software might not recognize that there is such a input called the day input, because they only know of a date input. So that will create some problems in trying to access that input. Whenever you have a visible label and an accessible name, they should match, or at the very least, it should contain all of the visible label. So it can have more in addition, but it needs to contain everything that is a part of the visible label. Okay, and if we return to our slides, there we go. Now we'll talk about related fields. And so the related WCAG Success Criteria for this is 1.3.1, Info and Relationships, Level A. And here, we're going to talk about programmatically grouped controls. So here, I have the same example we had before, a date of birth group, with the field month, day, and year. And then the question, "Are you enjoying this talk," which we hope you are, with the radio buttons yes and no. So visually, these inputs and radio buttons are groups, but without the context of the group grouping and the group label, do these input and radio button labels still make sense? So if you got to a form, and you encountered month, day, year, yes, no, would you understand that this was requesting your date of birth information and asking if you were enjoying this talk? And the answer is probably no, because these groupings and this context really makes a lot of difference. And so if it's making a lot of difference visually, you have to ensure that it's also being conveyed programmatically, so the screen reader users get the benefit of this context. So we're gonna look at another CodePen example. Okay, this is our Accessible Grouping Demo, which is linked in the heading for this slide. And we have those same fields, date of birth and are you enjoying this talk, in an inaccessible example and an accessible example using field sets. So for the inaccessible example, if I open my inspector on the Yes radio button and open the Accessibility pane, in the Accessibility Tree, I can see that this is a radio button Yes, but there's no extra context in the Accessibility Tree letting me know what this yes has to do with, yes what? There's no extra context here. If I go to the Yes radio button for the accessible version, though, now I still have a Yes radio button, but if I travel up the Accessibility Tree, I can see that that Yes radio button is within the group, "Are you enjoying this talk?" So the Yes and No radio buttons are grouped within this labeled group, "Are you enjoying this talk?" And the way that we were able to accomplish this is through the use of a field set. So if I scroll down to the bottom here, we have a field set element that contains the legend and two radio buttons, and the legend has the question here, "Are you enjoying this talk," that's the group label, and the legend is the first child of the field set element. So that's how we were able to programmatically group these fields. Okay, if we go back to our slides, I've also provided an additional resource for other grouping techniques, and that's the W3C WAI tutorial for grouping controls. Okay, and now we move on to errors. So when I first got started in accessibility, I found errors to be really intimidating. There's a lot of information about how to make error messages and errors in general accessible. So we're going to try to demystify that a little bit today. Our related WCAG success criteria are 3.3.1, Error Identification, Level A, 3.3.3, Error Suggestion, Level AA, 4.1.2, Name, Role, Value, Level A, and then I snuck in a little bit of 1.4.1, which we will look at in just a moment, which is Use of Color. Okay, so here we have errors indicated with color alone, and I have a full name field, it says Full Name Required, and the label and the border of the input are indicated in red, which I'm assuming means that there is an error in this form, but errors must be indicated in text. If color is the only indicator of an error, it might not be clear to users with colorblindness, and it won't be clear how to fix the error. So in this next slide, I have added some text below the input that says, "Error: Full name is required." So that makes it a lot more accessible for visual users, but we also need to make sure that this error message is conveyed to screen reader users. And one way to do that is through the aria-describedby attribute. So I have an accessible CodePen example for this one, and an inaccessible CodePen example. And for this one, I'm going to start with the accessible example. All right, so here's our Accessible Form Errors Demo. We have a Full Name Required input field, and if I try to submit it without any content in this input, I get an error message below the input, it says, "Error: Full name is required." And if I open the Inspector and open the Accessibility pane, okay, I can see that it has the name, the textbox has the name "Full Name Required," as we would expect. But then there are also these aria attributes. There's aria-invalid is set to true, which means that this is the field in error. And aria-describedby is set to name error, and we don't know what that means just yet based on looking at it. But if we go to the computed properties, we have the Name, "Full Name Required," and then there's this description. Description is, "Error: Full name is required." And depending on your settings, if you're a screen reader user, this would be announced as a textbox, which is the role right here, with the, that is called Full Name Required, and then there'd be a pause, and the description, "Error: Full name is required." And we also have here that its Invalid user entry is set to true. So we know that this is a field in error that has an error message, and we have all of that information on the input itself. If we look at the code, we have the input with aria-invalid=true. And then there's this attribute, aria-describedby equals name error, and that doesn't mean anything on its own. But if I scroll down to the div with the error message in it, the error message has an id value of name error. So the aria-describedby value and the id value match, and this is very similar to what we saw with the labeling technique of using the foreign id attribute values that match to programmatically link two elements. Now we're using the aria-describedby and id attributes to programmatically link these two elements. So now, the input has not only all the information about its own name, but also the information about any kind of description, in this case, an error. Okay? Actually, can't open that one, because the Zoom stuff is in the way. All right, so here is our Inaccessible Form Errors Example. It looks exactly the same. It has Full Name Required, and if I submit it empty, I get the error message, "Error: Full name is required." If I go into my Accessibility tools for this one, now, in my computed, oops, I'm in the wrong thing. Now in my Computed Properties, I have Name: "Full Name Required," as I would expect. And I have Role: textbox, but it says Invalid user entry: false, because that's what its default setting is. So it says that there is no error on this input, and there's no description, there's no error text, and that's because this error message isn't programmatically linked to the input. So while this looks exactly the same visually, it's not an accessible example of how to make accessible error messages. Okay, back to our slides. All right, and our final thing for errors is error suggestions. And what that says is that if known, suggestions for how to fix an error must be provided. So here, I have a zip code field with only four digits in it, and below that is an error message, "Error: Zip code must be at least five characters." And what we see a lot of the time is an error message that says, "You must enter a valid zip code," but with no information about why what I have entered here is not valid. So error suggestions is really meant to help users get back on the right track and figure out how to put in the correct information, rather than just telling them that they have the wrong information. And with that, I will hand things back to Carolina for 2.2.

- [Carolina] Thank you, Alicia. So yeah, now we just have a bit of the highlight of like what is coming on WCAG 2.2 related exclusively for forms. Full disclosure, this, again, this is only the highlight. If you really wanna go deep on how to test, and like what is the technical issue that you may encounter, or accessibility limitation for tester, I highly recommend you to watch the on demand webinar for accessibility testing with WCAG 2.2 that James Edwards did a few weeks ago here at TPGi as well. I'm sure Anthony have that link handy, he will post it eventually in the chat. But yeah, this is only like a few things of like what we gonna, what is the new thing that are coming for like testing on forms. So we have, we are gonna be focusing in three criteria, 2.5.8, Target Size Minimum, 3.3.7, Redundant Entry, and 3.3.8, Accessible Authentication. So the first one, 2.5.8, Target Size, we need to have a minimum target that is at least 24 by 24 pixel. And this is a great thing, and I'm sure like if we have any mobile accessibility engineers or testers, we will be happy about like having this one, because I'm, like a thousand times, we're testing, and you are on the phone, and you wanna click on one button, or one radio button, and you check the wrong one. So we were looking for this one for a long, long time. Very happy to like finally see that coming soon. So how do we increase this? There are different ways of doing this. I'm gonna present two of them. The first one, it will be just making bigger the checkbox or the radio button. So if we see on the screen, we have a bigger checkbox and a smaller one. The smaller one is the default one, and the other one is a bigger, like we increased it, adding a line-height and a width, oops, sorry, not just bigger. So that would be the first option. On the next one, the second option, and why we are presenting a second one is because we know, like designer, they will... Well, not that they won't agree, but it would be difficult sometimes. I know making change in the design is more difficult than making change on the back. So this, this is the second option, like how to make this on the back. So what we can do is like we can wrap the input inside the label, in the case of the checkbox or the radio button, and then add in the padding in there. So this way, we can click anywhere in the label. So, "I really, really like this talk." Again, hopefully the case. I will click anywhere in that label, and it will check or uncheck the checkbox. So again, there is many exception for this criteria. Check the webinar from James Edwards. He explained all the exceptions. Here, we don't have the time, so we'll move to the next criteria, which is 3.3.7, Redundant Entry. So what we're gonna check in here is how to reduce the cognitive load. How, by preventing to reenter information. Then how do we do that? So for example, we can pre-populate fields in the forms. We can minimize the mandatory fields. Let's say I'm buying shoes online, and they're asking me my age, or what is my favorite color? All this information that is not needed for buying shoes. For buying shoes, you will need my name, my delivery address, and my credit card. Everything else, it shouldn't be mandatory, it should be optional. And if you do need to repeat information, explain why you have to repeat, you have to retype again the same information, why you cannot retrieve the information from whatever I already filled out. So a nice example of this one is, again, if I'm buying shoes, and I fill out my name, my delivery address, and then I get to the shipping address, and I have a checkbox that it says same as delivery address, and you don't have to enter again same information. So that would be a good solution for this criteria. And the last one, it is 3.3.8, Accessible Authentication. This is to reduce the cognitive function tests. So the cognitive function test is like when you have to remember or transcribe information. So you don't, you shouldn't... The criteria say don't rely on the test, or if you do so, provide a mechanism to help. So a few example of like what is this. So one would be, for example, you are logging on any software on your computer, and they send you a second code on your phone. So now, not only do you need to transcribe the code, but you also need to switch devices, right? So that will, like how we will fix this? Like we could, for example, use a temporary URL, and that won't be an issue. Another example of this, it will be when you are logging into a bank, and then as a second login, as a second verification, they're asking you to like add the second, the third, and the fifth digit of your passcode. So this is required that you remember your passcode, and also what is the position for each one. So again, that would be a fail for this criteria. Now, we know how to make the forms accessible. We have, like now, we have a better idea of how to make everything accessible. If that is the case, the form is accessible, like the input is accessible, and we ensure that the browser allows to fill out the input, and we also allow the copy pasting between fields, that will be considered to help, and it won't be a fail. So if we make it until now, like everything that we learned today, we make the form accessible, we don't have to be worried about this criteria. And with that said, Alicia, give it back to you.

- [Alicia] All right. So we have our checklist available for you here, as well as in the checklist format. So if you go to the agenda slide and use that checklist, that will give you actual check boxes. This is everything written out sort of in long form. And since we just went over this, we're not going to go through all of it again, but I do want to highlight these two that we were not able to cover today. So number 15 is the behavior when an element is focused or entered expected behavior, which is for WCAG success criteria 3.2.1 and 3.2.2. And number 16, if the form is for legal, financial, or data information, is information reversible, checked, and confirmed, 3.3.4. So again, these are things that we don't see as errors as often, but they are things that you still need to check for. So we've included them in both of our checklists, and again, there's a lot of information out there about how to make sure that you can pass these two success criteria. But we wanted to make sure that we have time for questions. So we're going to turn our videos back on, and Anthony, do we have any questions so far?

- I haven't...

- Yeah, we do actually. And there's still some time, so if anybody hasn't submitted any questions yet, please feel free to do so. And also, I wanna thank everyone for sending those links in the chat. We've had a really engaged audience today. They've been on top of all of the links. So I'm gonna start off with Meg. Meg would like to know, "Designers are saying they wanna put optional on the fields that are optional, and everything else is required. What are your thoughts about this for accessibility?"

- I'll take this one Alicia, if it's okay with you. That's completely fine, as long as they communicate that visually and also programmatically. So if in the presentation, in the option number two, that was the option that was mentioned. So in the firstly, in the first line, you have all the fields are required except those that are marked as optional. And then you make sure that the input, they have the area required through the one that they are required, and that will be fine.

- Right, I think that a lot of the times, people wanna leave out that top line about how it's required unless marked as optional, and that is 100% necessary, like you need that. It can't just be assumed required unless you've been explicit that everything is required.

- Correct.

- [Anthony] Awesome. So next, someone would like to know, "Are there any valid reasons to use placeholder texts in text fields, or can we skip them altogether if we have accessible labels for fields?"

- I'm a big fan of skipping placeholder text altogether. I know, there can be a case made that if there's just a little bit of extra instruction in there, that you can keep it, but my thought on that is if there's extra instructions, everyone should have access to that all the time. So things like formatting. So for month, it has to be MM, you know, two digits. Why wouldn't you have that available to everyone? And that's another great use case for using aria-describeby. So if you have month, I'm sorry I keep running into the same example, I feel like it gets boring, but I wanna make sure that people are following along the full strand. So if you have a month label, then the month input, and then the format, you can either just put the format or extra instructions in the label itself, and programmatically associate that, or you can do it sort of underneath or adjacent to the input, and use aria-describeby to offer extra description. That's what the describeby is really for. So that would ensure that all of the information is programmatically associated, which placeholder would do, but it makes sure that it's also persistent, that you can access it at any time, because that kind of information is important. I mean, if you want it to be like a design thing, where you have a placeholder in addition to those things that are persistent, there's nothing wrong with that, I just think it's silly, honestly. It's redundant.

- [Anthony] Great. So next, Jonathan Would like to know, "For input type="date", the developer does not have control over the month, day, and year entry positions. Is this considered accessible, or do we have to create separate input fields to follow your specs?"

- So this one is a little bit more complicated. I haven't checked on it recently, but last time I checked, the date type input wasn't accessible. It's one of those things that you could argue is the fault of the browser for not implementing it accessibly, but at the end of the day, we're trying to make things accessible for people with disabilities. So really, you would want to create your own solution for that, and then make something that people can use well, and something that is accessible. So I can't tell you for sure. I mean, it sounds like we have a lot of knowledgeable people in the chat, so if anyone has recently looked at the input type="date", and knows if it's more accessible now than it was a couple years ago, that would be great. But yeah, our recommendation is to use something that you know to be accessible and that people can use.

- [Anthony] Okay, and this is the last question that I'm seeing, so if anybody else has any others, please get them in now before we wrap things up. But, oh, another one just popped in, so nevermind. Kay would like to know, "I've seen some forms," or, "I've seen some forms with error messages above the form field instead of below. What are your thoughts on that?"

- I think that's great. So I probably should have said that ahead of time that this was, or I think I did, that this was just one way that you can make error messages accessible is by the one that I showed you. The other way is called, I think it's called like bucket errors, where you have something at the top that talks about all the errors down below. And there are some things that you need to consider for that too. You would like... Optimally, you would like to have a heading that says that these are your error messages, so that screen reader users can navigate by heading, using the heading there. You'd wanna have all of your error messages in a list, and you would want to have all of your error messages linked. So if you click on the error message, it brings you directly to the input that's an error. Focus comes in quite a bit with error messages too, and that's something that I wasn't as explicit about. So in the way that I had it, you would move focus to the first input in error so that the error message is announced to screen reader users, or so that keyboard user can just quickly fix the mistake. For bucket errors, so errors at the top, it might make sense to move focus to the heading in that case for the error message, or to the first message there, depending on how you want it to go. And there are a lot of other things that go into that too. I don't know how in the weeds I wanna go in this answer, but there are a lot of great resources out there for how to make that kind of error handling work.

- [Anthony] Awesome, thank you. Kevin wants to know, "Can you clarify why you don't recommend using the native HTML 5 required attributes, and use aria-required instead?"

- Yes. It is because the form validation of the required is not always accessible. So we, just to make sure that we don't have any other, we don't add add issues to the form, we recommend the aria-required true in this case. So it's about the validation, the form validation.

- [Anthony] Cool, okay. Next, Ivana is asking, "Do you also test that forms are responsive on different devices?"

- Yes. Yeah, it's not the same on desktop. Why would you go like a smaller? Yeah, there's different behavior, especially, I mean, I cannot think of like the form, but when you have a menu button, you have the navigation, and then you go on a small device or mobile, you have the hamburger menu. So all of this is the completely different behavior. I cannot think of any example on form, but yes, we do test it, Alicia?

- Yeah, I think that's another, in the caveats we made in the beginning about what we won't cover, since the res... Why can't I think of the words? Reflow, responsive sizes, since those aren't specific to forms, that's something that you definitely want to check on the entire page for everything that you test, you wanna check those things. So it's not specific to forms. Definitely, if you're just getting started in accessibility, go through the entire WCAG list and make sure that you're not missing anything. Really what we were doing here is when I first got started in accessibility, I made myself a checklist for forms of all the things that I would forget. Like I'd forget to check and see if the errors were handled correctly, 'cause I was just looking at the form without submitting it, or I would forget to check the contrast of the borders, because it didn't occur to me just looking at it, those kinds of things. And so this really is an adaptation of that original kind of checklist. We've made it bigger and more comprehensive, but there are a lot of things that can apply to forms. You can pretty much apply almost the entire WCAG success, all of the WCAG success criteria to forms. So we just tried to make this the things that, when you're testing a form, that sometimes people miss. So for every page that you're on, you should be testing for resize, reflow, keyboard, images, title, all of these things. We just didn't include them in this checklist, but good question, thank you.

- [Anthony] Awesome. Okay, so I am not seeing any other questions at the moment, so thank you, everyone who asked a question. Thank you all in the audience for your participation today. Carolina and Alicia, thank you for an awesome and incredibly informative presentation. I think everyone got a ton out of it. Do you have anything else to add before we wrap up?

- Sure, yep. Let's see. Thank you. Again, we're Alicia Evans and Carolina Crespo. We're available through email, or LinkedIn, or however you wanna reach us. Our email addresses are put on the slides that we've provided you, so please feel free to reach out if you think of a question later today, or whenever, or anything like that. We really appreciate you coming.

- Yeah, thank you so much.

- [Anthony] Thank you. And again, we'll be emailing out the recording for this presentation later this week, so be on the lookout for that. So thank you so much everyone, and have a great rest of your day.

- You too.

- Bye now.