All above combined

Hello and welcome to the Forms Week, Forms Tutorial Week. This week we're going through

the Forms Tutorial. This is the easiest way to give you both, like something to read and

something to listen to. And so we're going through this. Now, forms are everywhere on the web.

Whenever you interact with content, whenever you can leave a comment or upvote something,

That's all what we consider form elements, anything that has interactions.

So forms are super widespread, super important, and you can't basically, you know, not use them if you want to have some interactivity with your users.

And because you have this interactivity, of course, it's incredibly important that it is accessible because otherwise, you know, you can't reach those customers.

And there are a couple of technical things that we will look at, but there are also a lot of non-technical things.

when you are designing a form input, and if that's like a simple form, like common form,

it's usually pretty straightforward. You know, you go like, oh, these are the things

that we want from you. And then you have, you know, just a submit button, something like that,

pretty straightforward. But sometimes we have these like very complex forms where you have

multiple steps. And then, you know, it's much more about like the design of the form,

in addition to the technical correctness. Because something that is technically okay,

can still be very, very hard to use, or impossible to use even, although it's technically accessible,

you know, if your wording is bad, if you have a lot of steps in between, you don't want to do that.

So at some point, form creation becomes like more of a, you know, an art instead of a science.

But you always need both, of course.

And so I think that's like one of the biggest challenges when you get to like complex forms that you have that.

Now, traditionally, forms send data to the server and then, you know, there was a response back.

So if you have something like a comment form on a website, on a blog, you type in your comment and you press send and that data gets taken and sent to the server, which then saves it into a database and keeps a record of it.

And then, you know, gets back to you, basically answers that request and says, yeah, hey, I've saved this.

And then you get like the page reloads and you get this information.

Yes, comment has been sent or just appears or something like that.

But there are a lot of form controls these days on websites that don't do strictly the server roundtrip stuff.

So you see that you have comment and you press send.

And instead of like reloading the page, it just uses JavaScript to send it to the back

end and then displays a message to you.

It might not make too much difference for you as a non-disabled person, if you are one

of those, but giving that response and feedback back to the users is incredibly important.

And so you have to think about that as well.

And those basics, we'll start from the top, I go linearly through this tutorial.

If you rather want to read it, that's also totally fine.

I probably go into a little bit more details.

I might also give you a little bit more context in what I prefer, but in the grand scheme

of things like reading this tutorial is already a good start.

So let's start at labeling controls.

So what do I mean with that?

So if you look at this example, so this is a typical form control.

You have something where you can put in text, you can check the checkbox, and that's usually

done with these input elements.

So when you will do reviews for accessibility, you will see those inputs here, there is one,

there, one there.

And these are basically, hey, put an input element, give user input or get user input

on this page.

And the label is this part at the front here of the text box and at the end of the checkbox.

So you already see that depending on the interactive element, the label can be somewhere else.

And we get into like other more niche stuff in a second.

But yeah, generally what you want to do is associating labels explicitly.

And that means that if you have an input that has an ID first name, you can actually use

a label for first name and assign that.

What that does is that when a screen reader user clicks or taps into the input field,

they get this label announced as the name of this input.

And that's super important because otherwise you just have like text input and you don't

know what you have to do.

The same goes with the checkbox.

If I press tab, now I'm on the checkbox and the checkbox on its own doesn't know what

it is.

we have the for and id relationship here, it knows that subscribe to newsletter is the actual label

for this element. And that's, you know, pretty straightforward. And that's always what you need

to do. Like you need a visible label as well. So visible label, and then you have to connect it

to the input element. Sometimes you want to hide label text and you can do that in some instances.

Like in this example you have a search button and when you have the search button this is a very

commonly used user interface component. I want to say if you have a search button here

here, you can, you know, you don't need to have search colon before the text input field.

This together works as the label, as a visible label, and as the label also for the text

element.

Now, if we just put the text box on the left and the button on the right, then that means

they are not connected.

So this text box would not have a name.

It would just say like text input and that's it.

And that would be bad.

So there are a couple of ways to do that.

So you can use a label element and hide it using visually hidden.

That's fine.

You can use ARIA label and we're going to talk about ARIA label next week.

