Forms

Discussion

All standard HTML form elements, except buttons, need to have a text description associated with them using the "label" tag.

The label should be associated with text areas, radio buttons, selects, and checkboxes by giving the form element an “id” attribute and giving its text “label” a “for” attribute that has the same value as the form element's “id.” This makes an unambiguous association between the label and the form element and provides two things. First, all screen readers will hear the label read when they focus the associated field. This is absolutely essential for form accessibility for blind students. Second, in most browsers, when the label is clicked with the mouse, the associated form element will get the focus. So, for example, if you have a checkbox that has the label "Yes, I agree that labels are important," when the student clicks the label text, the checkbox will become selected. For students with motor disabilities who still use the mouse, the label provides a larger target to click—the student does not have to struggle to check the tiny box.

In certain cases, labels can look ungainly. A primary example is a date input that has select fields for day, month, and year. Usually, we just have a “Date” text description off to the left of the fields. It looks more professional to not have obtrusive month, day, and year labels next to each field. In this case, we can still have labels. We just “hide” them from sighted students using CSS (actually we are positioning the labels off the left side of the screen).

The example below demonstrates the correct CSS and HTML to achieve an elegant looking and highly accessible series of form elements.

Example

Screen Shot: Using semantic, hidden labels to keep forms aesthetically pleasing yet fully accessible:

Figure BP-Forms-1. Click image to enlarge.

Code Example: Using semantic, hidden labels in forms:

<label for="day">Date <span class="semantic">day</span></label>
<input type="text" name="day" id="day" size="2" />
<label class="semantic" for="month">date month</label>
<input type="text" name="month" id="month" size="2" />
<label class="semantic" for="year">date year</label>
<input type="text" name="year" id="year" size="4" />

Resources

• Using Label elements — Several examples from ICITA on using Label element.
• Forms in HTML documents — Example from the W3C HTML 4 specification on using form labeling

Discussion

When browsing a web page, a screen reader reads linearly, following the order of elements in the source code from top to bottom. Sometimes you will encounter forms which appear logically arranged to the sighted student but, because the elements of the form read in source order in a screen reader, appear out of order to the blind student. We want to make sure that if a screen reader-reliant student browses from top to bottom in a form that the student can easily distinguish how the form is put together.

When browsing—when just moving through the text in the form and not focusing the form controls individually—the screen reader may not announce the label for a field. Instead the proximity of the label to the field may be the primary indication of the relationship. For example, if there is text that describes a set of form controls or a single form control, it needs to be clear to the screen reader user that that text applies to the associated form element or elements. Thus the best practice is to have your forms “linearize”—that is, make sense when read in source code order, top to bottom.

In a similar vein, when the student is tabbing from form field to form field, it is important that he/she not be jumping around willy-nilly—for example, skipping from one field high on the page to one much lower, leaping over the those in between. Such unpredictable or illogical field jumping creates unnecessary difficulties for students with certain cognitive disabilities, including attention deficits. Also, the shifting visual focus may cause problems for students using screen magnification programs, which are only displaying a small, highly magnified section of the screen at any one time.

Example

Screen Shot: Tables can be used to arrange forms (though CSS is better). Labeling of form elements is crucial:

Figure BP-Forms-2. Click image to enlarge.

Code Example: Form in table with no labeling

<table>
<tr>
  <td>First Name</td>
  <td>Last Name</td>
  <td>Email</td>
</tr>
<tr>
  <td><input type="text" name="first-name" /></td>
  <td><input type="text" name="last-name" /></td>
  <td><input type="text" name="email" /></td>
</tr>
</table>

Code Example: Form in table with proper labeling

<table>
<tr>
  <td><label for="fn">First Name</label></td>
  <td><label for="ln">Last Name</label></td>
  <td><label for="email">Email</label></td>
</tr>
<tr>
  <td><input type="text" id="fn" name="first-name" /></td>
  <td><input type="text" id="ln" name="last-name" /></td>
  <td><input type="text" id="email" name="email" /></td>
</tr>
</table>

Discussion

If your form has more than one logical section—for example a "Personal Information" and a "Test" section—use HTML headings to identify the sections.

Recall that it is common to navigate by headings when using a screen reader. Having long forms broken into smaller logical units introduced by headings provides a welcome convenience to blind students and may improve accuracy in filling forms.

Discussion

The fieldset is an under-employed but potentially helpful form element which can be used to “surround” a grouping of related form elements, most typically a set of radio buttons or check boxes.

The first element in a fieldset is the legend. Visually, it appears at the top of the grouping. Think of the fieldset's legend as a supplemental label for each surrounded field. The checkboxes or radios still need labels, of course. But the fieldset can help provide category or contextual information for each field.

Screen readers will typically read the legend of the surrounding fieldset each time they read the labels for the encompassed fields. The example for this best practics shows checkboxes that are labeled with a color—red, green, blue, pink, yellow. The legend reads “Favorite Colors.” The screen reader will hear something like “favorite color: red,” “favorite color: green,” etc. (See Figure BP-Forms-4.)

Two things to keep in mind. First, make sure to keep the legend short—it may be read for each field and long legend text gets annoying quickly. Second, in many usages, a group of radio buttons might be replaced with the select box, since both element types are used to choose one of a range of options. The labeling of selects is simpler and there is less variability in how screen readers handle labels as opposed to fieldsets with legends.

Example

Screen Shot: Using a fieldset and legend to group related form elements:

Figure BP-Forms-4. Click image to enlarge.

