Form element labels can be programmatically determined.


Rationale

For people who are blind, Web-based forms can be inaccessible if users cannot identify form elements when attempting to complete the form. The two major accessibility issues associated with completing forms: understanding which text label describes each form field and understanding which fields are required to complete the form. Screen reader users need the ability to tab through a form and understand the purpose of each form element.

The following resources provide additional information on accessible forms:

Required development and unit test techniques


To comply with this checkpoint, you must meet one of the following techniques for every form element. These techniques are defined in WCAG 2.0 Level A Success Criterion 1.3.1 (link resides outside of ibm.com). These techniques are consistent with Section 508 guidelines for accessible forms.

  • Label elements: Use <label> elements to associate text labels with form fields.
  • WAI-ARIA label properties: Use aria-labelledby (preferable) or aria-label properties to associate text labels with form elements.
  • Title attribute: Use the title attribute to identify form controls when the element cannot be used.

Note: The examples presented in the techniques are not exhaustive. They are meant to illustrate the spirit of this checkpoint.

At this time WAI-ARIA examples are only fully supported in Firefox version 3.6 or later and version JAWS 12 or later. If your product needs to be accessible in Internet Explorer and mobile Safari/VoiceOver, one or more of the required HTML/CSS specific techniques must be implemented, as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and Internet Explorer and mobile Safari/VoiceOver fully support it, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint.

Applications that provide WAI-ARIA must add the following statement to the checkpoint comments column of the Web Accessibility Checklist:

Note: This product uses WAI-ARIA to comply with this checkpoint. WAI-ARIA is supported on Windows using Firefox version 3.6 or later and JAWS version 12 or later, and supported on iOS v5.0 and later using Safari and VoiceOver.

