“Accessibility” is a catch-all phrase for the concept of making web content as usable as possible for people of differing abilities. It is the equivalent of putting a wheelchair access ramp on the front of a building and braille on elevator buttons. While it is not yet legally required in Canada (as of this writing) the principles of accessibility are strongly advised as “best practices”, and make your site easier to use as a whole for everyone.

The fact that we have been using clear, semantic HTML fulfills a big part of the guidelines of accessibility. In the context of forms, there are two other attributes we should add to our <label> tag:

The first is the for attribute. Used correctly, for “links” the label it is used inside of to the appropriate input, meaning that a user can click on the label to make the input active, rather than having to guide the mouse cursor inside the input box (useful for site users with diminished hand-eye co-ordination, for example). for takes the value of whatever id is set to in the appropriate form element:

1. <label for=“city”>City</label>
2. <input type=“text” name=“city” id=“city” size=“32” maxlength=“30” />

The second attribute is accesskey. This creates a keyboard shortcut so that users with disabled access can hit a key, rather than using the mouse (for our purposes, the keyboard equivalent is alt-shift-accesskey.) It is usually (but not always) the first letter in the label content, and must be unique to each element in a form:

<label for=“city” accesskey=“c”>City</label><input type=“text” name=“city” id=“city” size=“32” maxlength=“30” />