But ARIA is basically a way to more or less directly communicate with screen readers.

And in this case, you have the input and you label it, you put a name on it that goes into

the string at the bottom, at the back here. And then this is the same thing. I will not go into

the ARIA labeled by example, because we can talk about a lot of ARIA next week. It will be like a

really big chunky topic. So I don't want to like do too much talking about that too much right now,

because this is like, you know, need to know the basics. Here, you can also use the title,

the title is the thing that shows up when you hover over something, you can you can have the

title, but this is only fallback. I would not use the title, so ignore this part. Yeah, and this is

the visually hidden class that puts away the label, but make sure that the label stays inside

of the, like, you know, can be read by screen readers and whatnot.

You can also associate labels implicitly, and that's good for some situations where you don't have access to the code.

So you have an input somewhere, but you need to label it, but you can't put an ID on it.

This rarely happens these days, but it's still useful.

So you can just wrap it inside of a label and you can do the same for the checkbox.

And the nice thing about that is that all the distance that is between the checkbox and the subscribe text, that's all clickable.

So one of the things I didn't say that I should have is that if we go back to our top example, labels are clickable and will set the focus to the text field or select the checkbox or radio button or what have you.

So I can click this label and it will automatically put the cursor in here.

I can click this label and if I don't do a right click, it will check on and off.

the text, which is super useful, especially for people who have motor disabilities. For example,

you want to make that clickable area as big as possible and labels are great for that.

Scrolling down. Yeah, buttons are a little bit different. So we have already seen this,

the search button. So there are two types of buttons in HTML. This is for various historical

reasons. Really noticeably, the only button that you really should be using is the button element.

The input type submit or type button, they don't really do a lot. So if you have a button type

submit, that basically submits the form. So if you have a form, and that does the server-side

submission thing, then button type submit is the right thing. And then you can label that button

by putting the label, the name of the button inside of the button element. And the same goes

for like buttons that do not submit a form, you want to have button type button for that.

Now, if it's a submit button or a non submit button is not announced by assistive technology.

So you always have to be very explicit with your labeling and make sure that, that it fits

what you're doing. So as an example, I go to my website. Really quick. I have this preferences

dialog box. Let me make this a little bit bigger for you. And that opens this modal

that has a close button and a safe button. And this is a submit button and this is not. But here

In this case, I use close and save as my two button labels. And if we look at that in the

inspector, which open on the right, but doesn't want to do that. There we go.

Then we can see that, you know, this is a button type submit close, and this is a button type

submit safe because they both do something. So for example, if I change from system setting to dark

mode, the close button submits that form in this case to say like reset it to not being in dark

mode. So that's why this is also input type submit. Also it's inside of this form inside of

the dialogue. So that has different, that works a little bit differently than normal forms that

are not in the dialogue. Yeah, and I think that's all there is for buttons. Just put like the,

the action word in there, like submit, cancel, save, delete, stuff like that.

I always like when it's an actionable word and it's not something like deletion or something like that.

That makes little sense.

There are not so much rules, but guidance on where to position text labels.

So if you are in left to right reading language, which most of the people in this course are, I think, then you want to put the text before the field or on top of the form field if it's a text label.

and after the form field if it's something like a checkbox or a radio button, basically like it is in the example at the top.

So here we have the first name on the left and here we have the subscribe to newsletter to the right.

And if you look at the example and you can basically like change the order.

I can just drag and drop that.

I cannot.

Give me a second.

Because I think once you see it, it feels like, oh, yeah, this should never be like that.

So if I change this around and this around, don't you want to go over there? Yes, you do. So, you

know, this makes no sense at all. Like having the checkbox at the right, it still works. It's still

technically accessible, especially if the label text is in different length, then it's very hard

to scan and you don't want to do that. Now grouping controls are also super important because sometimes

different form elements they just belong together. So you want to make sure that that is clear to

people using screen readers to other assistive technology. And you're doing that basically by

using controls with field sets. That's the easiest way. And this is the only thing that I recommend

from this page. So if you go to this section, associating related content with field set,

then you'll see that there is a field set. In this case, it's named output format. And it has three