HTML examples

  • Label elements: Use <label> elements to associate text labels with form fields.

    To comply with this technique, you must implement all of the following examples.

    Some form field controls, such as Submit buttons, are automatically associated with a label. But text fields, select menus, checkboxes and radio buttons must have an explicit label using the <label> element with the for and id attributes so that assistive technologies can communicate the purpose of the <form> element to the user. If you do not explicitly associate the visual label using the <label> element, a screen reader user may only hear "edit" and not know how to complete the form.

    The value of the for attribute must be the same as the value of the id attribute of the associated control. Do not provide multiple LABELs for one form control. Each <label> element must be associated with only one form control.

    HTML example 1

    Use the <label> element for text fields.

    <form action="mailto:somebody@ibm.com">
    <label for="name1">Name</label>
    <input type="text" name="name" id="name1" size="30" />
    </form>

    HTML example 2

    Label a select menu using the <label> element.

    <form>
    <label for="shiptype">Select your shipping method</label>
    <select id="shiptype" name="ship_method" size="1">
    <option selected value="">Ground – 7 business days</option>
    <option value="air">Air – 3 business days</option>
    <option value="nextday">Next day air – 1 business day</option>
    </select>
    </form>

    HTML example 3

    Do not label input elements that have a type="hidden" attribute. For example, do not provide a label for the following hidden input element:

    <input type="hidden" name="name" id="name1"/>

    HTML example 4

    Label required fields on a form. If using layout tables to align form fields, put the label and the character to indicate a required field in the same table cell. If the asterisk is in one cell and the label is in another cell, assistive technology cannot read the content correctly. This example demonstrates how to indicate a required field so it is accessible.

    An * indicates required fields.

    ...
    <td> <label for="reqfield">* Name:</label></td><br />
    <td><input name="Name" id="reqfield" type="text" /></td><br />
    ...

    Note that the example uses an asterisk in addition to the color red to indicate a required field. In addition, the mechanism for identifying required fields is clearly labeled at the beginning of the form.

    For additional information, refer to the WCAG 2.0 examples of using label elements to associate text labels with form controls (link resides outside of ibm.com).

    HTML example 5

    Ensure that the Label for attribute value is an idref that references a valid id.

    For additional information, refer to the WCAG 2.0 Failure of Success Criterion due to insufficient information in the DOM to determine one-to-one relationships (link resides outside of ibm.com).

    HTML example 6

    Label required fields on a form using the WAI-ARIA aria-required (link resides outside of ibm.com) property.

    Note that WAI-ARIA examples are only supported in Firefox® 3.0 or later at this time. If your product needs to be accessible in both Internet Explorer® and Firefox today, one or more of the required HTML/CSS specific techniques must be implemented, as well as a WAI-ARIA technique. When WAI-ARIA becomes an approved W3C recommendation and Internet Explorer fully supports WAI-ARIA, then WAI-ARIA techniques alone will be sufficient to comply with this checkpoint in both Internet Explorer and Firefox.

    An asterisk and footnote indicates to a sighted user that data is required for a particular form field. However, if the footnote explaining the asterisk is rendered at the bottom of a form or page, a blind user may not realize that the asterisk indicates a required field until she navigates to the bottom of the form or page.

    Adding an aria-required property to the input element below enables a screen reader to provide immediate feedback that a name is required. When aria-required is set to true, a screen reader announces "required" when the name field receives focus.

    <td> <label for="reqfield">* Name:</label></td>
    <td><input name="Name" id="reqfield" type="text" aria-required="true" /></td>

    Required unit tests for HTML development technique 1

    Perform the following unit tests using a Web syntax analysis tool or a screen reader.

  • Title attribute: Using the title attribute to identify form controls when the <label> element cannot be used.

    To comply with this technique, you must implement all of the following examples, except for the WAI-ARIA aria-labelledby example, which may be used when a screen reader does not announce a title attribute.

    If a form field does not have a visible label, a sighted user can understand the purpose of the field by viewing the field in its context. However, the field is not accessible for a screen reader user because they hear "Edit" and no information about how to complete the form. You can use the title attribute to identify form controls that do not have visible labels. A "tool tip" displays when the user places the mouse over the form elements that contain title attributes. Screen readers announce the title attribute.

    HTML example 7

    Use the title attribute for a group of radio buttons.

    This example displays a group of five radio buttons on a survey form with possible choices ranging from "Very Important" to "Not Important". To simplify the visual look of the page, only three of the radio buttons have visible text labels. A sighted user can see the intent of the unlabeled radio buttons, but a blind user hears "radio button not checked", unless the buttons are labeled. Because there are no text labels, the <label> element cannot be used. The title attribute provides information about the radio button to a screen reader user.

    Rating the importance









    A subset of the code is listed below.

    <label for="important">Very Important</label>
    <input type="radio" name="important" value="5.0" id="important" />
    <input type="radio" name="veryImportToImport" value="4.5" title="Very important to important" />

    HTML example 8

    Use the title attribute for input fields.

    In this example, users enter their phone number into three separate fields. The first input field is labeled Phone, so the <label> element identifies the label. The other fields have no visual labels, so the title attribute provides information about the fields. If the <label> element is not provided, the screen reader reads the title attribute.

     -  - 

    <input type="text" name="num2" title="Enter your 3 digit phone exchange" />
    <input type="text" name="num3" title="Enter the last 4 digits of your phone number" />

    HTML example 9

    When an HTML <label> element can not be used and a tooltip is not desired, use the WAI-ARIA aria-labelledby (link resides outside of ibm.com) property to provide a label for an <input> element. The following example demonstrates how to label the input fields from the previous example with an aria-labelledby. Note the value of the aria-labelledby property matches the id of the label's container div.

    <input type="text" name="num2" aria-labelledby="exchange" /> <input type="text" name="num3" aria-labelledby="lastfour" />

    <div id="exchange">Enter your 3 digit phone exchange</div>
    <div id="lastfour">Enter the last 4 digits of your phone number</div>

    HTML example 10

    This example uses the <label> element, title attribute and correct table markup to show how to make forms in tables accessible to screen reader users.

    Placing a form in a table often gives a page a nice "look and feel." This table conforms to Checkpoint 1.3e: Tables so all table headings are spoken. In addition, the example uses the <label> element and title attribute to make the form accessible if table-reading mode is not used.

     

    Apparel

    Size

    Color

    Style

    Shoes

    shoe style
    Shoe Style:


    Shirt

    Shirt Style:


    Pants

    Pants Style:


    <th>Apparel</th>
    <th>Size</th>
    <th>Color</th>
    <th>Style</th>
    ...
    <th>Shoes</th>
    <td>
    <input type="text" name="ShoeSize" title="Shoe Size" /></td>
    ...
    <td>
    <fieldset><legend>Shoe Style:</legend>
    <input type="radio" name="ShoeStyle" id="cshoestyle1" value="Sneaker"/>
    <label for="cshoestyle1">Sneaker</label><br />
    <input type="radio" name="ShoeStyle" id="cshoestyle2" value="Dressy"/>
    <label for="cshoestyle2">Dressy</label><br />
    <input type="radio" name="ShoeStyle" id="cshoestyle3" value="Casual"/>
    <label for="cshoestyle3">Casual</label><br />
    <input type="radio" name="ShoeStyle" id="cshoestyle4" value="Hiking"/>
    <label for="cshoestyle4">Hiking</label>
    </fieldset>
    </td>

    For additional information, refer to the WCAG 2.0 examples for using the title attribute to identify form controls when the label element cannot be used (link resides outside of ibm.com).

    Required unit tests for HTML development technique 2

    Perform the following unit test using a Web syntax analysis tool or a screen reader.

  • ]]>
     

