Illinois Web Accessibility Standards
Proposed Modifications

Version 1.6; July 20, 2004

The following changes, primarily to the Forms and Tables sections, are intended to provide more guidance for the development of web "applications" (typically with heavy use of forms and data tables) and to reflect advancement in screen reader technologies.

Insertions are marked with <ins>
Deletions are marked with <del>

Implementation Guidelines:

1. Coding

1.4 - Provide meaningful page titles.

What:
Page titles appear in the title bar of the web browser window, as the default text of bookmarks or favorites, and in search results listings. Meaningful titles allow users to quickly and clearly identify what a page is about.
Why:
Screen readers users read page titles to confirm their location and to re-orient themselves when reading a page. Page titles are also read when switching between open windows.
How:
Each page must have a <title> element in its <head> section. The title should contain a brief indication of the site and the specific topic of the page. The most meaningful words should be placed near the beginning of the title. If possible, titles should be 60 or fewer characters in length.
Ref:
WCAG 13.2

10. Forms

10.1 - Associate labels with all form fields.

What:
HTML forms include "fields" such as buttons (<input type="button">), text boxes (<input type="text">), list boxes (<select>), and more. Each field is typically identified by a text label.
Why:
Screen readers cannot always determine which label belongs to which field based on positioning alone. The <label> element makes this association clear.
How:
Use the <label for=""> tag to label every form field whenever possible to identify each form field's label. The value of the label's for attribute must match the corresponding field's id (not its name).
Note: The value of a label's for attribute is the corresponding field's id, not its name A single <label> can be associated with only one form field, and a single form field can have only one <label>.
Ref:
WCAG 12.4; 508 n

10.2 - Position labels as close as possible to form fields.

What:
Using certain layout techniques, form labels are not always positioned immediately next to their fields.
Why:
When screen magnification software enlarges a web page it also reduces the field of view. If form field label is positioned far away from its field, it may be impossible for a screen magnifier-user to view both the field and the label at the same time.
How:
Position labels immediately adjacent to fields, preferably in standard locations, such as on to the left of or above text boxes and list boxes and on to the right of checkboxes and radio buttons.
Ref:
WCAG 10.2; 508 n

10.3 - Include any special instructions within field labels.

What:
Frequently, special instructions are listed after the field to which they apply. In some cases, instructions are even presented in "pop up" text or in the browser's status bar.
Why:
When filling out a form, screen readers typically read only the field's label. Screen magnifiers will focus on the field and its label, and instructions may be out of the field of view.
How:
Special instructions should be given before the form field and within the field label if possible. If instructions are too long to appropriately fit within the label, they should be given in an instructions section in advance of the form.
Ref:
508 n

10.4 - When you can't use label, use the title attribute.

What:
In some complex forms, it may not be possible to associate one and only one <label> to every form field; in these cases a title attribute can be used instead.
Why:
No matter what the circumstance, a screen reader user needs to be able to identify the purpose of every field. If a <label> is not associated, most newer screen readers will read a field's title attribute instead.
How:
Add a title attribute to any form field that cannot be associated with a single label. The value of the title should be the full text of the field's label (including any special instructions).
Note: Many screen readers will not read title if a <label> is already associated, so using both on the same field is not recommended.
Ref:
508 n

10.5 - For groups of fields, use fieldsets, titles, or selects.

