Live Session Forms (2024)

All right. All right. Let's start with the forms part of this. Any questions from the videos first?

Like was there anything that was hard to understand? Anything I should repeat? Anything that, you know,

didn't make sense to you in terms of like forms. I know it's a pretty complicated topic. And so,

you know, just trying to give you some space to ask questions.

I had a question. You didn't go through it, but for multi-page forms, you went through.

I was wondering if you have a multi-page form that is grouped between pages, so you have a new page for each of these forms' steps,

would the form submit button then be a link because you're navigated to a new page, or would it be a button?

I think for forms, you always want to have a submit button.

You know, there is often like that, like, yeah, you, you know, you're going between pages, but you're sending data.

So, you know, a button is what is expected.

And so, yeah, you want to have a next button and that will submit it because when you have a submit button, this is the fun of like the web working like it does.

It will automatically take the data and put it, like send it to the server as well.

So if you are thinking about, oh, I want to save it in between, it's much easier with a button.

And it always went like that.

And it's totally fine to use a button in that case.

Misael?

Yeah, I had a bunch of questions, actually.

I don't know if I picked them at once.

Start with the first one.

- Yeah, no, there was also, if you have this kind of wizard,

stuff that you have a form with multiple steps.

And as I understood it,

you should wrap everything in a form component,

but should it be like one for each step then?

Or how is it actually announced?

- Okay, that's good question.

So if you go to three.org/way,

I'm bad at typing today. I'm sorry. So if you go to the tutorial, so you generally every form, like if you have a form that has like that you intend to send to the server, like a normal, like, let's say, contact form, stuff like that, you know, even if it's multiple pages, like, oh, you have an exam and you have to like fill it out.

like survey, then yes, you generally want to have it in a form element. And that's mostly for, or

partly for like, you know, sending it to the server, like the form element has the data where to send

the data, has the information where to send the data. And it also like, gives a little bit more

structure. It doesn't, it is not 100% necessary. Like if you do everything through JavaScript,

you don't need it. And if the form doesn't have a label, it will usually not be announced, especially

as a form. It depends a little bit on the screen reader. But so it's not like you have to have forms

around it. But the standard thing to do is to have just one form element on every page and then submit

and then go through the steps.

- Okay, so if you don't have a title for it,

it doesn't really matter if you add it or not.

- Yeah, I mean, the title comes from the HTML.

That's like not the, you know, the form doesn't change that.

It just does-- - Sorry, if you don't have a form label.

Yeah, so you need to form label on every form field. So you have the, for multiple steps, you have the page where the form is in.

Then you have the form inside of that, and then you have the individual fields, and they all need to be labeled.

But you meant that the form was not going to be announced?

No, the whole, the form as a, oh, that, yeah, good, good point.

So I didn't explain that clearly.

So when you get into a search form, for example, you can use the search element and then we'll say this is a search container, basically.

And that's for the form element.

You can do the same thing if you give it an ARIA label.

So, and then it would say something like contact form or something like that.

By default, it doesn't have any labels and that's okay. And so it doesn't specifically announce that this is now form. The user usually knows because it's a heading or because the page title has a SES contact form or something like that.

And the next one was, you talked about like patterns and stuff like that. What about like, automatically formatting text? Is that a good thing or bad thing? I was thinking like, sometimes people add separators between the numbers or some lines, personal numbers.

Yeah, I'm not a big fan because it can interfere, especially with some kinds of assistive technologies.

If you have a screen reader, it's usually okay.

But if you have voice input, it can put dashes in between things.

So in general, I would suggest not manipulating the input field while typing in it.

You can format it when the user leaves the field.

So if there's a blur, you could go and format it.

I don't think it is the biggest advantage to have it.

Similar to how we have the checkmark here.

And we show that when you tap away from it,

You could technically say you do the formatting when you leave it.

I would do that really only for things that are very, very common, like dates, maybe something like a credit card number.

But that's maybe it.

I don't want to manipulate too much.

Because also, like, you know, one of the principles, and I don't think the tutorial does, like, good job at, like, showing that.

But, like, one of the basic principles is, like, you should basically try to take in all data that comes and do the best with it.

So, you know, and we see that often with phone numbers, for example, where a certain format is, like, required.

