Live Session (2025-26)

There we go. All right. Welcome back to 2026 and the first of our tutorials in this year. So over the last four weeks or so, you had time to go through a lot of the lessons. I always want to give you the most flexibility over the holidays to organize yourself. Because I know some people have a lot of time over the holidays. Other people just want to do it at the normal pace. And both are totally fine for us. I also want to highlight that if you have any questions, you can always use the Slack to ping us. Don't feel like you're disturbing us. It might take a little while until we get back to you, just because we're not, you know, don't have unlimited time, unfortunately. I wish. But yeah, just wanted to remind you on that. Also wanted to remind you that we have the examination coming up, which is going to be at the end, mid-end February, where you are going to do like a whole accessibility test, like a really small scale accessibility test. So if you have any questions about that, you can always ask as well. Yeah. So let's get started. This week is about forms and interaction. And forms are quite a complex topic. But it's basically our first building stone for the next two weeks. Especially as we're going to ARIA next week. Which is basically building on top these interactions. I think it's really good to, no, the week after next week. Next week is content. That's what you get for jumping a week ahead in your calendar. Yeah, next week is going to be like a little bit more low, low effort because, you know, I don't want to like give you too much technical stuff in one week. That feels cruel. Yeah. So any questions about what you heard? Anything that I should show? Anything that is like of interest to you? And if not, I do have examples prepared that I can talk about. Going. Going. Gone. Okay. That's good. So I explained everything perfectly. That's what I I will tell myself. There we go. Oh, and one of the things that I probably need to do is to rejoin the meeting. Because I just have tried to share my screen. And oh, it might actually work. Share. Oh, yeah. You can see it. Okay. So, that's good. I thought I had to, like, restart the app. And then I would have, like, left for a second. But that's not needed. So, this is in polypaint. But you can use any browser for this. But I think it's always good to show, you know, different tools. Let's go to full screen mode here. So if you have further questions about like forms and interactive elements, you can use the quick reference to find applicable WCAG guidelines. This is something that I like to show because like people get like really, really like, oh, what does, you know, what do I need to look at when I do X? This is all WCAG 2.2 success criteria tagged with buttons, errors, or forms at level A and AA, and then some techniques, in this case for HTML, CSS, ARIA, client-side scripting, and server-side scripting. I don't think we need server-side scripting, so we can go here at the bottom and uncheck that. Yeah, and so this way, by checking the tags here, Or you can know what you need to look at. For forms also you might want to say, "Oh, maybe there's something with focus that I need to focus on." You can click that or like, I don't know, modals or something like that. So there are a lot of options. I like these for forms because they're pretty straightforward. You can see that there are only like, you know, a pretty large number, but only limited number left. You know, or like identify purpose. That should probably be checked with forms, to be honest. But it's not AA, so it's not. Yes. Hello? Okay. Okay. Maybe you unmuted accidentally. So yeah. So this is AAA. That's why it's not highlighted, but it's tagged with forms. So you can basically go through and see what WCAG success criteria are applicable for you. So that's a good page to have, the WCAG quick reference. I really like it. I don't just like it because I worked on it. But it is certainly a factor. I will put the link into the... What is it called? Chat as well. My language brain is not really booted as much. Yeah. And the nice thing about these quick ref links is that they contain all the information that is, like, selected. So if you click on it, you'll see basically the same thing that I'm seeing. So this will also help if you have colleagues and they say, "Hey, what WCAG stuff do I need to follow for forms?" You can just send them the link that only has those success criteria in it. So it's a pretty useful tool for practical stuff. That is the first thing I want to show. And then, you know, going a little bit into, like, forms and how they actually work. So this is the inaccessible version of this page. Which is the before and after demonstration. I have used this before as a demo to show bad accessibility and good accessibility. So this form is terrible on purpose. So for example, you have here the favorite city park. And these labels are not assigned to the individual radio buttons. So usually when you see a radio button and text next to it, you can click the text to mark the radio button, but they are not connected. They don't have the label association. Same goes for this, like select a city here. You have the city on the... and you can select it, but it's actually, you know, not properly like formatted and also this has no accessible name in that case. Do want to have a free newsletter. Here it's all about the focus. So if I focus here, it goes to Mr. and Mrs. Also because this is a very old demo, we still use like binary pronouns, which is like always throwing me off and I show it off because it's a little bit embarrassing, but that happens. But then I press tab and it goes to email address and then it goes to the name field where also the label is like, you know, on the left here, but it's also not a real label.