radio button text file, CSV file, HTML file, and you can select one of those. In the HTML, this

basically looks like this. You have field set and legend. The legend always needs to be the first

child of the field set. So if you're doing accessibility testing, you'll need to look out for

that. But then you can basically do what you want after that. And here we have the input, the radio

button, so that's type radio instead of type checkbox. And then we have checked because this

is the first one and we want to have that automatically checked. Then we have the format

CSV and that is not checked and we have the label after that. Now what happens when a screen reader

comes across this, it will read "CSV file radio button selected" in this case, and then

it will say "output format".

And that basically gives you that additional information that, oh yeah, this is the section

for the output format.

And that's especially important if you have multiple similar things.

But let's first look at checkboxes, it's the same thing. Basically, so in this case, I

want to receive the weekly newsletters offer from the company and that would be also an

office from offers from the company. Checkbox unchecked. And then I want to receive as the

description.

And here we have the example with the related fields.

So in this case, we have duplicated name, street, number, city and subcode fields, input

fields.

So just having name input field does not give the user enough information because they should

be able to distinguish between those use cases.

So in this case, it's name, you know, edit text and then shipping address.

And then you have name, edit text, billing address.

And it's like, oh, yeah, that makes a lot more sense than just having like name and street.

And that can make it much easier to be mindful and knowing what's happening between those fields.

Yeah, and the code is basically the same.

Wrap it into field set, put the legend, which is in this case the shipping address at the top.

and then you put inside the field set whatever you want.

Now there is this note that the field set can sometimes be not announced or it might be only

announced when you enter the field set and stuff like that. That's all true. Users are used to how

they have their screen reader configured. So don't worry about this. This has been

around for a long time, so there's no need to really look at that and make sure that

I'll make anything else in that situation. It's a really simple solution for a lot of use cases.

All right, let's look at form instructions. So instructions are basically additional information

to know how to fill out a form because sometimes it's not straightforward. Like,

if you have a date input field, what is the text format that you have to put in there? Do you put

the day first as you know, people usually do here in Europe? Or do you put the month as the first

thing like people in the United States are often doing. You need to specify that and that's why you

need instructions. And there are a couple of ways to do that. And the easiest way to make sure that

you have instructions are overall instructions. Things like all fields marked required must be

complete. And you put that at the top of the form. And then you have a good information of

what the user needs to do. The same goes with dates or passwords or something like that. You

can just put that all up front and you're good to go. But often you don't want to do that or you

want to additionally have inline instructions. And inline instructions, you have seen those

are basically things like month, month, year, year, year, year, like this expiry date example.

And you can do that in different ways. So in this case, and this is my preferred way,

because I think it's super easy and super straightforward. You just put the instruction

into the label and just say expiration date month month year year year year um and then

this will be read when the screen reader user goes into the form field the most easy thing to do

but sometimes you don't want to do that or you can't do that and most of the time that's because

of design considerations or design restrictions. So designers can make this harder. So you will

see this in practice and usually done wrong. So this is the example. You have an additional

information underneath the label and then you have your underneath the field and you have your label

here, in this case on the left. And so this means that if I go into the field, it will only read

expiration date, but not if I use aria-labelledby. This is again one of the aria things. I just

mentioned it. Don't think too much about it. We will explain it more in detail next week.

So what I can do with aria-labelledby is basically

I rope in this label here with one ID and then the description here with the other ID.

And basically using ARIA label by I can connect them and then they will both be read.

First, this will be read, then this will be read.

And it will have the same result as the first example.

So I want to go into the inspector and then we can go into elements here and then go on here.

And under LE or sometimes accessibility, you can find the accessible name.

The accessible name is basically what the name of the form field is.

And you see that this is from the input.

This is not from the label. The label is before that. If I click on that, it doesn't want me to click it.

Oh yeah, now I clicked it, so it does not have an accessible name, because that's not the thing.

It's just a container for the accessible name.

And then if I click on the input here, it says the accessible name because they are connected through the for and ID normally as we talked about.

And then this aria-labeledby, if I take that, inspecting that, we basically see the same thing.

Expiration date, colon, and then mmyyyy.

And that's because this aria-labelledby basically points at this first and then this code second.