What:
In some cases, several form fields need to be grouped together. For example, a set of check boxes may provide different "answers" to a single "question".
Why:
Screen readers may need to be able to read the group name or "question" in addition to the field's individual label for the individual fields to make sense; however, HTML does not allow more than one label to be associated with a single field.
How:
Several alternative methods are possible:
  1. The <fieldset> element is designed specifically to group related fields, and modern screen readers will read the fieldset's <legend> in addition to each field's label. However, fieldset is not well supported by older browsers or screen readers, and it is difficult to control the graphical appearance of the fieldset even in modern browsers.
  2. In place of using labels, title attributes can be applied to individual fields, incorporating both the group label and individual label for each field. However, many screen readers will not read title if a <label> is already associated, so it is not practical to use both on the same field, and the other benefits of using <label> are lost.
  3. Groups of radio buttons, and, in some cases, checkboxes, can often be replaced by a single <select> (listbox) control. (Individual radio button/checkbox labels become the <option>'s in the select, and the group label becomes the <label> for the select.) When possible, this is usually the most effective solution.
Ref:
WCAG 12.3; 508 n

10.46 - Make sure that form fields are in a logical tab order.

What:
Screen reader and keyboard users move between form fields (and links) using the Tab key. The order in which form fields receive focus is called the tab order. By default, the tab order follows the order in which elements appear in a page's HTML code.
Why:
Depending on the design and layout of a page, the tab order may not match the visual (or logical) order of fields on a form. Reading fields out of their intended order can be disorienting for a screen reader or keyboard user.
How:
Make sure that fields appear in the HTML code in the logical order and/or use tabindex to set the appropriate order.
Note: Tabindex is only supported by Internet Explorer 4 and newer.
Ref:
WCAG 9.4; 508 n

10.7 - Avoid using disabled fields.

What:
Form fields may be "disabled" using the disabled attribute. Disabled fields are shown, but cannot be selected, edited, or changed.
Why:
Many screen readers skip disabled fields altogether. If a disabled field contains important information, a screen reader user is likely to miss it.
How:
For text fields and text areas, use readonly instead of disabled. For checkboxes and radio buttons, use onclick="return false;". Display list boxes (<select>'s) as readonly text fields.
Ref:
508 n

10.8 - Set font size to 100% for form fields.

What:
Internet Explorer for Windows, the most common web browser, does not automatically enlarge the text in form fields, even when its "Largest" text size is selected.
Why:
Users with limited vision often rely on the ability to enlarge text (see Guideline 2.2).
How:
Add the following style rule to make sure text in form fields can be easily resized:
input, textarea, button, select { font-size: 100%; }
Ref:
n/a

11. Data Tables

11.1 - For simple data tables, explicitly identify headings for all columns and rows.

What:
"Data tables" are simply HTML tables used to display data. (On the other hand, "layout tables" are used to lay out columns and sections on a web page. Both data and layout tables use the <table> element, but their functions, and accessibility issues, are very different.) "Headers" identify the content of each row and/or column.
Why:
A screen reader can use table headers to provide row and column information while a user explores the data cells within a table.
How:
Use <th> (table header) or <td> (table data) elements with scope="col" (for column headers) or scope="row" (for row headers) to identify cells that contain row and/or column headings.
Ref:
WCAG 5.1; 508 g

11.2 - Avoid using complex data tables.

What:
Table with multiple layers of headers and "spanned" columns or rows can become very complex.
Why:
Complex data tables can be difficult to navigate and understand using a screen reader. Only the most advanced screen readers can use advanced table markup to provide orientation information. Older screen readers may not be able to to make sense of complex tables at all.
How:
Whenever possible, simplify complex tables by re-arranging or dividing them into separate tables. When a complex table cannot be simplified, use advanced table markup, such as headers, axis, scope, <col>, and <colgroup>, to fully indicate the relationships between data cells and headers.
Note: See W3C's "Tables in HTML Documents" (http://www.w3.org/TR/html401/struct/tables.html) for complete details on how to markup complex tables.
Ref:
n/a

11.3 - Mark-up complex tables using id and headers attributes.

What:
It is possible to use advanced table markup to make complex tables readable for modern screen readers. The id and headers attributes can be used to associate multiple row and column headers with any individual data cell.
Why:
In cases where complex tables cannot be simplified, and users are expected to have relatively modern screen readers, advanced table markup may be the only way to make a complex table accessible.
How:
Use a unique id on each header cell in a complex table, for example: <th id="header1">. Use headers attributes on each data cell to indicate which headers it relates to, for example: <td headers="header1 header2 header3">.
Note: See W3C's "Tables in HTML Documents" (http://www.w3.org/TR/html401/struct/tables.html) for complete details on how to mark up complex tables.
Ref:
WCAG 5.2; 508 h

11.4 - Include summary attributes for data tables.

What:
The summary attribute provides a basic description of a table's content and structure. This information is not displayed on the screen but is read by modern screen readers.
Why:
By reading a table's summary, a screen reader-user can quickly decide whether to take the time to read a table in detail; it also helps to let the screen reader-user know what to expect regarding the table's arrangement.
How:
A summary attribute should be added to the <table> tag describing the data that the table contains and the arrangement of the rows and columns. (For layout tables, no summary or summary="" should be used.)
Ref:
WCAG 5.5