Dojo examples

This section provides specific examples to implement the Web techniques for accessible Dojo labels.

  1. Label elements: Use <label> elements to associate text labels with form fields.

    To comply with this technique, you must implement all of the following examples.

    Dojo example 1

    Dojo input controls must be given explicit labels using the <label> element with the for and id attributes to enable assistive technologies to communicate the purpose of the control. If a label is not explicitly associated with a label, a screen reader user may only hear "edit" and not know how to respond to the control.

    The value of the <label> element's for attribute must match the value of the id attribute of the associated control. In addition, each <label> element can only be associated with exactly one form control. However, a form control can have more than one <label> element associated with it.

    The following example shows how to label a Dojo Textbox widget.

    <label for="name1">Name</label> <input name="name1" id="name1" dojoType="dijit.form.TextBox" /> 

    Dojo example 2

    Currently, screen readers do not read Dojo Slider text labels properly when specified with VerticalRuleLabels and HorizontalRuleLabels. However, numeric labels specified with VerticalRuleLabels and HorizontalRuleLabels are read. As a result, avoid using text labels that are specified with VerticalRuleLabels and HorizontalRuleLabels. Numeric labels specified with VerticalRuleLabels and HorizontalRuleLabels may be used. The following examples demonstrate the correct and incorrect way to specify VerticalRuleLabels and HorizontalRuleLabels for a Dojo Slider.

    Correct way to specify labels (numeric values are used):

    <dojoType="dijit.form.HorizontalSlider">
    ...
    <ol dojoType="dijit.form.HorizontalRuleLabels" container="topDecoration">
    <li>20</li>
    <li>40</li>
    <li>60</li>
    <li>80</li>
    </ol>
    </div>

    Incorrect way to specify labels:

    When using non-numeric text labels, a screen reader incorrectly announces "one, two, three, four" which does not make sense in the context of the following example.

    <dojoType="dijit.form.HorizontalSlider">
    ...
    <ol dojoType="dijit.form.HorizontalRuleLabels" container="topDecoration">
    <li>high school</li>
    <li>associate's degree</li>
    <li>bachelors degree</li>
    <li>advanced degree</li>
    </ol>
    </div>

    Note for iOS platform: For mobile Safari targeted content, do not use a WAI-ARIA widget with role=”slider”. Slider widgets containing role=”slider” are not accessible at this time. Use the HTML5 range input type to enable accessible data input and validation.

    <input type="range" ... />

    Required unit tests for Dojo development technique 1

    Refer to the required unit tests for HTML development technique 1 to validate this technique.

  2. WAI-ARIA label properties: Use aria-labelledby (preferable) or aria-label properties to associate text labels with form elements.

    Dojo example 3

    Use the aria-labelledby property to provide a visible label for a text field.

    <input type="text" data-dojo-type="dijit/form/ComboBox" data-dojo-props='aria-labelledby:"textContainerId"'>

    textContainerId references an element id containing a visible label.

    Note: Label form elements with the HTML <label> element when possible because the label element is universally supported. When it is not possible to use the <label> element, using aria-labelledby is sufficient to meet the requirement.

    Dojo example 4

    Use the aria-label property to provide a hidden label for a text field.

    <input type="text" data-dojo-type="dijit/form/ComboBox" data-dojo-props='aria-label:"my label"'>

    Note: Label form elements with the HTML <label> element when possible because the label element is universally supported. When it is not possible to use the <label> element, aria-label is sufficient to meet the requirement. Note, however, that aria-label provides a hidden label. In most cases, it is preferable to provide a visible label via the HTML <label> or aria-labelledby. When deciding whether to use HTML <label> or aria-labelledby, the <label> element is preferred because it is supported by browsers that do not support WAI-ARIA.

     

    Dojo example 5

    The aria-labelledby property provides the ability to build a composite label from multiple labelling elements. This new capability provided by WAI-ARIA provides a simple approach to satisfying labelling and relationship requirements in some complex but common circumstances.

    This could be useful, for instance, if there were multiple action buttons on a page. Each button is visually labelled "Actions", and it opens a menu of actions that can be performed on an associated object. For example, the object could be a section of page content that could be moved up, moved down, edited, deleted, or otherwise customized.

    A sighted user can easily distinguish among the buttons via visual context. However, to ensure a blind user can comprehend which element the actions are acting upon, an effective label would be "Actions for section-name".

    In the following example, the heading 3 tag contains the name of a section. The link that follows has been re-cast as a button that performs actions on that section. There could be many sections, all with action buttons that have the same visual label. But, the screen reader label would be unique and easily understood for each.

    <h3 id="sectTitle1">Your favorite fruits</h3>
    <a id="button1" role="button" aria-label="Actions for" aria-labelledby="button1 sectTitle1">Actions</a>

    The resulting accessible name for the button is:

    "Actions for Your favorite fruits"

    Notes:

    1. In addition to the requirement to provide a useful label, this technique would also satisfy the requirement of checkpoint 1.3a to programatically specify the semantic relationship between the action button and the section object.
    2. It is important to provide the most critical information first in a label so the screen reader user who has some familiarity with the UI is not forced to listen to the entire label to know the purpose. In this case the fact that it is an action button is what distinguishes the button from the section title so the first word in the label is "Actions". Generally, it is best to put the visual label on the focused element first in a composite label.
    3. The aria-label of "Actions for" takes precedence over the link text of "Actions". The aria-label is specified here so the word "for" can be part of the accessible name. It is not essential but does make the label easier to understand without adding excessive verbage.
    4. The browser automatically concatenates text equivalents of multiple elements specified as the value of the aria-labelledby property. Space characters are automatically inserted as needed between each text equivalent.
    5. aria-labelledby takes precedence over aria-label. However, in this case, the aria-label element is being incorporated into the final label because the aria-labelledby property is self-referencing the element to which it is applied. If the aria-label property was not also specified, then the text equivalent of the anchor tag ("Actions") would have been included in the final label instead of the aria-label of "Actions for".
     

    Required unit tests for Dojo development technique 2

    Refer to the required unit tests for HTML development technique 2 to validate this technique.

  3. Title attribute: Using the title attribute to identify form controls when the <label> element cannot be used.

    To comply with this technique, you must implement all of the following examples.

    Dojo example 6

    Because the Dojo InlineEditBox appears as inline text, it is likely that the widget will appear without a label. If the InlineEditBox is not given a label, a title attribute is required to make the widget accessible. The following InlineEditBox example uses a title to inform a screen reader user that the heading is editable.

    <h3 id="editable" dojoType="dijit.InlineEditBox" title="editable level 3 heading" onChange="myHandler(this.id,arguments[0])">Table of contents </h3>

    Dojo example 7

    Currently, screen readers do not read labels associated that are programmatically associated with a Dojo Slider widget. Therefore, a title attribute is required to enable blind users to identify a Dojo Slider. The following markup renders a Dojo Slider widget with a title to indicate to a screen reader user that a difficulty level should be selected.

    <div id="horizontalSlider" dojoType="dijit.form.HorizontalSlider" title="Select a difficulty level using the slider"> ... </div>

    Required unit tests for Dojo development technique 3

    Refer to the required unit tests for HTML development technique 3 to validate this technique.


 