Typically a form will require details like first and last name, city, address, postal code, etc. Let’s start by asking for the person’s city of residence. Our question to the user - what we want the user to read - goes inside a <label> tag. The part of the form that they will fill out is created, in this case, by an <input /> tag. (Note that <input /> tag is, like the <img /> tag, is closed inside itself, as it creates its own content, and does not surround anything. For most text input we require the type attribute of the <input> tag to be set to "text". (In this case, “text” means alphanumeric characters: a textbox like this can be used to receive numbers and letters equally. This is improved, and made far more explicit and precise, in HTML 5 forms).

1. <label>City</label>
2. <input type=“text” name=“city” id=“city” />

Note that the name attribute is not related to anything in the text box itself: it is simply the name associated with the input, for the purpose of PHP. (id is set to the same value as name. id is referenced by JavaScript, HTML, and CSS). The name must be a unique word, following strict web naming conventions.

The size attribute determines how large the textbox appears on the screen: it literally limits how many characters can appear in its “window”. Set the size to a reasonable amount (approximately 25 for anything other than addresses or specialized entry areas).

The maxlength attribute is the final attribute required for this tag. It should be two less than the size to give space to see all the characters placed into the textbox, otherwise some the first few characters typed in will tend to be cut off as maxlength is approached.

So our line of code now becomes:

1. <label>City</label>
2. <input type=“text” name=“city” id=“city” size=“32” maxlength=“30” />

A functional bicycle, designed by Kevin Cyr.

Unfortunately when the HTML for forms was being designed consistency was not a high priority. You will find that most form-specific tags are <input> tags, but there are several notable exceptions.

The main points to remember about forms are as follows:

• a form starts with a <form> tag and closes with a matching </form> tag. Form elements (text fields, drop-down menus, etc) are only valid between the opening and closing tag in XHTML. In HTML5 you may put a form element, such as an input, anywhere on the page, with or without a surrounding form tag.

• The form tag has two attributes that are typically added: method and action.

• A form’s method is the way the submitted data is passed to whatever will be processing it (a CGI script, a PHP script, etc). Ninety percent of the time this method will be post. Alternatively, the get method appends the data to the URL itself when it is submitted, which is obviously less secure (but helpful, if you are interested in debugging a form or bookmarking a page created through a form decision).

• The action attribute of the form tag tells the form where to submit its data to. If a CGI script written in Perl was processing the data, the action attribute would typically be set to something like cgi-bin/form.pl. If a PHP script, it would be something like formhandler.php.

The first step in creating our form is the opening and closing <form> tags, with the correct attributes:

1. <form method="post" action="formhandler.php">
2. </form>

XHTML requires a fieldset tag immediately inside the form tag. fieldset is a container element inside the form. Think of filling out your tax form at the end of each year: each major section of the form (personal information, employer, income) is divided into a seperate box. fieldset is that box in the context of a form. A form may contain multiple fieldsets.

Immediately inside the fieldset you should enter a <legend> tag, with appropriate content. The <legend> is essentially the label for the entire fieldset, and typically indicates the purpose of that section. (“Personal information”, “Mailing Address”, “Billing Info”, etc).

fieldset is optional in HTML5, but it is a good idea to use it.

The creation of good forms involves far more than simple HTML. There are four primary principles that should be followed when creating a form:

Usability / simplicity

Is the form easy to understand? (Put rather more bluntly: “Users are idiots”.) Making a form that is simple to comprehend and easy to fill out is not always a clear process for the designer.

Security

Does the form provide basic security measures that help protect our site? Placing a form on a website essentially opens a window to the world, allowing users to interact with the underpinnings of our site (often, a database). One of the primary ways control of a website is hijacked from the owner is through the manipulation and insertion of malformed form data. The addition of simple safeguards on form elements is the first and most basic level of protection against this form of abuse.

Privacy

The site should have clear answers to the following questions:

• Why should I give you, the site owner, the information asked for by this form? What do I get in exchange for doing so?

• What do you use the information for?

• Who do you give the information to, if anyone?

• How do I remove information from your site once I have submitted it? (Also known as an “opt-out” process)

Privacy statements are not yet legally required in Canada for non-government, non-banking websites, but they are a Very Good Idea. They are required for doing business in the EU, and for minors in the United States. They do not have to be written in legalese (and it is, in fact, an advantage if they are not: users appreciate clear, straightforward explanations.)

Accessibility

Can the form be easily used by those with different or limited abilities? (For example, by the blind, or those with poor motor-coordination skills).

Forms are ubiquitous on the web. Any time you provide a username and password to log into a site, add a comment to a blog, or order anything online, you are filling out a form.

This section covers the HTML needed to create a form, as well as touching on the principles of good form design. However, there are two important areas that we will need to leave unaddressed at this time:

• We will not have the opportunity to cover the processing of form data, i.e. what happens after the user clicks the “Submit” button. HTML allows for the creation of the form, but allows for limited from validation, and that only in HTML5: that is, HTML creates the textboxes, etc, in our form, but does not check what the user types inside them. Even if you use HTML, you must also use at least one other web development language to double-check the validation, together with all the other tasks: inserting the validated user data into a database with MySQL, or checking it as a username/password combination, or sending the submitted information in an eMail. Typically these languages include JavaScript, PHP, Perl, ASP.Net, or some alternative. Processing of form data is covered in later articles.

• The form we create will work just fine (up until the moment the user presses submit), but will look terrible. We use CSS to control the appearance of forms, which is again covered in a later article.

Those with more confidence and/or knowledge in HTML are usually tempted to add more markup to their forms to make them “look better”. I know it is frustrating to see a form that doesn’t look the way you want it to, but don’t add markup other than what you see here. You’ll only be adding redundant or irrelevant tags that will get in the way when we add CSS to forms.

Also note that as we add markup to our page and test our form (by entering data into textboxes, making selections from drop-down menus, etc) the browser will remember what we have entered into the form, even after refreshing the page. (This is a feature added to prevent those who do accidentally refresh the page from losing their information). In order to see a truly renewed form, you will have to hard refresh the page. The keyboard shortcut to do this will change from one browser to the next. (CMD-SHIFT-R for Firefox on the Mac, as one example).

There are many tweaks that can be made to PhotoShop's preferences, depending on RAM, video card, and number of processors and hard drives. The screenshots that follow are from the Mac version of Adobe PhotoShop CS5.

First: one of the most annoying aspects of the Adobe Suite for OS X is that it alters the established keyboard shortcut for preferences in every program (CMD-,) to its own (CMD-K). Press that combination to start up the Preferences panel for PhotoShop.

In the General tab that appears, change the Image Interpolation setting at the top to Bicubic Sharper: in web development, you are more likely reducing original images to sizes that can best fit on web pages. Also, turn off "Use Shift key for tool switch". This is the second most annoying feature, which you have just nullified: you can now switch tools on the tool bar, such as variations on the marquee tool (the M key), with repeated presses to a single key on the keyboard.

Under Units and Rulers, change the units for both Rulers and Type to pixels.

Optional: if you have a second hard drive with a high-speed interconnect, choose that second drive as the scratch disk under the Performance tab.

To speed up PhotoShop, you may wish to turn Image Previews in the File Handling pane to Never Save.

Finally, we need to recognize that PhotoShop's suggestions for "Web" canvas sizes when creating a new document are incorrect, with the exception of the lowest four, which are standard advertising banner sizes. PhotoShop suggests full screen resolution as the size for web pages, and ignores the fact that the browser window will have a tab bar, scrollbars, and operating system UI components present, reducing the "screen real estate" significantly. The browser window may not even be maximised, especially at higher screen resolutions, reducing the available size even further. In addition, PhotoShop's suggestions imply that you will be creating a fixed width design mockup; generally speaking, you should be creating a fluid design instead.

However, if you are creating a fixed-width design, or wish to use some figures as a rough guide for a mockup, the following are more accurate dimensions to use:

Enter these dimensions as Custom sizes when creating a new PhotoShop document for mocking up a web page. 1024 × 768 is currently the most common resolution for desktop monitors, but you should keep an eye on emerging trends, particularly if you have chosen a fixed-width design.