It's pretty neat.

But also, like, you see how much more code that is.

Like, you have to have two IDs.

They have to be unique on the page so you don't get, you know, accidental, like, wrong associations.

So they should be unique.

And then you need the aria-labeledby and you need the two ids and you need to smush them together properly.

So it's already like a lot of more things to do.

You can also use aria-describedby and that's basically using the label normally.

And then you use aria-describedby here.

And that will basically also associate this text, but as secondary information to the form field.

Now you might say, oh, what about placeholder text?

So we see this often in forms like here that you have like email and then instead of an empty field, you have like joe at example.com.

And if you click into it, it stays and then you can type your stuff.

And what we also often see is that the label is not even there.

So you don't, you miss completely out of what this is once you start typing.

And that's actually a WCAG failure because you can't have an unlabeled field.

And once you start typing, even like a space, you don't know what's going on if you don't have a separate visible label.

So you always want to have a label.

Placeholders are not a replacement for labels.

Sometimes these examples, so the placeholders are just examples of data that can in there.

Sometimes that can be okay.

But in general, it is like super confusing for a lot of people.

So I have seen people who clicked into like a field like this and first try to press delete to delete the email address because they don't realize that it is just a placeholder.

And that's always enlightened to see.

You go to even people who know what they're doing with computers and stuff,

and they click in it and by default they press delete because they just assume it's text in there.

So you don't want to do that.

And if you have longer forms, users might even have the impression that they have already filled out sections of the form that they don't have,

or that they don't need to fill that out, or that this is like default stuff and they can just leave it in.

So they might not go in there and adapt that to their own needs.

So in general, placeholders are bad. Don't use placeholders. That's the moral of the story.

And one minor thing there is that placeholders are generally not meeting WCAG 2.1 success criteria.

so uh that's another thing that uh for for contrast uh i should say that's like another

ding against them like you need to like put placeholder color and make sure that the opacity

is reset because some browsers use that for the uh the effect um and make them visible and uh

And yeah, that's additional, you know, additional stuff that you need to do that is in the grand scheme of things totally unneeded because you don't need placeholders.

Never use placeholders. Placeholders are bad.

And I can say this again. Placeholders, they are bad. Don't use them.

Yeah, super important.

Validating input is also super important.

Now, you start filling out a form and you do stuff, and sometimes you just type something that is not correct.

You mistype your email address.

You enter some ID and it's not long enough.

Your form should be able to say, like, hey, this is likely wrong input.

Please correct that.

And that's what validation is for.

And there are a couple of ways to do that. What this page shows is the built-in browser validation

and that's quite okay. But there are better ways to do that. For example, one of the things is,

well, I just show it. Why talk in the abstract when I can talk in the, like, you know,

in the concrete, I guess. Don't talk in concrete, kids. Okay, so if I press submit here,

it should show "Please fill out this field", which is great. But it is also like a thing

that comes from the browser, and then it just disappears at some point. So I press submit again,

please fill out this field and it goes away after a couple of seconds. Now, if you have a small form

like this, probably okay. If you have something longer, people might just not see it. And you

can do that by adding required to the input. And that will also, in addition, announce that this

input field is required, which is a good thing. And you should do that. If I put in my name,

or, well, that's not my name, but if I put in anything and press submit, you know, it

does actually submit it.

And then we get back to the tutorial.

So, yeah, so you can use those to validate common things.

Here we have a couple of different inputs and that might also be interesting for you.

So as you can see, there are different things and this is all normal HTML input.

So for example, here we have an email input field.

If I do "Verkäif", which is not a real thing, and then press submit, it will say, "Please

include an ad in the email address."

This is missing an ad.

If I put an ad at the end, I will press submit.

Please enter a part following the ad.

So it is even intelligent enough to do that.

But then if we add more text there, it will just submit because that's how the email validation here works.

Oh, they are not marked as required.

That's why it's reloading.

So that's how email works.

So I will pretend we have an email.

Now for website, if I go and put in Yacht Hill.net, it's a website, right?

If I press submit, no, I have to enter a URL.

And that's like where you see like, oh, this is like a terrible error description because

what they really want me to do is to put in the http:// before the yachil.net and then this would