Erik, I'm so sorry for interrupting. Can I just ask the part above when you said, which city do you find is the greenest? You said it doesn't have the accessibility name. What did you mean by that?

Good question. So when you look at a form field, you have the visible label, which is in this case, which city do you find is the greenest? That's the visible label. But then there is also the concept of an accessible name. So that is basically the programmatic, like in the HTML code, that it's connected to the visible label. So it has the name for things like screen readers and other assistive technologies. If it doesn't have an accessible label, basically if you go through the page and you press tab, and in this case it would just announce radio button, but it would not announce none as its accessible name. The same goes here. It would say select a city, which works as a description, but it's not optimal. But like this, which city do you find is the greenest? That's the -- that should also be the accessible name. But in this case, it would probably say something like select a city combo box or something like that. So the accessible name is always like -- but do you want the screen reader or other assistive technology, the braille display to say.

>> Okay. Thank you.

>> Yeah. Perfect question for this. So in this case, in PolyPane, you can just press the Alt key and hover over. Why doesn't this one to work now? This is fun. Maybe I'm doing something wrong. So you can use this inspect element as well. You can see that from the bottom, the third up is missing accessible name. So basically, this says, this name, this label is not connected to this input field to this radio button. The same goes for here. and I will show how it is done well in a second. Same goes for here.

Is PolyPane a browser that is free? Maybe I missed this. I don't know. Have you talked about this?