Like, you don't need to do that.

Just let people type their phone number, like, they want it.

And then on the server, you can throw out all the dashes or slashes or whatever people use, you know, and make a number out of it and format it like you want.

It's much easier than giving that to the user.

So you can do it, but I would only use it very limited because otherwise it can be quite hard to use for some people.

Maybe I know the answer about this is about the same thing but like you add a number input and you can't really type any letters by guess then maybe a screen reader will tell you it's expected numbers but should you not do that in other inputs either like should you always let everyone input whatever they want?

For example, if you have an amount that is the max amount, should you cut it off when they go above that amount?

Yeah, I mean, there are several things that you can do.

So, for example, you can set an ARIA invalid to the field once it reaches a certain amount.

You can use a live region.

We will talk about that in a couple of weeks as well.

that just announces like, oh, this is the maximum number of things, you know, select less.

It's always tough, like even using the number input is not super accessible for people because,

you know, there are also like non-numbers numbers that a number input takes, like an E or a pi,

you know, which is like not a traditional number. So if you rely on the number input,

you know someone might uh order like pi number of things which is like not not super good um so so

you need to do the back end verification anyway um and so i i would be very open uh there is the

input mode attribute where you can force a number keyboard on mobile mainly um but what i what we

found out just last week or like not found out but like we were aware of like that the input type

number now doesn't show dashes or points on iOS so you can't actually use that for like dates or

or stuff like that so it's like yeah in general I think my recommendation these days

is to just leave users alone and trust that they,

if it's a small amount, that they know what they're doing.

So maybe using text inputs is better

and just always have good messages.

Yeah.

I think I would use text inputs.

And then what you can do is you can use the pattern

here at the bottom.

I haven't looked at these for so long. There's a number plate example. That's a great example.

Oh, it's under validating. Of course. So what you can do is basically you can say,

oh I only allow numbers here like here I have 0 to 9 and 1 comma 4 which basically means you can get up to 4 numbers at the end.

It's like this is German license plates so you know you can have your xx and then 1 2 3 4 and that would be a valid license plate.

because of just how it's formatted.

Now, if I put in, I can do four here,

but if I do five, then it should complain,

which it doesn't do for some reason.

Great.

But technically, like this, this would not be submitted.

If there was a submit button here,

it would complain about it, I think.

And that's a way to do it.

So you could go and say,

I only allow numbers from 0 to 9.

And I require like one number or like five numbers or whatever.

And that way you would get like the built-in validation without forcing users to use like a certain keyboard or, you know, do other weird stuff.

Okay.

And the last one.

Errors in common.

When should they be announced?

Is it when you're leaving the field?

You said that like announcing while you're typing is not good.

Or is it when you're actually submitting?

Yeah, there are multiple ways to do that.

And like all have their advantages and disadvantages.

I think so because you have to do server-side validation anyway,

you need to have a good strategy for showing those errors.

And I personally like those most because I can just fill out the form and I don't get distracted and have to go back.

If you have errors that show immediately, you probably want to do the on-focus change one where you move away and then it shows an error.

And then does that actually work?

they break it yeah there we go um you know you show the error and you can use an aria live here to

basically announce that to the screen reader user um all are good all are good uh approaches uh

you know it's just like it really depends on the form a little bit too like if you have a short form

this focus change like when you leave the field um it's much easier to to find and edit and

fix then like if you have a really long form you know you might want to say like oh i filled this

out and you probably want to split it up into steps but then you get like an error message for

each step and just says like oh here's the forward wrong or you know do you mean like this street or

something like that and that can be like easier than like having it like pop up all the time so

Yeah, that's more usability.

What I asked is more that I've always heard,

like for people that see that you should always try to present it as soon as possible

so they can fix it as soon as possible.

But is that the same for screen reader users?

Yeah, I mean, it's hard.

I don't think we have hard evidence that that's true.

I think people just could do it, and so they started doing it.

So I don't know.

I don't know if that's fully true.

Like, if, you know, I mean, if you have, like, I don't know.

What's a good example?

Like, you have validation for a date, and it needs to be in the future.

I think then it makes sense to, like, immediately present it.

If you have to do like, if it's more complicated, I think it's basically on the same level either way.