Adobe® Flash® examples

To comply with this technique, you must implement all of the following examples.

Flash example 1

Use the Adobe® Flash® components (Windows® — Components) that are native to Flash when possible.

Flash components

If you are planning on using one of the component types (form elements) listed below, first you need to enable the accessibility object by using the ActionScript® command enableAccessibility(). This includes the accessibility object with the component as the movie is compiled. By default, the accessibility object is turned off. However, once you enable the accessibility object on the component, any of the following form elements will have access to the Accessibility Panel:

It is best to attach this enableAccessibility() code to the first frame of the movie. After enabling the accessibility object, you can open the Accessibility Panel for all instances of that type of component. For more information on the enableAccessibility() command, refer to Components and Accessibility, on Adobe's Web site.

Flash example 2

Use descriptions in Flash to inform the user about the status / purpose of any controls that are used and make this information available to the screen reader.

Flash example 3

Use auto-labeling in Flash.

Required unit tests for Flash development technique 1

Refer to the required tests for HTML development technique 1 to validate this technique.

  1. Label elements: Use label elements to associate text labels with form fields.
  2. Title attribute: Use the title attribute to identify form controls when the <label> element cannot be used.

To comply with this technique, you must implement all of the following examples.

Flash example 4

Selecting the Flash auto-label checkbox does not always work seamlessly with a screen reader.