I think I talked about it a little bit. PolyPane is not a free browser. It's free for students. I don't know what the details are on that. But this works in any browser. You don't need to use PolyPaint to inspect certain things. If you want to know what the accessible name is in other browsers, you can do your usual right click, which also doesn't work. >> Yeah, inspect. >> And inspect. Exactly. And then you inspect it. And then it looks like this. These are your Chrome Some dev tools, basically. And you can inspect, let's say, this radio button here. Because we talked about that. Why are you annoying today? Oh, because we also did put another accessibility issue in that actually breaks this. So that's fun. So this actually breaks on purpose. But if we hover over this, and then we can, I guess I can go on to do input radio, yes, here we go. So here we have the input field. You can see that it has the class align, I'll make this a little bit wider, so that we can read it a little bit better. That didn't work out too great. But basically, as class align, type radio name res value one. And then in the name, so this is in this table column. This is on purposely really, really bad. Oh, this is one too far. Oh, there it is. So, it just says in this table column, which you should never use tables for this. But it says none. And this is not connected to the input field. So, this input field has no accessible name. And you find that in Chrome, in the DevTools under accessibility, which is often like behind these two arrows. And then at the bottom, you would see under name that the name field here is empty. And then you also see where the name can come from, like ARIA labeled by, ARIA labeled from, labeled contents and titles. So you've got this hierarchy. thing that is on the top, most top, that will provide the accessible name. Just as a thing. This is all ARIA stuff as well. So, we'll hear about this a bit in two weeks. So, let's take a look at how this looks if it's done correctly. So, we go to the survey page here. We can now also inspect this element really nicely. And you can see that it is the same input type radio name res value one but it also has this id nn at the top which basically puts an id on it so a unique identifier and then here in the label we can say for nn so this input is now connected to this label and what that does is when i click on the label it also selects the input that it's associated with. So you have like for people who have Parkinson's or who have other disabilities who like do not have like fine mouse control, they can easier hit the target. So that's actually pretty good. And in the dev tools, if you click on the input, it will here at the bottom say From label, via the form attribute, for attribute, label none, which is not none, no label, but it's the label none. Bad example. And basically, that means that the name is none here. And in the screen reader, it would say something like none radio button selected in this case, because we have just selected it. go to the central park one. I think it's a little bit more obvious. So here the name is central park and it comes from the label. That means, and this is like for basically for next or the week after next, means also if you have an input and a for and you put in here another attribute like ARIA label. Grand Park. Then you're basically overwriting the actual visible label with the ARIA label. And that's obviously bad. Because now a screen reader user would hear different information than what's on the page. Don't want to do that. So there's a hierarchy in how something is named. This is like -- I mean, we will touch on this in two weeks. But usually you will never -- or how the accessible name comes to be is not that important. The important thing is what comes out of it. And is that the same thing that is also visually on the screen? And everything else, where it actually comes from is interesting for fixing stuff or not breaking things in the beginning. But in the end, for testing and just looking, doesn't actually matter too much. You know, where that comes from. But yeah, that's how that goes. In this case, we also have these boxes around and these are field sets. So when you go with the tab inside of this, usually it would just read non-radio button not selected. But that means you don't know what the actual question is, right? Because like, how would you? And of course, when you use a screen reader, you can use arrow navigation. Then it would go through all the letters and stuff. But if you are expecting a form, a lot of users just press the F button, which goes directly to the first form. You know? And then they would see that they're in the -- actually, like, here, quick menu or search or something like that. They would press it again. And then they would be, like, in the form on the page. And then they would just go by tab. That's generally how most people are using it. Especially if they think it's an accessible form. Which is not a given, of course. So when they go in there, they will only read, even if it's done, you know, otherwise correctly, but there's no field set around, they will only hear the options in here. So with the field set, you're actually adding more information. In that case, an accessible description. So this is also something we will talk about in two weeks again, but I'm gonna prime you for that a little bit. So it will say "None, radio button not selected, favorite park" because it's inside of this section. And how it's really announced, that depends always on the screen reader and on the assistive technology that you use. So some screen readers only announce it when you hit the first thing or if you come from the bottom when you hit the last thing. So basically once you're inside the group. But other screen readers announce it with every option. So it's like there's no right or wrong thing there. when you look at the dev tools, you also have -- well, you can have this small, like, person in the top right. And this is when you enable the accessibility tree. Which you should have an option here when it's not enabled in Chrome. I think there's just a button that says, like, enable accessibility tree. And then you get that. And if you have that, it will actually show that there's group favorite park. And then there will be, like, you know, two paragraphs, none, and then there's grand park, and then there's another grand park, because we overwrote the accessible name here. Should probably undo. But yeah. So this way you can actually see, okay, how is this structured? And this group actually gets their information from this legend. It's just like favorite park. So if you need more information on how something is structured, this accessibility tree can really give you like a lot of additional information on that. All right. And then so that's the most basic of things. on how to connect the labels to the actual form fields, and you should do it like that. What I don't recommend, what this website does, is that the currently selected field gets a red background, because that looks like you've already made an error before you typed anything. So that was, I don't know why we did that back in 2010, So 15 years ago I helped with this. So maybe we grew and now have a better understanding on this. I have two Nielsen-Norman Group articles about forms as well that I want to share. The one is error message guidelines. And the other one is about placeholders, which both are important to me and are more content focused than usually what we're doing. So this is not about technology as much, well, the placeholders is, but error message guidelines is not. So this is more like where do you position error messages so that they are good? How do you make sure that they are seen? How do you make sure that they're not like, you know, getting skipped over or like, you know, people think it's like an advertisement or something like that. So this gives you like all those really good guidelines. Like here you have the URL field and it's like the error messages very far away. you shouldn't do that. And they have a decent size of things, including avoid prematurely displaying errors. So if you start typing and you immediately get an error that you haven't filled out your email address, but you just started typing the first part of your email address, I think that has happened to every one of us these days. So that shouldn't happen. Make sure that it's human readable language, that you describe the issue very concretely. Sometimes you just get like, oh, correct your error, and you go like, I don't even know what I did wrong. So that's the idea. Be constructive. Don't blame the user. If the user does something wrong, it's always your fault. Yeah, and then there are some efficiency guidelines as well, like, you know, make sure that you don't, that users can't make mistakes, or that it's more unlikely. So your descriptions need to be good, your advice need to be good. Preserve the user's input when there is like an error and it needs to reload, that they don't have to type everything again. Very good practice. And, you know, make it as efficient basically. and they have a very good article on that. So there's a lot of good things in there. And the other one is about placeholders. And this is like a really old article from 2014, updated 2018 with new confirming evidence about placeholders and how good they are. So the basic gist is that if you have placeholders in the labels, that's really bad. So you should never use placeholders that replace labels. You can sometimes use placeholders that are showing a format or something, but then it also needs to be on the page for users so they can interact with it without disappearing start typing. Yeah, and so, yeah, so some guidelines, some reasons why you should not use placeholders. If you can, without labels, users cannot check their work before submitting a form. An error message is there, it's much harder to fix it. Fields with stuff in them are less noticeable. So if you want someone to fill out a form, you want to give them like a blank slate because otherwise they think, oh, it's probably already filled out. Yeah, and then there are a lot of like things about like placeholders in addition to a label and with accessibility, you have the contrast issue because there's not enough contrast to be read. You also have sometimes it's not real placeholders. I don't think that's an issue anymore. So you have to delete all the letters of the placeholder text. And I also think that screen readers now can do it because it's in the official thing. So, but these are the considerations and I think it's a good article for that. Let me take a sip of water. All right. Any questions about this?