I don't think there's a big difference between people who can see the form or use a screen reader to operate it.

I think both are equally affected by it.

I mean, it's one thing that we don't do a lot in accessibility is talk about people with cognitive disabilities.

and I know that they sometimes struggle when they get error messages during filling out the form.

So, you know, but like there's no one way to do it.

I wish browsers would do more about that.

And so users could like just check a checkbox and say like, hey, this is what the behavior that I want, you know, but that we don't have that yet.

Yeah, I think that was all.

Thank you. We have another hand. I just have a question about floating inputs, you know, where you have the... I don't recall you mentioning them in the video.

Yeah, I don't like them.

Yeah, they have their own unique problems.

I mean, they're better than just having text,

faceholder text.

And I know that Google did a big thing about them a couple of years ago,

and then they got into material design, and then they were everywhere.

and then Google did actually test with people with disabilities and others and they found out that like

yeah maybe that wasn't a good idea so so um yeah so I don't like them you can use them

in short forms where um where people know what's going on like let's say you have the um let's say

It's a contact form and it has like name, email address and message.

You know, I would not blink too much about it.

But if it's like a long form with like complicated stuff and explainer text and stuff like that, I think it's more distraction.

Like it looks nice, but it's like it's weird.

And also like the text, often people go like from like relatively big text inside.

Very small like flags on the top.

And I'm like, that's not too useful.

Don't do it.

Yeah.

Awesome. Any other questions?

Those have been good. I like them.

Ah, yes.

Hugo says the license plate input

validates on

on submit basically. So, just go here. Where did I click? I'm better clicking to today. That's like, not good. So, yes. So, if you press return.

that apparently this is valid because it's not required

very smart so if you do

WA1 that would not work

yes and it says match the requested format which is like

so if we didn't put the format inside of the label we wouldn't know

what the requested format is so that's one of the downsides

of like this type of pattern stuff I think it's good that we have it

I have to say for accessibility, everything that is in HTML5, including lots of the inputs here, are really lackluster in terms of accessibility.

And when we wrote that, we thought, yeah, this will fix itself. This was 2016, something like that.

And we were like, yeah, in a year or two, then people will use this, and it will be super accessible.

And none of these are super accessible.

I mean, the email website number is okay, range is okay.

But then date and time, depending on your browser, not very accessible, unfortunately.

So, yeah, that's the sad reality.

And these validation messages, this will be announced in screen reader.

But like for a lot of people, it's just not super clear what they are.

The good thing is they are always in your system language.

So if I had my computer set to German or you had it set to Swedish, for example,

it would say match the requested format in German or Swedish,

which can help, which at first you would say that's weird,

But it helps, you know, if you're filling something out where you don't understand the language, it can help to like get a better error message than what's in there.

Theoretically, I guess.

Yeah.

Okay.

If there are no other questions, I would just really quickly go through a couple of pages and tell you how I.

look at forms and also like how I test them I think that's that's important it's also good for

the examination like getting like a little bit of fee for it and I also have like some

good like best practices for forms like articles here and I want to mention them I don't think I

want to go too deep into it. Yeah, I mean, speaking of forms and submission of forms, like, this whole

left side of the quick reference, this is also a form, like, it doesn't look like a traditional,

like, contact form or something like that, but there is a select box, there are buttons all over,

like these are like you know buttons with like checked and unchecked state and we have here

check boxes that we set and they have like results on the right.

And so you know if a form doesn't always look like a form it can also have like different views and

And usually when form stuff comes into play, it often has to do with user input and feedback to that.

So I want to highlight that.

And also highlight that you can select different tags here in the quick reference.

So for example, if you select forms, it may be buttons and maybe arrows. It will give you all the success criteria that have to do with forms, buttons and arrows. And you can look through it and say like, oh yeah, contrast. I should look at that. Or keyboard accessibility or that you don't have a trap. Super useful.

And yeah, and it's just like buttons here too.

Just a button with ARIA press true, because this is pressed up.

So that's how you get these toggle buttons.

And yeah, that's how that goes.

Then, I don't know why I have this.

Oh, this is for identity input purpose.

I think I want to talk about that a little bit.

I also have this survey in the before and after demo, which is good to train with for the exam.