work. And we have number and of course if you put in like an a now I press a on the keyboard and

does nothing so this is how it's supposed to be. So you can't submit something that's not a number

you would think. And you get these like little buttons. These are actually in 10 increments.

And I think if I put in five, it should complain about that maybe? Yes.

So please enter a valid value. The two nearest valid values are

zero and 10. So if I go six and press submit, yeah, it also does zero and 10 as the nearest value.

So you get this information because I've constrained this to those things and I get the answer.

Is this message, how long it is there, enough to read it?

Probably not.

Yeah, but I can also put other stuff in here like "e", which is, you know, the Euler'sche

Zahl, the Euler number, I guess. I can also put probably Pi in here. I don't know how I would do

that out of the top of my head. But yeah, you can also put non-numbered numbers in here, but

this is constrained to these numbers that I set like every 10 things. Then we have range here.

We have the slider and that works also with the keyboard. So this is left and right arrow key up and down arrow key

Which works nice. Don't think there's constraint on that

Nope, just do it and then you're back here

We have a date so

This is the date input. So this makes just make sure that you can't enter something that's not the date at all. So but I can still say four, five, six, 12, 12, 12, 12, stuff like that. And there is even a calendar. And in some browsers, those calendars are accessible and others they are not.

Here you can really nicely go through this chromium. So that works well. You can have like 10, 30 here. And you can even have like this time selector. That's my brain was like date selector, date selector, date selector, but it's a time selector. So super useful.

And that prevents basically users from making bad decisions.

So you want to do that.

You always have to verify it on the server side as well.

Because I can go into the HTML and just change anything.

Like this now says 1935.

And I couldn't change that.

But if I go into here and into there, and then I can go basically into this, and can then say value test and press return.

and then the test value would be sent to the server. Like if I remove input time and say text,

then it will be revealed. Should have been. Oh, that counts as changed, I guess. So yeah,

but you can do manipulations like that. And so you always have to also test it on the backend and

then throw errors to the user if something is wrong. Yeah, oh, yeah. And this is like

a super, super fun. Little example. So this case, this is about German license plate numbers.

And you can have these patterns, which are regular expressions, which if you don't know what that is, regular expressions are basically a syntax to say like, okay, I want to search for something.

I define a pattern and then I can search things in that pattern.

So in this case, it says like from A to Z is allowed and then Ö, E and Ü.

So the umlauts for A, O and U and between one and three times.

So that's basically what this means.

And then there must be a space.

And then we have A to Z for two to four times.

So one time A to Z is not enough.

And then we have zero to nine.

So number between one and four times.

Theoretically, you could say, oh, and optionally, there's an E at the end, because that would be for electro cars.

They would have that.

But so you can actually validate stuff like that.

So you can say, so if I have, let's say, PSAB123, this would be a valid thing because it has two here, two here, and then three numbers here.

But if I go 56, it says, please match the requested format.

Now, this doesn't tell you what the requested format is.

You have to know that.

So for the city, I could do like, if I do like Cologne, and I don't know what the city thing is, you could Cologne, Cologne, which is obviously for, which is not allowed.

So we'll also complain.

But if you go CG, that will work.

CG is not the number plate of Cologne. That's just a K. I know that.

Yeah, but that's a fun thing where you can be like, oh, how is this supposed to be working?

And then you can at least give your users a little bit more information. Now, you should

always be forgiving to different input formats. So, for example, if you have a credit card number

input. You might theoretically have like 12 numbers and you want to have them in four packs

with a space in between. But maybe a user wants to put dashes in between or wants to just write

them out in one line. Then they should be able to do that. Same goes for phone numbers. Don't say

like, oh, you have to put brackets here and spaces there. That's all like that's not useful for you.

Well, it might be useful for you, but it's not useful for your user.

And you can always, on the back end, reformat it when you output it.

So don't do that.

Yeah, and in general, you want to do the client-side validation, which is these like, hey, change your format, enter the right thing, something like that.

because it's immediate and it gives you the immediate feedback.

And we will talk about ARIA Live next week.

And that will have a lot of other things,

how you can get this immediate feedback to users.