>> Yeah, I do have one. So it's about error messages. I saw that you kind of scrolled past it, but it was about floating labels. I mean, I think, I might be wrong, but I think that Google decides the material design as apt. And I'm not sure if my question actually is, to be honest. (both laughing)

- Yeah, I skipped over it because I'm not a fan of floating labels and also Google did actually now step away from it. So they don't recommend it. and recommend is probably to, they don't use it anymore like widely in their designs because yeah, it's like with having smaller sizes, it's harder to read. Also you have the animation and to be honest, it's also a nightmare for implementation because you always have to, you need to use JavaScript or like relatively complicated CSS for it. And if something breaks, it's harder to repair. If you just have text there and you have your label and it's assigned to the input, you never have those issues. It's like it just works. So I think this is like-- how do I make that so I don't sound like someone who hates on Google too much? But I think this is an overdesigned, overengineered way to show labels. And I don't think it helps users much. But yeah, that's my thing. And they say, okay, they do fix some of the issues, but other issues are still a problem. Like five and six, what was that? It doesn't even have five and six here. of feasible stuff inside them are less noticeable and users may mistake it for data that was automatically filled in. And I've seen that, like, I've also seen like implementations of this where my password manager filled stuff out and it was then behind the floating label because I didn't like actively click into it, right? So it didn't think like there was text in it or it didn't detect that, right? So it's like, I don't think it helps. Like, if you want this design, yeah, do it. But then leave the text field empty. I think that's my general gist of what I would recommend. - Okay, thank you. - No problem. That's why we have these sessions. All right. Let's see. I do have... So I have some... So what I like to do for these, because forms are so important, I like to just show you a few forms that are... That have very common errors that you can find. If you do QA for accessibility, you will find. And you can basically just Google any, like, options. Oh, god. This is really bad. This didn't happen so many ads before. I swear. But basically this is just a collection of contact forms. Or sign up forms. And they are all terrible. And I don't think on purpose. But basically they say, like, oh, these are the most beautiful CSS forms. And it's really nice to just click on them and say, like, oh, this is an issue and this is an issue and this is an issue. Because that's how you learn, you know? So let's open one of those. Let's say this one. Go full screen here, too. So this generally looks pretty nice, but we already have some issues here. So your name is with the placeholder, and actually they're using the little floating label. So we have that. Then the time here is to be selected, 6 or 7 p.m. And then you have food, and you can basically select mushrooms or fish. And then you select the dining space. Okay, as a mouse user, not the worst. But there are several issues with this. So the first thing is, is this really a heading? It looks like a heading. It should be a heading. I bet it's not a heading. Oh, it's actually an H2. So that's okay. I think. Oh, man, you have to be really wide so it shows the image. Let's go into... There we go. So okay. So we have the book in place for your dinner. So that's good. And then we have here a form group and an input. That input is name and it also has a label. So this actually should, if we go to Ali, have the, why don't you focus on the input? This is really weird today. There we go. So the accessible name is your name. and has a raw text box. So that works because the for and ID are the same. So they are connected. Perfect, that's exactly what we want. So that works for your name and your phone number. Now time, that's different. That's like a dropdown, like a select box. But apparently we're not using a select box. So let's see what they did here. So they just have an unordered list where the first list item is time, and then they have two hidden list items that are both times. So this is not even an interactive element. So when I go through it with my tab key, I go to your name, I go to your phone number, and then I go to somewhere, which I can't see, And that's it. So this is a clear forms issue, you know, where you can't navigate to here. And, you know, so this is a problem. Same goes for the food. It's the same structure. So this is not how you use lists. And then you have a label here for the the different selections here for the table size, basically. And they have input type radio. And so you think they should be focusable, right? So one of the things is, this is not a field set. So the question would not be read. So it would just say, like, to radio button. But I think, yeah, you might infer that, or you might explore it. So not the best. But that I would say you need to have a field set around it in practice, like when I tested. But here you have the input type radio and the label. And when we tapped, it didn't look like we could focus it. The reason is it has a width 0, height 0, and then it's positioned somewhere else. So it doesn't show that it has focus. we can test for. If it does have focus, I press tab, and now I press the left and right arrow keys, and that actually works. So we are focusing something, but there's no visual indicator that we're there. Can use something like track focus to better see where we are. So this has like the little indicator on the bottom right. It also doesn't show anything here because we are physically shoving this to the left -999 pixels. And this is to replace it with this more fancy view. Also should probably say "two person", but that's like minor stuff. But if you are inspecting this and you say "oh, I really like to know where I am", while While inspecting that you can actually disable this dial, and this dial, and this dial. And then you see the radio button is then just placed in the center of here. You can also... Well yeah, if you break the positioning it breaks pretty badly, but like... Oh no, what did I do? But yeah, if you tap then here, you see that there is a radio button floating here. But it's absolutely positioned. So it's like off whack. If we undo it, tap. And then we have, like, you know, it corresponds to the thing. But obviously it looks broken. But this is a good way to make sure that the right thing is focused when you're seeing Yeah, and then the book now button doesn't have enough contrast. So that's not good. So we should know that. Now this is something you can do manually to test for form issues. But there are tools to do that as well. So if we go to here, outline and forms in PolyPaint, but there is an online tool that does this too, and I will show that in a second. Then we see the form here, and it actually gives us some information that we can use to inspect it. So we have seven total fields. One, two, three, four, five, six, I don't know. What are the seven fields? I don't know. Two required fields, which are not visually represented. This is also a problem. And one button. It's the book now button. I think we can say that pretty definitively. And then we see like this input with the text and the ID name and the label your name is required. And then you can even look into details. Yeah, just the ID here. So it should have some indicator that this is a required thing. The same thing goes for the number. Then we have the two, four, five. Oh, yeah, time and food, they weren't real input fields. So that's why they're not in the total fields. And then you have the radio buttons here, which they are grouped correctly. So they all have the same name, not ID. And then you have, like, the ARIA label. And you can see where that comes from. And also see that they're not required. Radio buttons can never be required. They're always required because one is always selected. So there's not really a required field thing there. I think that's always better. And then you have the submit button at the bottom. So yeah. So you can find some issues here. And you can even highlight what are the form fields. And then you see that these are not real form fields. That's the first example. Let's go to the second example. Let's do focus again. So this is student registration form. And here we can also click on the labels, so this works. But we also see that we are skipping over this gender selector. I don't know why they need to know that for student registration, but it's a good example for like radio buttons that do not work. So again, we can go into our... Oh, and I wanted to show the online version of this form inspector and how to use it. Let's do that right now. Polypane form inspector. I do not... Oh. I have put my computer into a reset. Am I a robot? I don't know. Select all the buses. Even more buses. Is that enough buses? Okay. There we go. So this is the blog post about it. So that goes through all the information. And then I think, where is the online one? Oh, available online for everyone to use. So in this case, you're posting your HTML form code in it. So this is what we want to get out of it. And to copy and paste the HTML, we go to the DevTools again. And then we just search for the form element, which that usually should include all of your form. If it doesn't, then that's a problem already. Then you can edit it as HTML. And then you copy all of it, go to the form inspector, paste it, and then analyze it. And that will bring at the bottom-- that will copy and paste this into the chat as well. So you don't need the PolyPaint browser for that. We'll basically bring up the same information on the web page. So there's no action specified. And then you see your input. You see the type, you see the label, see the input here, and what is required as well. And then you can also expand and collapse the details. So it works pretty much the same as the others. See that there are inputs for like these gender markers. There's a select for the state, which has a proper thing. So this is actually pretty nice. And then you have the two buttons, including reset all and submit form. And you should never have a reset all button, because it just throws stuff away. But what we have seen is that when we tap through here, we cannot select one of these radio buttons. And why is that? So, we see we have the form, we have the radio buttons here. And then the form and description is totally fine, but if we go here to styles, it has visibility hidden on it. The visibility hidden means it's also hidden for screen readers. Because everything that's not visually on the screen, screen readers also don't want to read. Because you could hide stuff to reveal it later. So you know, you don't want that to have read. If we uncheck the visibility hidden, you can see it's pretty hard to see. I wish I could zoom in a little bit more. Maybe I can. Like, let's do this. Does that work? No. So you see the real radio buttons behind this fake radio button. Because this is just for show. This is just to make it look like this. And they do it by having a background image on the label. This is just to show, in this case they use a span. Just for show, just so it looks nice, right? Because they want their orange radio button there. And if you don't use that, then you can't... Well, you couldn't use your company colors or something like that. So if we just hide that, or I can just delete it, then we have the normal radio buttons there and then we can just tap to them and then we can just go back and forth. And again, the radio button that is checked, I can just delete that. So this is just like -- so if they didn't want to do this, like, vision flourish, they would have automatically had an accessible version of their form. So they broke it afterwards. Now we do have now CSS that can actually do colors very well. So if you do... oh god. Vacation Brain, come back. I think... no, it's not appearance. It's something with a... Accent Color. There we go. The first thing. Accent Color and then I use the color that I just copied, the orange. Where does the black line come from? Is that this? No. I don't know. doesn't look too bad. I think there's something else going on. But if we do that for both, accent color, and then we tap to it, then we can see that we could have an orange dot for our focused, or for our selected radio button really easily, without doing any trickery or any other things that might break the accessibility. So that works actually pretty well these days. So I guess the learning here is like it's easy to, like, for style reasons to break the accessibility of these form elements. Any questions about that? have to break myself a little bit to allow for questions.