So for example, here we have the city park and we have these radio buttons here and they

are not connected to the label.

So you can't click actually the label.

have to click the round like small round radio button here this is also not labeled so so you

know might not be immediately clear what you're actually selecting like if you use a screen reader

go from here to here it will not announce which city do you find is the greenest because it will

only announce the label or I have to say the accessible name of the select element and that is

the first selected item here. So it would just say select a city which is like okay but why I'm

selecting this. And if you had a label it would announce both it would say which city do you find

is the greenest and then would also say select a city because that's the currently selected thing.

And then we have the newsletter here. I pressed escape. I don't want to press tab. So name, Mr. and Mrs. As you can see, it's like not really in a good order. So you could go from name to email address to the name field here at the top again.

and then to retype email and if you submitted the error message is also just in a different color

which is like that's that's not good um that's not what we want um and of course these are not

not required so you don't get an error message um so on the accessible page and this this was

something that really like when we read this I really enjoyed this because now if you go into

this favorite park thing it will announce immediately like favorite park and then you select none you

know and because it's radio buttons you use the arrow keys to navigate through them central park

grand park jurassic park south park other and you can you know you can just navigate through it

Also made it very clear with the background color that this is the currently selected one.

You know, you can do that with CSS really easily.

Same goes, or that it's the focused one.

And if you select it, you know, the active one, I think, also gets the background color, which is a little bit weird, I have to admit.

But that's what we did.

And then you go into select a city from this list and it would also because now it's inside this field set. It would say green city group select a city from this list. And you know like immediately okay what am I doing here. So that's good. And then also what we did in here like you can actually group these items.

This is great for visual users.

It will not be announced in any screen reader.

So if you do screen reader testing and you see like this, don't worry about it.

Because if you're a screen reader user or actually keyboard user of any kind,

you just type where you are.

Like when I do forms, I would just do BR.

And I know that I'm in Berlin, you know, which is like,

It's just how most people should be using select boxes instead of like picking and choosing and using the mouse to find stuff.

But yeah, that's not how it works.

Then we have Mr. and Mrs. as the two selections.

Unfortunately, this was probably done in 2005, and we weren't aware that we should have other options.

So I take that personally on my point.

This should be updated with just a better example.

Then we have name.

And in this case, you know, we use this like dark maroonish red background color to highlight the current focus.

And I hate this.

Like, it's so ugly.

But that's what we did.

At least it's very clear where the focus is, you know.

That has an advantage.

But I think it looks like there is an error.

And that's not usually what you want.

And then you can submit it.

And then it will say, thank you for submitting your vote.

I think you can do something to make it error out.

I think if you do this, maybe.

Oh, yeah, you have not provided a valid email address.

And this is the approach that I like a lot.

So I think, oh, we didn't do it in the title.

But you get the error here, the submission failed due to the following two problems.

I would work that a little bit more nicely.

And then basically says like what you did.

And because those are linked, you can basically jump directly to the input field where you are and go and type those.

And that's useful.

But yeah, you know, error messages, you can do it in so many different ways. But they're useful. So that's what we're looking for. Being able to click the label, that's always important. And then, you know, go into things easily with the keyboard.

So, there are a couple of other things that I really want to only high level talk about. Disabled button suck. Especially if you have them in the form that you want people to submit.

Like if you have a contact form and you only enable the button, the submit button, once people have filled out all the required fields, that might make it harder for people to find the required fields if they're not aware of that.

Because they will arrive at the bottom of the form and will not be announced to people.

It will be like, you know, they can't tap to it.

And it's just like harder to know, oh, there's something missing.

If you submit it and you get an error message back, you immediately know.

And yeah, I mean, if you have them usually in very bad contrast, which is not useful.

And then if you...

Yeah, I mean, the contrast is terrible.

examples here from hampers. But even then if you have them here and you tap through, you might not be able to see them. Like if you have a zoomed interface, it can be really hard to see why something is disabled or how it works. So I would always use buttons that just can submit and take care of the validation afterwards. Because it's

It's so much better.

And I think there have been, like, many studies now since Hempos published this in 2017 that have, like, you know, validated this.

Like, don't just have, like, disabled buttons everywhere.

A question there.