And of course, you will also want users to check their input.

So if you can delete something, do you really want to delete this?

you know something like that you want to give undo functionality that's one way to address that as

well is to allow just deletion but then you have like a trash can where you can claw stuff back if

you need to and yeah and these are like important principles just to make sure that users don't do

anything that is that is bad for them and especially if it's destructive like deleting

something you always want you know to have a net and and make sure that it doesn't happen just

you know in a click and then the user is like sad they have to phone you and then you go like

I can't do anything because I don't have any backups for this or something like that you know

You don't want that to happen, so you always want to confirm with the user that this is really the action they want to do.

Notifications.

They are important for giving the user feedback on what's happening on the form.

There are many ways to do that.

Here are a couple of best practices mainly.

And if you're testing, you would just make sure that one of these is available.

So for overall feedback, things like, oh, I've just sent that form and there was an error in it or it worked.

Putting it into the main heading is a very good way to do it.

You can also put it in the page title.

The page title is always read the first thing when you submit something.

So this is basically the first feedback for the user.

You can use dialogues like this safe dialogue.

Thanks for submitting the form.

That works.

Usually don't want to do that.

But if you're using JavaScript, you need to at least give some feedback to the user that something has happened.

Nothing is more frustrating than clicking a button and don't know if something happens.

And then you click it again and again.

And then you see that you have actually submitted that comment.

seven times instead of once. Then you want to list errors. That's also a very good approach.

Just make sure, like in this example, that all the errors are listed. The first name field is empty,

a required field must be filled. It's a required field and must be filled in. And this links,

Actually, that's the idea behind this example, links to the form field.

And the date field is in the wrong format. It should be similar to the format that is used.

Yeah, and here it's in a role alert. This will be announced when it's added to the page.

page. So if you're using that to add it through JavaScript, then it would be announced immediately,

which can be quite useful. Yeah, you can think about using aria-describedby to the error

message. You want to mark the erroneous field in some way. There's also inline feedback, you know,

after submit, like here, imagine we have submitted this, just this is like, okay, username, check,

and error expiry date used to format mm y y y y. And we did, you know, we did have a dot here,

so we can't actually submit this. Does this reload? Probably.

So, so yeah, just, you know, having a tick, having some indicator that yeah, this is correct.

And then having like an error here. That's good, a good way to do it.

And of course, I mean, this goes without saying, you should not only distinguish stuff using colors.

So here, if you have, if you leave out okay and error here, then someone with color blindness

might see this as the same color and we can actually take a look here and say

here this is Deuteranomaly. Deuteranomaly that's what I wanted to say.

I'm really terrible pronouncing these and you can see that it is like harder to see.

And then, you know, if you look at, what is that, deuteranopia, it's even impossible to distinguish between those two colors.

So you always want to have the word in there.

Protonomaly, that works pretty well with this color combination, but is problematic with others.

And protonopia, also hard to see what the difference is.

So, yeah, using colors alone, never a good idea.

Oh, I want to switch that off. And if I just scrolled up and said like, oh, don't use colors

to distinguish that, and you go like, they do have different colors. Yes, they do. This is like

green, and this is red, and you might want to get checked for color vision deficiencies and see

if there's something you can do in your settings to make this easier to see because there are

like color boosters or color shifters that you can use. But yeah, that's,

always remember to put text on those things.

Sometimes you want to give feedback while typing. I'm not a big fan of this, to be honest,

Um, because it's like, it's like it's immediate feedback and it can be a little bit, bit rough.

So if I put a username in here, like YA, that is okay.

That is, and then I go TIL and this username is taken.

So I get this, sorry, this username is taken message.

Uh, and because we have the ARIA live polite, as I said, we talk about ARIA next week.

Uh, this would be announced as soon as you stop typing.

That's why it's polite.

This is the example of the JavaScript that doesn't matter for us at all. Then you can have scale feedback, like in this case, it's a password testing field and you want to give feedback. And here we also do like the same thing. So if I go and my password is, yeah, two, three. Great.

at 123. So this is now my password. It says it's a strong password. I don't think that this is a

particularly strong password. It's also not my password. It's nowhere my password. I promise