Test the forms to ensure that the controls are labeled correctly. If the auto-labeling does not read correctly with a screen reader, un-select the Auto label option for the control and enter the appropriate text in the Name field on the Accessibility panel for the control. In addition, make the control's auto label invisible so that the screen reader does not read two labels for the control. To disable auto labeling for a specific object (yet not the entire movie):

  1. Convert the text to the dynamic text type using the Property inspector.
  2. Select the text and un-select the Make object accessible option in the Accessibility panel.

This is an acceptable work-around for labeling controls if the auto-labeling causes difficulty for a screen reader.

Required unit tests for Flash development technique 3

Refer to the required unit tests for HTML development technique 3 to validate this technique.

Note for iOS platform: Mobile Safari does not support Java applets, Flash or other third party plugins. Therefore, equivalent content must be presented in a manner that is accessible on iOS devices. Apple recommends using the HTML5 audio and video elements for audio and video content. However, these elements use the browsers' native players, and the controls on the players are not keyboard accessible. Therefore, developers must use the HTML5 audio/video API, JavaScript and CSS to implement keyboard focusable controls. An example implementation of an accessible HTML5 video/audio player can be found in Chapter 6 of Pro HTML5 Accessibility: Building an Inclusive Web.

Note: use this link to register for access to the Pro HTML5 document.

IBM® Lotus® Domino® examples

  1. Label elements: Use <label> elements to associate text labels with form fields.

    To comply with this technique, you must implement all of the following examples.

    Domino example 1

    Associate text labels with form fields in Lotus Domino.

    1. Open the form and select the editable field to be labeled.
    2. Press Shift-F10 or right click the field and select Field Properties.
    3. Select the HTML tab and open the HTML Tags - Other field.
    4. Enter the text that matches the visual label that the sighted user sees on the form. For example, if the text label is Date, enter Date in the field.

    Domino example 2

    Do not use HTML title to add the label for radio buttons and checkboxes in Domino. Domino only supports a single title attribute for all radio buttons in the group. As a result, a screen reader reads the same title for each radio button and the field is not accessible.

    At this time, you cannot create radio buttons and checkboxes that are fully compliant in Domino. You can use the following technique to create radio buttons and checkboxes that a screen reader can read correctly, but these will fail automated syntax testing because of the absence of a <label> element and title attribute. Without a title attribute or <label> element, the screen reader reads the value of the radio button and the state of checked or not checked.

    1. Open the form and select the editable field to be labeled.
    2. Press Shift-F10 or right click the field and select Field Properties.
    3. Select the HTML tab and open the HTML Tags - Other field.
    4. Ensure that the Other field contains no text; it must be blank. If Designer has filled in a value, delete the text.

    Domino example 3

    Add the <label> element to associate text fields using pass-thru HTML.

    Do not use this technique with radio button or checkbox fields in Domino.

    Domino example 4

    Pass-thru HTML is used for the SendTo field on the Memo form: To:

    On the HTML tab of the Field Properties box, the ID is set to the value "sendto". The HTML Title is set to the value "To:" for consistency with the visual label on the field.

    Domino example 5

    Use HTML title and correct table markup to make a form in a table accessible.

    Because the form below is in a table, you must implement the requirements outlined in Checkpoint 1.3e: Tables. In addition, the form fields must follow the requirements of this checkpoint for accessible forms. A screen reader user should be able to navigate the table in Table Reading mode or Forms mode to complete the information.

    form contained in a table

    In the example below, the column headers are set for Size, Color and Price in the Table Properties box. Row headers are defined for Shoes, Shirt and Pants.

    table properties dialog

    The HTML title is defined for all fields except the checkboxes. The screen shot below shows the Field properties for the shoe color field. HTML title is set to Shoe Color. When in Forms reading mode, the user hears "Shoe color. Combobox. Black. One of four." In Table reading mode, you hear “Row 2. Column 3. Shoe Color. Black. One of four."

    field properties dialog

    For the checkboxes, the HTML Title field remains blank. As explained previously, you cannot make radio buttons and checkboxes fully compliant in Domino without writing pass-thru HTML. The HTML Title field is blank, so the screen reader announces "Small. Checkbox not checked." Table reading keys can be used to determine whether the cell is for shoes or jackets.

    field properties dialog

    Required unit tests for Domino development technique 1

    Refer to the required unit tests for HTML development technique 1 to validate this technique.

  2. Title attribute: Use the title attribute to identify form controls when the <label> element cannot be used.

    To comply with this technique, you must implement all of the following examples.

    Use the HTML title attribute in the Field Properties box to associate the text label with the form field for editable text, rich text, listbox, combobox, number and date/time fields. This technique is not accessible when used with radio button or checkbox fields.

    Domino example 6

    Provide an HTML title for each editable control in Domino (for example, text fields, listboxes, comboboxes) using the following steps:

    1. Open the form and select the editable field to be labeled.
    2. Open the Field Properties box and select the HTML tab.
    3. Add a title that matches the visual label that the sighted user sees on the form.

    Required unit tests for Domino development technique 2

    Refer to the required unit tests for HTML development technique 2 to validate this technique.

    Recommended techniques for Domino developers

    While the techniques above are required, the recommended Domino technique for page titles is also recommended for forms to enhance accessibility.


