[ LiB ] |
Forms aren't glamorous, but there are plenty of ways to make them look and function at their best. Dreamweaver can help you make your forms accessible to all visitors , to look their best, thanks to CSS formatting, and to be more interactive with the addition of Dreamweaver behaviors.
Because the whole purpose of forms is to be accessed and interacted with, form accessibility is a big issue. If a user can't use the mouse, how can he select a form field to type information into? If he can't see your page layout, how can he tell which form field is for the username and which is for the email address? Consequently, various rules, guidelines, and options apply to making acceptably accessible forms.
According to Section 508, §1194.22(n):
When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.
That sounds like a lot! Luckily, browsers and operating systems take care of some of this for you, such as making it easy to activate form fields for the mobility-impaired. And the HTML specifications provide several mechanisms (some more well supported than others) for helping:
Labeling Even a user who can't see your form's layout should be able to tell without a doubt what each text field, check box, or other element is for. To accomplish this, every form element should include a label tag containing a text label that explains what information this element collects (username, password, phone number, favorite color , and so on).
Tab indexing A user who can't use a mouse should be able to use the Tab key to activate all form elements in order. The browser should allow this automatically (at least, on Windows or Mac OS X), but you can help users by adding a tabindex attribute to at least the first form element and optionally to all form elements. tabindex takes a number as its value, indicating the order in which elements can be tabbed through. So, the first element in the form should have a tabindex of 1 , the second element should a tabindex of 2 , and so forth.
Access keys Ideally, a user who can't use a mouse should be able to enter a key command that will activate a particular form field. For instance, type F to activate the First Name field. This bit of accessibility is not well-supported in browsers, however, and can conflict with OS-level shortcut keys, so it is not often used.
Using these guidelines, the basic code for an accessible form might look like this:
<form name="theForm"> <label for="username"> User Name:</label> <input type="text" name="username" id="username" tabindex="1"accesskey="n"> <label for="pword"> Password:</label> <input type="password" name="pword" id="pword" tabindex="2"
accesskey="p" > <input type="submit" name="submit" id="submit" label="Submit"
tabindex="3" > </form>
In this example, each item has a tabindex . Each item except the Submit button has a label and accesskey attribute. (The Submit button needs no accesskey: It is always accessed by pressing Return and needs no text label because it contains its own internal label attribute.) The form would also be acceptably accessible without the accesskey attributes.
Labels can be coded implicitlywrapped around the form element being labeled:
<label>User Name <input type="text" name="username" ... > </label>
Or, they can be coded explicitlyplaced next to the form element:
<label for="username">User Name</label> <input type="text name="username" ... >
According to the U.S. Access Board (www.access-board.gov), explicit labels are more reliable. They also allow for more design freedom.
Before you create your form, make sure you have accessibility options for Forms turned on (Edit > Preferences/Accessibility). When this is enabled, the next time you use the Insert bar or menu to create a form element, you'll be presented with a dialog box letting you assign label , tabindex , and accesskey attributes (see Figure 9.9). Note that the same dialog box appears regardless of whether you're inserting a Submit button, a textarea , or another form element. It's up to you to know, for instance, that a Submit button can do without explicit labeling. The form object itself doesn't call up an accessibility dialog box because no special treatment is necessary for form tags.
The accessibility dialog box gives you choices for how your labels are coded and how they appear. To create explicit labels (coded separately from the form element rather than wrapped around it), choose Attach Label Tag Using for Attribute. To create implicit labels, choose Wrap with Label Tag. Whichever option you choose, use the Position choices to specify where the label should appear in relation to the form element (before or after). As mentioned earlier, explicit labels are more flexible and reliable. Implicit labels are easier to manage, however, because there is no for attribute to keep track of and no chance that the label and its related form element will become separated.
Remember that the text in the label tag will display in the browser window as regular text. So, when laying out your form, don't enter the text separately if you're going to use the accessibility dialog box to generate a label.
To add or edit either the tabindex or accesskey attributes for an already existing form element, use the Edit Tag command (Style Sheet/Accessibility category) or Tag Inspector (see Figure 9.10). Neither of these attributes appears in the Property Inspector, but they are available in the Tag Inspector's CSS/Accessibility category.
The smart money says, don't bother with accesskey unless you have a really good reason to do so. It's not well-supported, and it can actually cause conflicts with the user's operating system.
The tabindex attribute can be applied to other page elements besides form elements (the object and a tags, for instance), to allow users to skip directly to important page content. If the form is an important part of your page, however, you probably want users to be able to tab directly there, so don't clutter the page with other tabindex attributes. Not every form element needs to have a tabindex because after the user has activated the first field, built-in browser/OS tabbing features will take the user to additional fields. However, if you want to control tabbing order ( especially if you want to override browser/OS defaults), you can apply the attribute to all elements.
Note that tabindex values don't have to be consecutive. If your first field has a tabindex of 10 and the second has a tabindex of 300 , the tabbing order will still go from a smaller to a larger number. You can use this to your advantage! If you think there's any chance you might be coming back later to add more form fields to the beginning or middle of your form, don't assign consecutive tabindex values to every field in the form. For instance, what if you have 20 fields and want to add a new field or two between the address ( tabindex=3 ) and phone number ( tabindex=4 )? You'll have to renumber almost every field in the form. Either don't assign tabindex to all form fields, or give the address field a number such as 10 and the phone number a higher number, such as 15 or 20 .
Labels are different from tabindex and accesskey because they're coded as separate tags rather than attributes of the form element tag. They also create visible elements on the page.
If you've created form elements without labels, using regular text to identify them, you can easily convert that text into a label. Just select it and, in the Insert bar (Forms category), choose the Label object (see Figure 9.11). This wraps a label tag around your selected text. Because labels display in Code view, it also activates Code view so you can see the code being added. Note that the tag is entered without a for attribute, so it's not connected with any form field. You'll have to enter the for attribute in Code view or in the Tag Inspector.
Labels display in Design view as regular text, with no visual indicator that they're labels. If the insertion point is inside a label, though, the Tag Selector will display the label tag in its hierarchy. The Property Inspector doesn't recognize labels, so use the Tag Inspector to edit label properties such as the all-important for attribute.
In this exercise, you'll create a form that uses various types of form elements. Figure 9.12 shows the finished page you're aiming for. Before you start, download the chapter_09 folder from the book's website at www.peachpit.com to your hard drive and define a site called Chapter 9, using that as the root folder.
| |
|
|
|
|
When both buttons are inserted, select the left one. You'll see that it's automatically a Submit button, but you can make it a Reset button. Choose Reset from the Action options in the Property Inspector. This automatically changes the button's label as well as its type. Its name becomes submit2. Change it to Reset.
With forms more than any other type of page content, you're at the mercy of the browser for what things will look like. Text fields, drop-down menus , check boxeseach browser and platform determines how these will appear. At the same time, it's crucial that your forms look tidy and inviting so that users will want to fill them out and will find them intuitive. The two main weapons in your form-formatting arsenal are tables and CSS. You also have the choice of substituting images for Submit and Reset buttons.
Tables help keep page elements aligned and organized. Organization is especially important when it comes to forms. Many designers organize forms in tables with one row per line of form elements, and optionally a separate column for labels, as is shown in Figure 9.17. Cell padding (applied via the Property Inspector or specified in a CSS style) or gutter cells can be used to separate the form elements from each other.
![]() | For more on tables and layout, and their related accessibility issues, see the sections "Using Tables for Page Layout" and "Making Your Tables Accessible" in Chapter 8, "Building Tables." |
Remember as you're doing this, however, that the form still needs to linearize well, or it won't be accessible. Screen readers read tables from left to right and top to bottom, so keep labels and form elements next to each other in the same row rather than putting the label on one row and its associated form element on the row below.
If you're using Dreamweaver's accessibility options to create your form labels and you want to put the form in a table in which labels and form elements are spread across different cells (as shown in Figure 9.1), be sure to use the Attach Label Using for Attribute option. This inserts the label and form element as separate tags. Dreamweaver inserts them both into the same table cell, but you can select either and drag it to another cell when it's in place.
One of the frustrating aspects of designing HTML forms has always been how little control you have over their appearance. With CSS, things are looking up. By redefining form and form element tags and applying custom classes, you can add borders and backgrounds, determine sizes, and more. As usual with CSS, results aren't equally well supported across all browsers and for all form elements, so some experimentation and previewing is in order. But you can still do some nice things with your forms' appearance for most visitors (see Figure 9.18).
![]() | With its limited support of CSS, Netscape 4 offers a particular challenge when it comes to form design. Not all styles display properly. But much more important, in some cases text fields can become nonfunctional, no longer accepting input. Obviously, this is unacceptable. A workaround is to create a style sheet that Netscape 4 won't see, using the import directive . See the section "Using Linked and Imported Style Sheets to Create a Netscape 4Friendly Site," in Chapter 11, "Using Cascading Style Sheets," for full details. |
Text boxes Text fields and text areas can benefit from having borders and backgrounds applied, type properties specified for their input, and width controlled (use absolute sizes only).
Buttons You can use borders and backgrounds to control the appearance of buttons such as Submit and Reset. Width and height can also be used to control size (use absolute sizes only), although be careful that text display isn't chopped off.
List/menus Use borders, backgrounds, and type properties to control drop-down menus and lists in forms. You can also assign width (absolute sizes only), but be careful not to truncate text display.
Radio buttons/check boxes Not much can be done with these elements. Backgrounds and borders can be applied, but the effect isn't very nice.
Labels If you're using the label tag for all text labeling of form elements (and you should be, for accessibility!), you can use any CSS formatting that you would apply to any text elements on a page.
When designing style sheets for your form elements, it's better to apply custom classes and contextual selectors than to redefine tags. Different form elements use different tags, so it's easier to apply one class to input , select , and textarea tags than to redefine all three. The input tag, in particular, is used for so many different kinds of form elements (text fields, radio buttons, check boxes, buttons) that redefining this tag to suit each kind of element at once is difficult. Borders and backgrounds, for instance, work on text fields and buttons but don't apply nicely to radio buttons and check boxes.
![]() | Just because it's possible doesn't mean that it's always a good thing to do it. Don't forget that the primary purpose of forms is to be useful and easy to fill out. Colored backgrounds and other odd effects can interfere with that. |
If you don't like the way the browser displays your Submit and Reset buttons, and if CSS doesn't give you enough options, you can always use image buttons instead (see Figure 9.19). To do this in Dreamweaver, use the Image Field object. When you choose this object, Dreamweaver presents you with a standard Select File dialog box to choose a GIF or JPEG image. But the image is inserted into your form as an input tag, with code like this:
<input type="image" name="imageField" border="0" src="myCloseButton.gif">
If you have accessibility options for form elements turned on, the standard Input Accessibility Options dialog box appears. As with regular buttons, you don't have to supply a label because the button will be its own label. But be sure to supply alt text for your image button, as you would with any image. When the image button is selected, the Image Field Property Inspector appears (see Figure 9.20).
In this exercise, you'll format the form created in the previous exercise using CSS styles to control form elements' appearance.
Forms collect information and pass it along for processing. That's the mysterious "back end" of web development that front-end designers usually know nothing about. But it's important, even for front-end folks, to get a sense of how everything fits together and to build better and more efficient forms.
It all starts with that age-old question: What happens to forms when they're submitted? When a user presses the Submit button, the browser looks in the form tag for an action attribute. The action attribute holds the address of a receiving file that can presumably do something to process the form's input, like this:
<form name="theForm" action="http://www.mysite.com/cgi-bin/myscript.cgi" method="GET">
The browser sends that information to that receiving file's address using one of two methods :
With the GET method, the browser adds the information to the end of the receiving file's address as URL parameters, like this:
http://www.mysite.com/cgi-bin/myscript.cgi?fname=Fred&lname=Smith&favcolor=blue
With the POST method, the browser sends the information as a separate packet of information
The POST method is more secure and can transmit larger amounts of data. GET is often used by search engines and for other nonsecure purposes.
Even though the form is usually submitted to a script file, it doesn't have to be. It can be submitted to any file. A form tag like this
<form name="myForm" action="thankyou.html" method="get">
will send the information to a "thank you" page, and because that's a regular HTML page, it will display in the browser window. The "thank you" page might contain JavaScript for processing the information, or it might just ignore the information and display as any normal web page would.
A form tag like this
<form name="myForm" action="mailto:laura@rocketlaura.com">
will send the form's information to an email address, which will cause the user's email program to send the named recipient a message containing all of the form data.
![]() | The mailto solution is very easy to implement but is very limited. If a user is on a machine that doesn't have a default email client installed (at the library or a cybercafe, for instance), the form will not send, but it will also not alert the user that there's a problem. Internet Explorer displays a security warning when the user submits the form, alerting the user that the sub-mission method is open to being read by third parties. This is enough to scare quite a few users into hitting the Cancel button. In other browsers, the email-composition window will open, but nothing will be filled in. |
Forms can also partake of purely client-side scripting (for example, JavaScript carried out by the browser). Interacting with form elementschoosing items from a drop-down menu, selecting a check box, and so oncan trigger JavaScript behaviors. And form elements can be dynamically updated by a JavaScript without having to reload the entire page.
Together, these two facts make it possible to create forms that adapt their information display as the user is interacting with them.
In Dreamweaver, the Set Text of Text Field and Change Property behaviors give you access to some of this client-side processing. Set Text of Text Field lets you dynamically change the text in any of your form's text fields. With Change Property, you not only can change text in a text field or area, but you also can change the selected item in a drop-down menu or change the selected state of radio buttons and check boxes.
To use the Set Text of Text Field behavior, start by creating a form with at least one text field that you want to change. Next, select the page element that you want to trigger the change. This can be another form element, linked text, an image, or any other element that can have behaviors attached to it. From the Behaviors panel Actions list, choose Set Text > Set Text of Text Field. When the dialog box appears (see Figure 9.21), enter any text that you want to appear there.
The text that you enter doesn't have to be plain old text. Any valid JavaScript function call, property, global variable, or other expression can also be embedded in the text. A JavaScript expression must be placed inside braces ({}). So, an expression like this:
The URL for this page is {window.location}
would display text like this:
The URL for this page is http://www.mysite.com/mypage.html
To use the Change Property behavior, Start by creating a form with either a text field, a text area, a list/menu, a radio group, or a check box that you want to dynamically change. Next, select the page element that you want to trigger the change. From the Behaviors panel Actions list, choose Change Property.
When the dialog box appears (see Figure 9.22), it has a variety of options to choose from because this is a generic behavior that can be used on more than just form elements. From the Type of Object menu, choose the type of form element you want to change. From the Named Object list, choose the particular element that you want to change. The Property list then gives you a choice of all changeable properties for this element, as supported by different browsers. Luckily, all but the oldest browsers support changing basic properties of form elements. For different form elements, here are your options:
For check boxes and radio buttons, the checked property determines whether the item is selected. To change this, enter true or false in the Value field at the bottom of the dialog box.
For text fields, password fields, and text areas, the value property determines what text appears. To change this, enter the text that you want to appear in the Value field at the bottom of the dialog box. Unlike the Set Text of Text Field behavior, JavaScript expressions entered in the value field aren't evaluated.
For select elements (for example, list/menus), the selectedIndex property determines which item in the list is selected. It works like this: Each item in the list has its own index number, starting from 0 for the first item. Determine the index number of the item that you want to have selected, and enter it in the Value field at the bottom of the dialog box.
In this quick exercise, you'll get a chance to see some more client-side form processing. You'll also see how form elements can be used to trigger behaviors. If you haven't done so already, download the chapter_9 folder from the book's website to your hard drive and define a site called Chapter 9, using that as the local folder.
{myForm.num1.value + myForm.num2.value}
In this exercise, you'll tweak the Supersite form you built earlier in this chapter. When the user changes one form element, you'll use that to trigger changes in other form elements.
There's no point in submitting a form if vital information is missing or incorrectly entered. In fact, depending on the script that will be processing the form and how much error-checking it has built in, missing information might cause errors on the server. The most efficient course of action is to make sure all required form entries are present and valid before submitting the form. This is generally done using a JavaScript that executes when the user clicks the Submit button. The process is called form validation .
Dreamweaver's Validate Form behavior lets you specify that certain fields must be filled in and/or must include a certain kind of content (such as a number or email address) before the form is considered valid. To use the behavior, do this:
Regardless of where you attached the behavior, it will execute when the Submit button is clicked, before the form is submitted. If there's a problem, it will stop the form from being submitted and display an error message (see Figure 9.27).
![]() | You can test the Validate Form behavior offline by previewing it in the browser because it gets executed by the browser. Only if the form is valid will the browser try to submit it. |
The behavior validates only text fields, not drop-down lists or any other form element.
Unless you're very comfortable with JavaScript, you probably don't want to go messing around with how the Validate Form behavior behaves. But as long as you're a careful typist, you can customize the text of the alert message that appears when a form is invalid. Go to Code view, find the MM_validateForm() function, and within that find the line of code that looks like this:
} if (errors) alert(' The following error(s) occurred:\n'+errors);
You can enter your own brief statement in place of the text marked in bold here. If your message contains any apostrophes or single or double quotes, however, you'll need to escape them by typing a backward slash (\) in front of them:
} if (errors) alert('Your form can\'t be submitted because:\n'+errors);
Your customized message should stay in place even if you edit the behavior.
In this exercise, you attach the Validate Form behavior to the form's Submit button to check the text fields in your form before submitting it to the server. This exercise builds on Exercises 11.1 and 11.2, which should be completed before you proceed with this exercise.
If you haven't done so yet, download the chapter_09 folder from the book's website to your hard drive. Define a site called Chapter 9, with this folder as the local root folder.
[ LiB ] |