You want to still have inline validation, right, as you go, so that you don't, like, discover everything at the end, I guess.

Yes, you can still have inline validation if you want.

But you don't have to have it.

It really depends on the form.

For long forms, I would say yes, have inline validation.

For short forms, it's like sometimes you don't want to bother with it.

But it really depends.

We have done some studies, and I would say mostly people were ambivalent.

They were like, oh yeah, just give it to me at the end.

And some people were like, I want to have it immediately.

I personally like to have it at the end.

I submit it and then I get a list of things that I need to fix.

But everyone is different.

So I don't think it makes sense to have hard rules about that kind of stuff.

Because every site, every user, every requirement is different.

Yeah, but you can have inline validation.

You just don't want to also disable the submit button because submit buttons, if they are

disabled, always a pain.

Okay.

I have this Nielsen Norman Group article and they have published some things about accessibility

that I would not trust relatively recently.

So don't take this as gospel,

but I think it's always good to see how usability recommendations

and accessibility recommendations go hand in hand.

And this is from 2016, so this is a long time ago.

But it's basically the same things on best practices,

like only ask for the data that you need,

group stuff visually and, you know, for us using our field sets, present fields in a single column layout. You don't want to have multiple columns. I generally agree with logical sequencing, which is like, yeah, make things logical. No placeholder text.

This is one that I find super interesting, like match fields to the type and size of input.

So if you ask for like a year, don't have a super long input field.

Because it's like, and we've seen that too in our testing with people with disabilities and without.

like if people see a short field and it says year next to it it's just less cognitive load

than if you have like you know a super long field and it says year next to it it's just like oh i

know i know a short field that looks like four numbers uh roughly is uh is there for to put a

year number in and that can also help with like you know subtly forcing like specific formatting

because if it's like as wide as four numbers, people will put in four numbers instead of only two or like, you know, putting in like a whole date, for example.

So yeah, so I think that makes a lot of sense.

Distinguish optional and required fields.

I talked about that in the videos and that's very important for accessibility.

The trend goes to only have the required fields even there.

Don't put optional things in.

I know that's not always possible, but if you have them, make sure that it's clear.

Sometimes that might even be having a button that says show the optional stuff,

and then you see the optional fields in there.

explain any input or formatting requirements that's a basic thing um avoid reset and clear

buttons yeah i'm really really a big fan of that uh recommendation because like

uh they immediately clear the form like often you don't even get like confirmation step

I think most browsers now have that, but if you have a cancel button or a clear button or something like that, it just destroys the input that the user has already done.

And the user can always just navigate away or reload to clear the form, so you don't have to have a button for that.

And then 10th is highly visible and specific error messages and they have really good error message advice here on this page, which has been relatively recently updated in 2023. So I don't know how good this still is, but back in the day it was pretty good.

So yeah, they have, you know, things like prematurely displaying error.

So when you have to add your email address and you start with like writing your first two letters of the email address and it goes like, this is not the right email address.

You have to have an ad in your email address.

You go like, yeah, but I have like three letters before my ad in my email address.

You know, it's like, don't do that.

I think you want to be like, you know, just use common sense.

Like this is all, like none of the things that are in there, like it's like rocket science.

I think it's all common sense that we have to put it together and then you will have a good time.

And then I would also recommend to read, and I have all the links in the infrastructure as well,

to read the placeholders in form fields are harmful article,

because there will be the time when you become a boy and you grow into a man.

When you talk to a client or a boss or whatever, and they say,

oh let's just put placeholders in it and not have labels on it and then you know these are the

arguments you want to pull out and say like hey um this is don't let's not do it like even and they

even argue you shouldn't have placeholders in addition to labels uh which i personally agree

but uh it's not an absolute requirement um so yeah uh don't don't use placeholders they're

really good arguments in this. And then, you know, just to show you a little bit of the, like,

variation of form field issues. Like, if you want to dive into that, I found this page, like, I want

to say two years ago in this course, I was like, oh, I should like, find nicely designed forms,

and show what's wrong with them for accessibility. And this is like, this has a lot of contact forms, and they're all for, like, I think, WordPress or something like that.

And it's pretty neat because they all do the same things wrong.

But it's good to know.

And so you can just click on them and see what's going on.