it's not my password. But you see that it has these like different layers of information. So if I

go into like the middle where it's yellow, this pale yellow is too, too yellow, too bright.

It doesn't have enough contrast to the gray background.

So this should be a different color, but you know, it is what it is.

But it has the track, it has the... actually I think we should go in here.

This is better, a little bit more contrast.

So it has the track, it shows nicely where you are on the scale, and then it also has

weak password, cracked in six days. I shouldn't use this password anymore. I do not. And here's

cracked in centuries. I don't think that JavaScript code is very reliable on that,

But you know, this is like basically the example you get like an update while you're typing.

And for that, things like the aria-live approach makes a lot of sense because you basically want to

the user to stay in this field until they are sure that they have chosen a password that is secure

enough. Then you can have on focus change. So if I'm focused in here and I change to the next one,

Now, in this case, this is the next field. It updates this example and says like expiry date, use the format mm yy yy yy.

Now, if you jump away from the field, that means you probably don't go back. So it doesn't matter a lot.

I think if you're doing this, then you need to put in aria-live. And because this happens after it jumped out, it would use aria-live assertive,

which basically announces it immediately.

So you jump to the next thing and it immediately announces what's happening.

But we will talk about ARIA next week.

This is a big tease, really.

Sometimes your forms are on multiple pages.

Like this is not like mind blowing stuff.

It happens all the time, especially with complex forms.

And you want to inform the user pretty directly.

Now, this is like minor stuff, but in the aggregate, I think it's pretty useful.

So there are a couple of ways to do that.

The easiest one, again, just putting it into the page title, say step two or four shipping address.

And then you can just add your shipping address.

And then you know that there are two steps ahead of you and, you know, one step behind you.

Perfect.

But there are, and you can also add it into the heading.

Also great.

You can use a progress element in HTML, which can be useful.

And sometimes, now, because this is a graphical element, you have to have an alternative text to write.

And you can do that with, like, step one of circa seven in this case.

and put that into the progress element.

And that is then announced as the label for this element.

And why is circa 7 in here?

Now, you would use progress if you don't know the steps.

You know, there might be a selection at some point where you jump over a step,

where you're not sure, you know, oh, this whole page is not applicable to you,

so we will just not show it to you.

And for a visual user, these, what do we call them, like progress elements, like these progress meters, they are a little bit fuzzy.

you know if you're here or here you don't say like oh i probably have another like five steps

to the end you don't you don't say that you say like oh yeah i'm you know i'm not halfway and

then you're at some point you're halfway through and then you're like three quarters through and

if if one of this is skipped it's not like oh i'm now completely i don't know what's going on

it's just like oh this progress was quicker um and if you want to have alternative text for that

you basically want to put the circa in here and maybe even add like, oh, we skipped one step or

something like that. But you don't have to do that. But yeah, and then you have like the finished

progress with value seven of the max, which is seven.

You can style them and then you can have these step-by-step indicators which are broken in

this version of the page, which is interesting.

So in this case, we have the billing address here.

We are currently at the shipping address.

Then we review the order, the payment and finish the purchase.

So five steps here.

And basically what that does is that you have this link at the bottom and then you have

the triangles and you see where you are on the progress.

And I think this is a very nice thing to do, especially because you can, because this is

a link, you can get back to where you've been.

So it's basically just links and it says here completed.

So you have that information as well or current in here.

Now I quickly want to talk about custom controls.

So you will see that quite often on websites and usually they are implemented in a quite cumbersome way.

But they don't need to.

So sometimes there's a lot behind those custom controls and sometimes there's not.

And these are like a couple of simple ways.

So here we have a share button.

So this would be like your Facebook share button.

I don't even know if they're doing this anymore.

I've not been on Facebook for many, many years.

But basically, this could be just a button that you submit.

know, JavaScript can get into the middle and do the submission through JavaScript. But it can be

just that easy. And then you click it and you get like shared and the checkpoint. And that would be

a nice way to have a button like this. In this case, we cross them through because it's now a

disabled button so you can't unshare this. And then the second example is a star rating.

And here we have an X, which is basically zero stars, or I won't rate it. Then you have one star,

two star, three stars, four stars, five stars, and you can say three stars and boom, you have