Code Example: Using a fieldset and legend to group related form elements:

<fieldset>

  <legend>Favorite Colors</legend>
  
  <input type="checkbox" value="red" name="favcolor" id="redfav">
  <label for="redfav">Red</label><br />
  <input type="checkbox" value="green" name="favcolor" id="greenfav">
  <label for="greenfav">Green</label><br />
  <input type="checkbox" value="red" name="favcolor" id="bluefav">
  <label for="bluefav">Blue</label><br />
  <input type="checkbox" value="pink" name="favcolor" id="pinkfav">
  <label for="pinkfav">Pink</label><br />
  <input type="checkbox" value="yellow" name="favcolor" id="yellowfav">
  <label for="yellowfav">Yellow</label>
  
</fieldset>

Resources

• Radio Group Form Control Labeling Example: Fieldset/Legend for grouping — An example on Radio grouping example from ICITA
• Creating Accessible Forms - Screen Reader Form Accessibility — An example on accessible form from WebAim.

Discussion

Some forms have certain fields that must be filled before the data submission is acceptable. These "required" fields should be indicated. The usual means for doing this is via a red asterisk. And there is usually an explanation at the top of the form: "Required fields are indicated with *."

Since a screen reader user may be moving through a form solely by tabbing between elements and hearing their labels announced, it is important that the purpose of the "*" be clear, even if the student did not read the explanation of what the "*" represents.

There are a few simple steps to take to ensure screen reader using students understand which fields are required:

1. Make the asterisk an image, rather than just typing the keyboard character into the label.
2. Give the image an “alt” and “title” value of “required field.”
3. Place the “required field” image within the label tag of the required element.

If these steps are followed, a label that appears as “First Name *,” will read as “First Name (image) required field.”

Example

Screen Shot: Using an image to mark required fields in a form:

Figure BP-Forms-5. Click image to enlarge.

Code Example: Using an image to mark required fields in a form:

<p>Fields marked <img src="required.gif" alt="required" title="required" /> are required.</p>
<form>
  <label for="fn">First Name <img src="required.gif" alt="required" title="required" /></label>
  <input type="text" name="first-name" id="fn" />
</form>

Discussion

The input format of certain fields needs to be indicated so that students are not frustrated by filling out a form. Content designers should provide an example of the required format. The only place to do this where you can guarantee a screen reader user will see it in the label text. Label text for a text field for a phone number might be "Phone  ((111) 222-3333)." This clearly indicates that an area code is required.

However, in many cases it is possible simply to silently reformat the input data. For example, a Social Security number is nine digits. It is typically represented with dashes in between groups of numbers, and we may want to store it in that format. But if the student enters just nine digits and no dashes or puts dashes in the wrong place accidentally, there is no need to raise an error. Instead, the best strategy is simply to reformat the data using JavaScript.

You should attempt to be as forgiving as possible to student input. If there is a way to automatically and silently, without throwing an alert, reformat incorrectly formatted data students enter, do it. For example, if you want a date formatted as February 17, 2009 but the student enters 2-17-2009, when the focus leaves the fields, run a JavaScript routine to silently reformat the date to suit your needs. This silent correction is always preferable to an alert. Take advantage of the power of JavaScript to improve access.

Discussion

The most error-proof way of alerting a student that there is an error in a form after he/she submits it is by using a JavaScript "alert" notification. All major browsers support JavaScript alerts, and all assistive technologies notify the user when one appears.

You will undoubtedly note, however, that we just don't see pop-up browser alerts much anymore. There is a strong tendency in form development to create a custom alert area that appears either above or below the form upon submission and lists form errors. In principle, alerting the student to mistakes in the form using a custom dialog or on-page alert can be a good idea, so long as the custom alert area gets the cursor focus and draws the attention of the student.

In practice, this can be a challenge. How do we ensure not only that the sighted user sees the error area but also that the screen reader-reliant student understands that there are errors and can find them easily? We can use JavaScript to direct the cursor focus to the error area and make that area stand out by giving it a red background when the form submits.

Note though that it will require experimentation and testing by the developer to guarantee that the screen reader announces that there are errors when the page refreshes/gains focus.

Ultimately, it is up to the better judgment of the course designer, but we can always be sure that a screen reader will read the simple, standard pop-up alert.

Discussion

To avoid frustrating your students, we recommend creating a "landing page" that confirms for them that the form has been submitted successfully. The page should be as simple as is practical. It should have a single heading that indicates "success" in some fashion, perhaps followed by a simple, one sentence statement reinforcing the point (perhaps adding extra, pertinent information about the course or next assignments, etc.).

Discussion

There are two points to be made here. The first point relates to settings on the server; a server typically has a time after which, if there has been no activity, the current session expires. The student will need to log back in and may have lost work.

Provide a pop-up alert warning of the session time out. A screen reader user will be immediately notified of a pop-up alert, even if he/she is currently using a different application.

The second point relates to timed quizzes and tests. We strongly recommend that online quizzes and tests have no time limits.

As we are all highly aware, the online learning experience is very different from the in-class one. While we might consider quizzes administered in the classroom as tests of both knowledge and speed, students prepare differently for online quizzes. They are on computers. They are sitting in front of a knowledge gathering device. It is highly likely they will be reviewing both printed and online materials as they answer quiz questions. A well-designed quiz will take this eventuality into account and will be composed of questions that require on-the-spot research. Thus, in most circumstances, it does not make sense to use the LMS to limit test-taking time. You want well-thought through and researched answers, not responses hobbled by unreasonable time limits.