Yeah, I had one, but I think you just said it. You said it was kind of sloppy, front-end development. Is that right?

Yeah, I mean, that's all of accessibility, right? Okay.

Okay, but my real question is, I think you touched on it on the video, but required fields. I think you said that it was important to make it clear. So one example, it said required for one field. But something that I've seen that's really usual is that people just use the star. You see it in Google Forms. Is that fine to use? Or does--

Maybe. So there are people who are more strict about this and people who are less strict about this. Generally, every icon that you use, and the star is also an icon in that case, needs to be described. Like, you need to have, like, oh, this icon means that the field is required. So, I think having it without, like, a text that says, like, all fields marked with a star are required is, I think, not the best way to do it. Like, you should always have the information there. Because there are also some websites who use the star for like, or who use other ways to mark required fields or not, right? So I think it's always good to have it, although it's pretty widely understood. But especially people with cognitive disabilities or people who are culturally, you know, not used to star smacking required fields might appreciate the information. But then, like, if you declare it once, you can use it.

>> Okay. Because I've kind of never seen maybe I don't remember, but I've never seen a field where it says required. is always the star.

Yeah, I mean, yeah, I mean, the thing is like people, I don't know why, but they feel like they can't put required on the field for some reason. You know, and the star looks elegant and like nice and not obtrusive, but in reality, it's like And there are some research into that, but I don't have it handy, unfortunately, that says the star is recognized and people know what it means in general, but it's not as clear or as obvious as just writing required. And so people, on average, need more time filling out a form if there are only stars on it, especially if there are form fields that are usually not required information, like birth date or something like that. So people give people a harder time. So I don't think that's necessarily worth it. But yeah, people want to avoid using stuff like required and things for some reason. I do not understand that.

