Required reading: Your reading for this week includes:
Chapter 16 of the WebAIM Guide
to Web Accessibility: Forms (all sections)
Chapter 18 of the WebAIM Guide to Web Accessibility: JavaScript (part or all, see note below) Note: If you know JavaScript or plan on using it on your web site, you should definitely read the entire chapter. If you don't know JavaScript or don't plan on using it, you should at least read the "Overview of Creating Accessible JavaScript."
Interactivity
Most web sites are not very interactive. They have links, but not much more than that. Links are interactive (because users click on them in order to access other content), but they're easy to make accessible, so they're not really a big problem most of the time. When I use the term "interactive," I'm referring to items that require scripting (programming) of some sort. This week's lesson focuses on HTML forms and JavaScript. In a future lesson we'll also look at multimedia and Flash, though we won't go into great detail with these other technologies. You could easily spend a whole course—or several courses—learning any of them.
Interactivity on web sites can make them more engaging, more useful and more fun in a lot of ways. Unfortunately, some types of interactivity are not so good for accessibility.
When using a screen reader, one of the problems with interactivity is that users don't know when something has changed on a web page. They can't see the change, and there is no built-in way in HTML to notify users of changes to the interface or to the document. Even if the changes are "accessible," it does little good if users are unaware that the changes even occurred.
For example, a web site might have a link that users can click on (or hover over with their mouse) to make a sub-menu appear. Sighted users can see the sub-menu appear, but blind users cannot. Even if the menu itself is accessible to a screen reader, nothing happens to alert the user that the sub-menu has appeared. As far as the user knows, nothing happened after clicking on the link. This can be frustrating.
Keyboard accessibility is also an issue. If a web site uses "drag and drop" functionality that requires a users to move objects with the mouse, people who use the keyboard will not be able to use this feature.
This does not mean that sub-menus and "drag and drop" functionality are completely "against the rules." You can use them, but you have to ensure that users are made aware of changes in the interface, and make sure that there is more than one way to access the information (e.g. with both the keyboard and the mouse).
HTML Forms
HTML forms are used to get information from the user. Users either type in the information or they select from a list of pre-set options. Here is a simple example (Note: This form is non-functional. You can type in it, but you can't submit it anywhere):
Here is the code for this particular form:
<form id="sample_form" method="post" action="">
<p>
<label for="who">Who are you?</label>
<input type="text" name="who" id="who" />
</p>
<p>
<label for="where">Where are you from?</label>
<input type="text" name="where" id="where" />
</p>
<fieldset>
<legend>Do you prefer green or yellow?</legend>
<p>
<input name="color" type="radio" value="green" id="green" />
<label for="green">green</label>
</p>
<p>
<input name="color" type="radio" value="yellow" id="yellow" />
<label for="yellow">yellow</label>
</p>
</fieldset>
<p>
<label for="textarea">Why is the sky blue?</label><br />
<textarea name="textarea" cols="30" rows="5" id="textarea"></textarea>
</p>
</form>
I'm not going to go into great details here about the accessibility features of forms, because the reading materials do a pretty good job of that. You should refer to them for more information.
One thing not covered in a lot of detail, though, is the basic information on how forms work, so let me talk about that for just a second.
How Does a Form Work?
Setting up a form is relatively easy, especially if you use a program like Dreamweaver. But how do you make a form work? How do you get a form to do something?
The answer to these questiones depends on what you want a form to do. Forms are most commonly used to do the following two types of actions:
save information to a database
send an email to someone
There are other things that you could do with forms, but there are by far the most common. Unfortunately, to do either of those things, somebody has to write a script to perform these functions, and it would go way beyond the scope of this class to teach you how to do that. Scripts can be written in such languages as PHP, JSP, Perl, Python, ASP, Cold Fusion, or others. The script tells the server what to do with the information once it is submitted. Should the information be sent in an email? If so, to whom? Should the information be sent to a database? If so, to which database? How should the data be handled? What happens if someone submits a bad email address? Should the user see an error message? What about when users forget to fill in important elements of a form? These are usually not small issues. It takes time to set this up and to do it right.
The illustration below shows how most forms are set up to work:
The user fills out the information in the form. This information is sent to a script. The script determines whether or not there are errors. If there are no errors, the script processes the data by either sending an email to someone or by inserting it in a database somewhere. Then the script presents the user with a confirmation message. If there are errors, the script presents an error message, and usually sends the user back to the form to try again.
Using Someone else's Form-Processing Script
Take another look at the flow chart diagram above. Notice that you need both a form and a script in order to make forms work. You can create a form on any site, but only sites that have scripting capabilities can run scripts.
Luckily, there are sites on the web that let you use their scripts. Some of them allow this for free, such as the "Allforms" tool at http://allforms.mailjol.net/. These scripts receive data from your form, process that data, and send you an email with that data.
Note: These free scripts won't insert the information into a database. To do that you would need to set up the database on your own site and write custom scripts that can handle the data. All of these things go beyond the scope of this class.
How to Use "Allforms"
Step 1: Create a Form on your own web site
Create a form, complete with labels, a submit button, and the accessibility features mentioned in the readings
Once you log in, you will be given the choice of "basic" or "advanced."
Choose "advanced."
Click on "create new."
Answer the questions they ask you. Their instructions are pretty good, so hopefully most of it will be self-explanatory. The truth is that you can ignore some of these and still have the form work, but feel free to experiment with the many options they provide to you. The most important one is to select the email address to which you would like the form data sent.
One option worth experimenting with is the confirmation page option (the instructions say "Enter a complete destination URL where the visitor will be taken to after successfully submitting the form. If you want to display the default success message, you can leave this blank."). Ideally, this confirmation page will be on your own web site, rather on theirs, because their confirmation page is not very attractive. The confirmation page is just a web page, perhaps created using your template, which says something like "Thank you. The form has been submitted" or "Thank you, your email has been sent" or something along those lines. Note: If we had access to the script itself, we could create custom confirmation messages using the actual data sent by the users. For example, we could say, "Thank you, Paul (or Jane, or Johnny, etc.), for submitting the form." But, alas, we don't have access to the script to do that, so we have to be content to create a generic confirmation page.
You can choose to have an email sent not only to you but to the person who submitted the form. Allforms calls this an "auto-responder." There are various options that you can set for the auto-responder.
Note: Any time Allforms asks you for the "name" of a form element, it is referring to the name attribute in the code. For example, if you have <input name="email" type="text" id="email" />
then the name in this case is "email." Remember that you have control over the name element. You can name things anything you like... well, sort of. Don't use spaces or punctuation. Use only text and/or numerals.
One option you should definitely NOT choose is "enable security code protection," even though they list it as "highly recommended." This security code protection enables what is known as a "Captcha," which shows users a list of letters and/or numerals written in wavy fonts. Captchas are completely inaccessible to people who are blind. Don't use them. See the article at http://www.w3.org/WAI/intro/captcha.php for more information.
Click on "Create new form script."
Copy the web address they give you:
Follow their instructions and insert this web address into the action attribute of your form (the form that you already created in Dreamweaver).
Upload your form to the web.
Go to your form on the web and test it. Type into your form and submit it.
If you receive an email with the form data, then you've succeeded. If you didn't, then something went wrong.
Here is the confirmation page for that form: http://mason.gmu.edu/~pbohman/form_confirmation.html. View the source code for this file. Notice that there is nothing special at all about this page. It is just a plain web page. There is no scripting at all. The truth of the matter is that users don't really have to submit the form to see this page. You could just type in the web address (or click on the link above) to go there. Of course, the page doesn't mean much unless you submit the form, and users won't see it unless the submit the page, so it's not a big concern.
Note: In more sophisticated site designs, you would probably want the confirmation to be available only when the user submits the form, but that would get a little complicated for our purposes here.
In fact, all three of these pages (the form, the confirmation page, and the error page) are plain old HTML, but none of them would work properly without the script at Allforms. The script is what makes them work properly.
Here is a copy of the table that I created in the Allforms interface. This will help you see how to set up the options.
Note: This is just a copy of the table; even though this is a form, it is not functional.
blah@blah-blah-blah.com logged in. Log Out
Here is a copy of the email I received when I submitted the form (Note: this is with the HTML formatting option NOT selected):
*******************************************************
Results of form submission.
*******************************************************
The submitted value of field named "name" is:
-------------------------------------------------------
Paul
-------------------------------------------------------
The submitted value of field named "email" is:
-------------------------------------------------------
blah@blah-blah-blah.com
-------------------------------------------------------
The submitted value of field named "subject" is:
-------------------------------------------------------
I love sending emails
-------------------------------------------------------
The submitted value of field named "message" is:
-------------------------------------------------------
I think you will really like this email from me. This
is the main message. I'm just going to keep typing
until I get tired of typing. Ok. I'm tired of typing.
-------------------------------------------------------
The submitted value of field named "Submit" is:
-------------------------------------------------------
Submit