selected three stars. And here again, for color vision reasons, there is an underline under the X.

And then also once you selected a star, there's also an underline underneath there. If it's

focused, you see that it's with like dotted lines and if it's going to the submission field,

submission button, it basically gets solid underline. And the reason for that is,

why do we have a submit rating button there at all? It's because when you're using the keyboard,

You can't select, in this case, a radio button and submit it at the same time.

If I click here, this would be directly submitted.

You can program that in JavaScript and that's totally fine.

But if I'm using the keyboard, I don't want to submit, like if I'm at the start, I don't want to submit one star and then submit two stars and then submit three stars and then submit four stars and then submit five stars.

So you need another button and you can make that as a hidden button that you then activate when you tap to it.

Yeah, and I think that's it.

I mean, there are a lot of code examples in those things, so you can knock yourself out.

And for this, I think, you know, that might be an interesting case study.

Basically, the stars and also the X, they are these SVGs.

And they get like the label, in this case, zero stars.

And the SVGs are inside of the label.

And then when the input becomes checked, it will then basically use styling to change the SVG inside of the label.

It's very clever.

And I don't say that because I did this, but because it's a really nice technique that, you know, makes sure that you don't have like a lot of different things going on.

And the same goes here when I select like two stars, then basically it formats everything

up to the two and including the two stars SVG.

Yeah, that's all you need to know about custom controls.

There's a lot of flexibility in here that we can't get into and which I don't think

is like useful in this like format.

If you have anything that you want to show, feel free to bring that to the tutoring sessions and we can talk about it.

All right, let's go to our most favorite thing, which is WCAG stuff.

So these are the WCAG success criteria.

The first one is that relies to the form fields is info and relationships.

So information structure and relationships conveyed through presentation can be programmatically determined or available in text.

And that basically means that when you see a form field, you need to know how to fill it out.

Like if it's all visible, what you need to do, you have to be able to fill it out and it needs to be programmatically in the code.

So this is for if you have a form field and then you have a button up and a button down.

Next to it, visually, you might infer this is the amount of things in this that you want to add to your card, for example.

But you have to put that programmatically inside of the code.

And that's where you need the label, this where you need the technically the ARIA label, stuff like that.

This is where this comes from.

So that's super important to make sure that, yeah, if it's clear visually, it also needs to be super clear in the code.

Then we have headings and labels.

And this is about the label that you see and make sure that there is a label that describes the topic or the purpose of the user interface element.

Now, this is not about connecting the label in the HTML to the input field.

This is more like something on the page needs to be labeling this.

That can be a heading, that can be different things.

It can be the search button that we talked about next to the form field.

That would be a label, but there needs to be something that is there to describe the topic or purpose of that input field.

And if it's not, then that falls all under the headings and labels option.

You often see, for example, select boxes to sort things.

And it just has like by date and you go like what by date, you know.

And so in this case, it's a good candidate for headings and labels as something that you would fail it on.

Yeah, and you can fail this even if there is a hidden label, for example, or something like that.

This is when there is no label, then that is visible and for everyone, then this can be a failure.

Labels or instructions are basically a similar thing to the headers and labels before, but this also covers instructions.

So this is specifically when you are asking for input, then you need to instruct the user on how to do that.

And this is like a base level success criteria in level A.

So this means that if you have a specific format, if you mark up your required field with an asterisk, you need to describe that.

You need to put in those instructions.

And that's, you know, that's important.

And then we have name role value, which is basically like the catch all for like elements need to be properly used.

So we have seen the input fields with the label and descriptions, for example.

And I always said like, oh, it would be announced as label and then text input and then the description for that.

And this is exactly what name role value looks at.

So we're looking at the input field.

It has a label. That label is then the accessible name.

So that's the name part of this success criterion.

uh if you have used proper html like an input field with the um uh the type text then it will

say oh yeah sure this is a text input field so uh the role is text input and the value is whatever

is inside of the field but it's also things like required it's also things like uh the length that

that is required. So all these properties and states need to be also conveyed in a programmatic

way. That's basically what this is asking for. So this is asking for the correct HTML,

making sure that everything is clued together properly.