I have seen it though, when you use the star and you make a mistake as a user, I've seen that the error message then says, this is the required field. Is that correct? Exactly.

Yes. And that needs to happen. Like if you make a mistake and then yeah, you need to get the information. I mean, you can do it after you submit it to form as well. That would also be fine. So you don't have to do it immediately. But yeah, if there's a required field and it's not filled out at the time you test, so that can be either in line or after submit, you have to say like, "Oh, this is a required field," or "You must fill out this field," or something like that. It needs to be very concrete what the error is. Good question. Good question.

I'm not sure if you already answered this. But you mentioned this success criteria 3.3.2, labels and instructions. So it says that labels and instructions are provided when content requires user input and we instruct the user when they ask for this input. So do you mean by what you mentioned before, this or why is this needed?

Yeah exactly. So when the content requires input, that doesn't mean a required field. I think this is like a little bit of like a thing where WCAG uses the word differently than we would use it like colloquially, right? So basically whenever you have a field that the user needs to interact with it, so whenever it's on the page and visible and interactable with, then it needs a label or instructions. So you have to say like, you know, what it does. Yeah. And a lot of people say like, if there is a star, that is not enough instruction on its own without like an explainer text. And so they will say, like, oh, you don't provide all the instructions needed to fill out this field. So that's why you should have -- you should or you must have a text that says, like, star means this field needs to be filled out.

