Processing Forms
Form processing can be generally categorized into three areas: e-mail forms,
client-side forms, and server-side forms.
E-mail Forms.
Actually, there are two types of e-mail forms: forms where the data is reformatted
into an e-mail message and sent via server-side scripting and forms where users
must have an e-mail program installed and setup to send via their own e-mail
server. The first type of e-mail form is both highly accessible and more secure.
The second type puts a lot of the requirements on the user. When users click "send
e-mail," the form may automatically open the user's default e-mail program
(which may or may not be the one the user typically uses) and all e-mail settings
must be configured by the user to successfully send the document. If the user
does not have an e-mail account, the form may be completely useless.
If the only setup that your server supports is to have users manually e-mail
their forms to you, ask users to download/save the form and fill it out offline.
Additionally, make it clear at the beginning of the form that users need an
active e-mail account to submit the form online. And, expect that some users
will send you the information directly without using the form to format their
responses.
Client-Side Forms (JavaScript).
Generally speaking, client-side scripting means that some relatively simple
code, which is embedded into an HTML document or referred to in it, is executed
by the user's browser (e.g., IE, Netscape, Opera, or Firefox). Currently the
most popular client-side scripting language is JavaScript. JavaScript can be
used to populate the form's entries (such as a list or menu), verify the user's
input, and submit or redisplay the information in the desired format.
As with the external e-mail client described above, requiring users to have
a certain configuration (i.e. a JavaScript enabled browser) presents several
barriers to accessibility:
-
Some assistive technology disables JavaScript automatically when browsing
the web.
-
Many users disable JavaScript to avoid ads, pop-up windows, and nefarious
programs. In particular, certain IT networks disable scripting to prevent
hacker attacks and other security issues.
-
It may be difficult, even for experienced browsers, to turn JavaScript
support back on if it has been disabled. This is especially true for IE
users.
-
JavaScript processing can cause lengthy delays or even crash the user's
system, depending on how much memory and processor work is required.
Scripting and the OSU Standards.
Because it is not fully supported by assistive technology, the OSU Standards
(MWAS#12) actually prohibits users from relying on client-side scripting to
display content or process information. You may use scripting to enhance the
page add decorative elements, layout content, or add additional navigation
features but you may not use it as a primary or required element on your pages.
Thus, OSU designers should use an alternate method of form validation and processing.
Workarounds for Scripting.
If you must use client-side scripting:
-
Inform users, in plain, non-script dependent text, that the form requires
a script-enabled browser. If possible, use a detection method to automatically
detect if scripting is turned on and direct the user accordingly.
-
Provide detailed and explicit instructions for turning on scripting in
various browsers, especially IE. Link to these instructions from your form
page.
-
Offer a method to request a non-script-dependent version of the form.
Be sure users can easily request the form in alternate format and that
they are not prevented from receiving the benefits of the form if it is
submitted via an alternate route. For instance, if a user requests an alternate
version of a grant application and the application is due the same day,
the user must have reasonable time to complete and submit the alternate
version and equal consideration as those who were able to use the online
form.
Server-Side Forms (JAVA, ColdFusion, PHP, etc.).
As a general rule of thumb, forms processed and submitted via server-side
processing (for example, using ColdFusion or PHP scripting) are the most accessible
type of forms. This is because, in most cases, users are not required to have
any special software other than a browser capable of displaying the form. Since
all processing happens on the server-side, the user's operating system, browser
version, or firewall connection has minimal effect on the functionality of
the form.
Error Messages and Notations.
When a users presses the "Submit" button, typical a form is passed-through
a validation process, either using client- or server-side validation techniques.
If the user incorrectly enters information, leaves required fields blank, or
otherwise tries to submit invalid data, the validation process can return the
user to the input screen and flag problem fields.
Tips for identifying invalid input:
-
If the validation process reloads the current page or returns the user
to the same input page as was displayed before submit, put a "errors found" message
at the top of the page, so screen reader users know that a problem occurred
and don't have to read through the whole page again to find out what happened
and why their Submit didn't work.
-
Use more than color to indicate which fields require corrections. Turning
a field or input red doesn't help those who can't see the screen or have
colors turned off.
-
Put error messages to the right or above form fields. This insures that
screen readers will read the error before the form field and the error
is associated with the appropriate field.
-
If users are required to enter a lot of data using a particular set of
formatting (e.g. "All lower case only and no numbers or spaces." or "Use
dashes to separate entries"), consider creating an instruction page and
linking from the form page. Thus, users can read all the instructions first,
then go to the form or can refer back to the instructions, when needed,
without interrupting "Forms Mode" entry.
|
1760
Neil Ave 