Recommended development techniques

Although you do not have to implement the recommended techniques in order to comply with this checkpoint, you should review them because they can improve the accessibility and usability of the application.

The following techniques are recommended to comply with this checkpoint:

  1. Use WAI-ARIA aria-describedby (link resides outside of ibm.com).
  2. Use the optgroup attribute.
  3. Add invisible labels using alt text.

Recommended example 1

Often help text is associated with a form field and rendered by activating an image link beside the field. When help text is initially hidden and then exposed via CSS, a screen reader does not always read the text.

To overcome this problem, associate the form field with the help text via a WAI-ARIA aria-describedby property. The following example exposes help text to sighted users when the help icon is clicked. Blind users hear the same help text when the help icon receives focus. When the aria-describedby property is set to the id attribute value on the help text container div, the field is programmatically associated with its help text.

Help

<img onclick="showHelp();" src="help.gif" alt="help" aria-describedby="nameHelp" tabindex="0"/>
<div id="nameHelp" style="visibility: hidden;">
This is a long description of the name field...
</div>

Recommended example 2

Use the optgroup attribute to group options in a drop-down list under the select <element>. Use optgroup when the user must choose from a long list of options. Groups of related choices are easier to grasp and remember than a single long list of options.

...
<label for="menu">Accessibility Options:</label>
<select name="select" id="menu" >
<optgroup label="Checklists">
<option value="Web">Web</option>
<option value="Software">Software</option>
<option value="Java">Java</option>
<option value="Hardware">Hardware</option>
</optgroup>

Recommended example 3

While using the title attribute is preferred, you can also use alt text to add labels for fields in which the <label> element cannot be used. This technique uses a spacer image with alt text to describe the field label. For example, the following set of radio buttons could be coded using this method rather than using the title attribute.

The following is the code for the radio buttons using a spacer image with appropriate alt text.

Please rate the importance









<label for="veryi">Very Important</label>
<input type="radio" name="1,300" value="5.0" id="veryi" />
...
<label for="vii">
<img src="images/clearpixel.gif" height="1" width="1" border="0"
alt="Very important to important" /></label>
<input type="radio" name="1,300" value="4.5" id="vii" />

Refer to the WCAG 2.0 Additional Techniques (Advisory) for Success Criterion 1.3.1 (link resides outside of ibm.com) for a list of techniques and examples.

 
]]>

©2013 IBM Corporation

Last updated January 1, 2013.

W3C Recommendation 11 December 2008: http://www.w3.org/TR/WCAG20/ (link resides outside of ibm.com)
Copyright 1994-2009 W3C (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University), All Rights Reserved.