>> Okay. Thank you.

>> Yeah. These are -- like, this is such a small success criterion. And it's like so hard to parse and understand sometimes. It's really interesting. But yeah. It's really trying to make that argument. Yeah. This is another one that you will find a lot in like when you test. We will get the usual stuff like these are probably not accessible. Like here you get the error message but it doesn't actually tell you why it happens. And this also, like this only has the star. It's barely recognizable as a star, right? It's more like a dot. But it is. And it doesn't say like star means required. So and then like, is the check required? You know, it's like, I don't know how that works. I never used to check in my life, so I'm not used to that. But then you have things like this slider here. At the bottom you can use your mouse to slide it around. There's no way to slide it around with a keyboard, like it just jumps over it. So you will find stuff like that all the time. I think now we're focusing on detail. We'll switch on the track focus, there are also bookmarklets that do that, so we can better see. We're now at launch detail, and then payment detail. And the radio buttons, same thing as before, just not correct. As radio buttons are, they're hidden. And then you have this drop down is also not a real select drop down. But there is also no way to -- oh, there's a way to focus this donate thing. But you cannot -- if you use the arrow keys, they just move the page. So that's not good. And there's no way to change the stuff using -- just typing the number or something like that. This is completely inaccessible for people who are using the keyboard. And if you take a look at that, here, you can see that they are actually using an ARIA slider, but they have not, and we will talk about ARIA in like two weeks, but they are using this slider, which basically allows you to make an accessible slider thingy here, but they just implemented it wrongly. So, you can focus on it, but then you cannot change it because it doesn't have the event listeners to change it. So, you need to use basically JavaScript to fix those. So, this is also like one of the things, like, implementing this, you are taking up all the responsibility to make it accessible on your own. Right? And so, unfortunately, that's not a good way to do it. And so you should use built in UI elements. Like you could just have an input field that says like donate amount. And then you would be good. There is actually a slider component in HTML that works pretty well. If you know what you're doing. So, yeah, if you build it like that and you can't use it with the keyboard, then, Yeah, it's inaccessible. And that's obviously not a good experience at all. So yeah, you will find that a lot with like sliders and stuff that are not good. Yeah, that's a t-shirt demo page. There are a lot of accessibility issues here on this thing. I think you can't select a color and you can't select a size and stuff like that. And it's pretty much the same thing as always. These are not real buttons or interactive elements. And then, yeah, I think the tutorials I talked about that in the video. Oh yeah, and for error messages I like to show this example from the UK design system, which basically says like a good way to do it is after you submit your form you put on the top you put like, oh, there's a problem, like, and then you just list all the issues and you give people a link to where the issue is. Right? So in the form, so this would go to your full name field. This would go to the passport date field. And that's a good way to, like, ensure that, like, you know, there is cohesion and, like, it's easy to see, like, oh, there's a problem. What is the problem? And then they also recommend repeating the error in the label or in the ARIA description. So that's a good way to do that. And they're encouraging people to be very specific with their issues. And I love that. So I will put that article into the chat as well.

