Preview
Video Player
00:00
00:00
Delivery Information Screen
12:25If you haven’t already, download the Project Files associated with this video, and open them up in a code editor. As you can see, I’ve provided the basic HTML and CSS already. Everything but the form.
If you haven't already, download the project files associated
0:00
with this video and open them up in a code editor.
0:05
As you can see, I've provided the basic HTML and
0:09
CSS already. Everything but the form.
0:13
There are a few resources attached to the head of our HTML page.
0:19
I've included a Google Font called Nunito, and a CSS reset
0:25
to make my page consistent from browser to browser. You'll also
0:30
see a note that I'm planning to use a resource called Font Awesome.
0:36
Font Awesome describes itself as the web's most popular icon set,
0:41
and is a great resource for vector icons and social logos.
0:47
I'll be using Font Awesome to display an icon called utensil.
0:52
To use Font Awesome, you'll need to sign up for an account.
0:57
Once you've confirmed your email, press the Copy Kit Code
1:01
button that appears in Font Awesome, and paste to the bottom
1:05
of your head. We'll look at the code that implements our utensils
1:09
icon in just a moment. I've also created the header of the
1:16
page, including a logo, a few context clues reminding the
1:22
user they'll have two more steps to complete after this delivery
1:28
information page, and a summary of what's in their cart.
1:32
You might have noticed the two empty a elements in my nav,
1:39
but that's because those links are currently inactive.
1:43
I've included an article from CSS tricks in the Teacher's Notes
1:48
on removing the href from inactive links.
1:52
The code that applies Font Awesome is already in your HTML
1:56
in line 32. I've used three classes here. "fas" means
2:00
Font Awesome Solid. "fa-utensils" provides the utensils icon,
2:06
and "fa-3x" increases the scale of the icon.
2:11
My layout is responsive, which is mostly due to a class
2:17
I'm using called container. Let's get started right where I've
2:22
included a comment that says form goes here.
2:29
I'm not going to make the form do anything when you submit,
2:33
which would require server-side code.
2:37
I'm also not going to write any JavaScript.
2:40
So our form won't really be validated upon submit.
2:43
I've included an MDN article on client side form validation
2:47
in the Teacher's Notes.
2:52
I'm going to include a fieldset element next.
2:54
Fieldsets group related questions, which we
2:58
learned is an important principle of creating usable forms.
3:02
Since I've kept my number of questions per screen as few as
3:06
possible, there will be only one fieldset on this screen.
3:11
The legend element creates a caption for our fieldset.
3:16
I'll call this set of questions Delivery Information.
3:21
I'm creating a paragraph with a class called a hint,
3:28
to provide instructions for this form.
3:32
Including using a star to indicate which fields are required.
3:36
Now to create a few form labels and
3:45
inputs starting with Your Name and Email Address.
3:47
It's critical that the for attribute of your form label
3:55
match the id attribute of the form input.
3:59
Otherwise, screen readers will be unable
4:06
to figure out the association between label and input.
4:09
Another reason it's so important to match the for attribute of
4:14
the form label to the id attribute of the form input,
4:18
is this increases the area that can be interacted with.
4:23
Thinking back to the 44 pixel target size required by the WCAG,
4:28
you might say, hmm. Checkboxes and radio buttons
4:33
aren't usually 44 pixels. And that's true.
4:36
But if the label uses proper markup, the user can tap on either
4:41
the input or the label to change their selection.
4:46
Now, the target size is larger and the form input is more accessible.
4:54
I could use the required attribute here,
5:09
if I wanted some built in HTML5 form validation.
5:12
But as I said, I'm ignoring validation for now.
5:17
I'm choosing my form labels carefully to try to be as
5:22
clear as possible about what information is needed in each blank.
5:26
By choosing Your Name and Email Address, over just Name
5:31
and Email, I'm aiming for clarity, not concision.
5:35
Users with cognitive disabilities might struggle with a shorter label.
5:40
With the email field,
5:47
I've included a note indicating why the email address is required.
5:49
User will receive a receipt at this address.
5:55
Next, I'll create the labels and fields for the user's Street Address.
6:00
The first line of the user's address is required, but the
6:27
apartment or office number will be optional.
6:31
I'm assuming for this exercise that the user lives in the United States.
6:49
One great way you can reduce the number of fields on an address form
7:03
is use JavaScript to look up the city and state from the zip code.
7:08
A service like Google's location API can help with this.
7:25
I've included a link in the Teacher's Notes.
7:30
Of course, it's important to include a note letting users
7:33
know the reason there's no form input for city and state.
7:37
I haven't required the phone number
8:06
for reasons covered in the previous video.
8:09
I've mentioned in the instructions
8:25
that if the user doesn't have or
8:27
can't use a phone, they should
8:29
include an alternate contact in
8:32
the delivery instructions.
8:34
A question you might have here,
9:02
is the fact that I haven't used any placeholder text in my form.
9:05
Even though some sites provide placeholder text
9:09
to indicate how a phone number should be formatted.
9:12
I covered in the last video the fact that using placeholder text
9:16
instead of labels is a bad idea.
9:21
Suggesting the formatting of data using a placeholder isn't quite as bad.
9:24
But placeholder text can create a color contrast issue.
9:30
Too light and low vision users can't read it, too dark and
9:33
the text could get confused with a pre-filled form input.
9:39
Also, will your user remember that formatting once they start typing?
9:43
A better solution is a technique called Input Masks,
9:50
in which JavaScript converts the format of the user's data as they type.
9:54
I've included articles in the Teacher's Notes to learn more, as well as
10:00
a link to a Treehouse JavaScript lesson on reformatting a telephone number.
10:05
Finally, I'll make sure to label my submit button carefully.
10:11
I need to let the user know they're not finished filling out the entire form.
10:23
Billing comes next.
10:28
All right, let's check our page out in a browser.
10:31
The page remains responsive.
10:35
All interface elements are a minimum of 44 pixels across.
10:38
And, if your page is on a web server, you can run Google Lighthouse
10:44
which is built into Chrome, and check your accessibility score.
10:49
For example, I've loaded my completed form hosted on GitHub Pages,
10:55
which is GitHub's static site hosting service.
11:01
I'll right click on my page, and choose Inspect.
11:05
Then choose Lighthouse from the drop down menu.
11:09
Lighthouse will run performance, accessibility,
11:13
and SEO audits for either mobile or desktop view.
11:17
I'll try mobile for now, and hit Generate report.
11:22
And it looks like I have an Accessibility score of 100%.
11:28
I've included resources on GitHub pages in the Teacher's Notes.
11:35
And don't forget to navigate using only a keyboard.
11:40
Can you tab back and forth using Tab
11:44
and Shift+Tab without getting stuck?
11:50
You'll notice as you tab through, that I've made the focus indicator
11:58
more obvious than what's built into the browser by default.
12:03
I've achieved that by adjusting the focus pseudo class selector in my CSS.
12:08
If your page is keyboard navigable, we can move on to our error messaging,
12:16
which we'll examine in our next video.
12:21