Like here we have this dining thing and you click on demo and then you have the form here and then you can tap through it.

Like here we have your name and we have the nice like smaller thing that people love so much. And now I press tab and I don't know where I am. Because that's how these types of forms often work. So I want to here and to force focus.

orange like outline around the the tab so you know where you are and so we see we're here we're here

and now we should be on time somewhere but we we can't see it so i don't i don't know we'll try to

press the down arrow no oh we're down at select your dining space so the time and food uh

selectors are not even like accessible but funny enough like the select your dining space stuff

It seems to work pretty nicely. I guess they are radio buttons for change. And here these are custom drop downs. And if you look at the inspect element really quick, we see that.

It's just a list item for some reason and another list.

And of course the LI element, you know, or the UL, that's not a focusable element using the keyboard.

I wrote an article about focus just on the weekend.

So I'm going to put that into the list of articles as well.

But like this is not in the sequentially focusable items.

and it only has a click event I guess yes so even if this was like you could put on tab index zero

this is very hacky like you should not do that but tab index zero now makes this time field that I can

select it but the problem is if I press return nothing happens I press space nothing happens

And the reason is that this is not translated into a click event handler.

I do a key down, key up event handler with a keyboard.

And if you have a button, you specify only the click event handler, but the browser will translate your key up event handler into a click event handler.

It's just a thing that buttons and links and stuff like that do to make it easier to program for them.

So if you use a button or link, you will have a much easier time specifying click event handler only.

In this case, you would also need to override it and say, oh, yeah.

And by the way, on key up, we also want to click.

But only if it's return or space and stuff like that.

So it gets complicated really quickly.

people use buttons if you can. Don't do it like that. And then yeah for the dining space here at the bottom, we do have radio buttons I think. Yes. And those work pretty nicely. I assume that the people is added using the after but on the bed.

So this will not be read as two people, it will just be read as two, which I think is okay in this case, because dining space, I think it's pretty clear what it means.

But if I had programmed this, I would have put, well, I would have put probably the two person, two person, okay, into the label and just hide it visually.

or I would put the after pseudo content inside of the label and then it's also read by screenreaders.

You can do it both ways.

But yeah, these are just radio buttons and they even have like, you know, properly connected labels,

which not all of these examples have.

For example, if I have this one, I mean, they might have fixed that since last time.

But these, again, gender markers, male, female, they have not been like focusable at all because they hit the actual radio button using display none, I think.

See, is that correct?

Oh, visibility hidden, which is the same thing, does the same thing.

If you select visibility hidden, it will just be taken completely out of the DOM.

So if you go here and you uncheck visibility hidden, you have the radio button behind this graphical radio button now.

But you can tap there and you can just change it using the arrow key.

So you don't want to use visibility hidden, display none, stuff like that in those cases.

And to be honest, for these, we used to do a lot of shenanigans with these types of pseudo-radio buttons and stuff.

I don't know where they have put it.

Did they do it here? I look where they got the little like graphic from. Yeah, so we did. Oh, yeah, it's the span check. So if I delete that, let's delete it also from the second option.

And nowadays we don't need to even do that because you can use, what is it called? Something with an accent color. Orange. Orange. And boom. And now we have nice orange radio buttons.

those don't meet the contrast ratio by the way but like you know you could easily do that without like

relying on like any tricks and stuff like that and i think honestly for like most websites

using accent colors is so much better than like creating like stuff from scratch

uh yeah it's really easy to do

Anything else I want to show? No, I think the rest is pretty good. Just, you know, UK design systems also uses error summaries. I think I just had that as an example from last time. But yeah, I think that's in general, that's it. Any questions?

Doesn't look like it. Yeah. If you have any questions, put it into Slack, you know, and also don't forget, we still have a couple of weeks for like the one on one tutoring times. Take advantage of them, especially with the examination coming up.

If you, we see how many people are taking them, if we think we should have more slots or if you like to have more slots, we can maybe organize that in, you know, in the first week of January, maybe or something like that.

I don't know how that will like shake out, but in general, like, you know, we want that everyone has the opportunity to do those as well.

All right. Thank you very much. And have a good rest of your week. Take care and see you around. Bye. Bye. Bye. Bye. Bye. Bye.