Yeah, I have a question. So right now we're talking about good ways to do it. But when it comes to VKUG, I've seen some examples where they don't list it at the top and don't link it. But they kind of just make the fields red and they write a message underneath. Is that -- does that pass? - Yeah, that does pass.

As long as there is a concrete error message, like what the error is, then that meets the requirement.

- Okay. So from your experience then, would you recommend this way to do it?

- I would recommend this way to do it, yes. I think having at the top, so my personal philosophy is, don't get in the way of the user, let them fill out the form. If there's something wrong, bring up a report that lists the issues like they do here and link to the form fields and then let them correct the form. Very like two-step because a lot of people like to have like inline validation and like just jumping into the user and say like, "Hey, this is wrong or this is going wrong." And stuff like that. I like the calmness of just a form and I fill it out as best as I can, or the user fills it out as best as they can, and then you submit it and you get only back what is really problematic, right? So yeah, I really, really strongly prefer something like this where you get really clear indication. And I mean, these are one of the guidelines that Gov.UK has, which WCAG does not care for because it's not the basic accessibility thing, is that they basically say, only a limited number of questions on each page, like one, two, or three questions as the maximum number of things. So you already have a lot of steps. So if you have to go back and redo something because of an error, it's always very focused. You know, like here you have only one thing that you fill out usually. don't even know. No, they don't even have like a thing where you have like 10 fields and like three are wrong or something like that. You could do but like, yeah, I think form-wise, what gov.uk does is really, really good and well researched as well.

Okay, thank you.

Yeah, no problem. So that's also all I have prepared. So if you have any other questions, Feel free to ask them now. And if not, I will give you back a little bit of time to process all of this. And as I said, you can always ask in Slack. And for questions, we also have the Bookable tutoring. Don't forget that. And feel free to sign up for that. like, you know, we're here to give you all the information that we can. And this is not supposed to be like just a one-way street where I'd tell you what to do. It's always like good to have questions and discussions around this.

Yeah, I have a question. Me with the questions. Yeah, good, good. It's about the final. No, it's about the final examination. So for example, when you go to university, it's very formal. You write it in a certain way. Is that applicable for this assignment or we just write it?

Just write it. Okay. We don't grade you on form. Yeah. We just grade you on content, on what's in there. worry too much about the formatting or stuff like this. It's all like we don't super care, as long as it's readable and we can scan it. Because one of the things is we only have this two tiers of grading, either you meet the requirements or you don't. And then you have like your higher level of meeting the requirements with the video. So, you know, what we're looking for is that you understood what the task was, that you think like, or that you find some of the issues that are on the side, like it also doesn't need to be like super comprehensive. But just so we see that you have participated, have been in these meetings, have watched the videos, and you came to conclusions, and they are not completely wrong, and then we're good with that.

Yeah, because what I've learned, and I'm a designer, so I will focus on that area, But what I've kind of learned is that it is the designer's job to kind of, for example, focus, focus. What do you call that when you use the tab and the order? Yeah. It's up to the, to the designer to kind of determine what the order is. And that could be, I mean, as a user, I can interpret it in a different way.

Right.

So in my paper, for example, could I discuss that?

Yeah. I mean, if you find, so you pick a side and then you go through it and you basically, your evaluation is like, does this make some kind of sense? Like it doesn't even need to be perfect. If you feel strongly about it, if you say like, oh, this generally makes sense or this works well enough and I can reach everything, but I would have done it differently and you want to discuss that, then feel free to do that. You know, we will not like tell you not to do it. But that's not necessarily a requirement, you know, if you, if you find it's good enough, then that's good enough for us too. Okay. Okay. Thank you. No problem. Any other questions? Or anyone else a question? If not, thank you very much. Good first, like very heavy first, first meeting of the year. Should have scheduled that differently. But that's sometimes how the dice roll, right?

So thank you very much and have a good rest of your day. Take care. Thank you. Bye. Bye. Bye. Bye.