The Web Content Accessibility Guidelines 2.0

WCAG 2.0 Success Criteria

The Web Content Accessibility Guidelines Success Criteria relevant to forms are:

SCDescription
1.1.1Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. (Level A)
  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose.
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content. (Refer to Guideline 1.2 for additional requirements for media.)
  • Tests: If non-text content is a test, exercise or game that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.
1.3.1Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
1.3.2Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)
1.3.3Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound. (Level A)
2.1.1Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)
2.1.2No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away. (Level A)
2.4.3Focus Order: If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. (Level A)
2.4.5Multiple Ways: More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process. (Level AA)
2.4.7Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)
3.2.1On Focus: When any component receives focus, it does not initiate a change of context. (Level A)
3.2.2On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)
3.2.4Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)
3.3.1Error Identification: If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text. (Level A)
3.3.2Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)
3.3.3Error Suggestion: If an input error is automatically detected and suggestions for correction are known, then the suggestions are provided to the user, unless it would jeopardize the security or purpose of the content. (Level AA)
3.3.4Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one of the following is true: (Level AA)
  • Reversible: Submissions are reversible.
  • Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  • Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

The relevant guidelines are detailed in the website manager factsheet.

WCAG 2.0 Sufficient Techniques

For each of the guidelines and success criteria in WCAG 2.0 there are a wide variety of techniques. The techniques fall into two categories: Sufficient techniques – techniques or a combination of techniques that are sufficient for meeting the success criteria. Advisory techniques – techniques that should be considered (where relevant) to make content more accessible. The advisory techniques go beyond what is required by the individual success criteria and are not covered by these factsheets.

SCDescription
1.1.1Situation C: If non-text content is a control or accepts user input:
1.3.1Situation A: The technology provides semantic structure to make information and relationships conveyed through presentation programmatically determinable:
  1. G115: Using semantic elements to mark up structure AND H49: Using semantic markup to mark emphasized or special text (HTML)
  2. G117: Using text to convey information that is conveyed by variations in presentation of text
  3. G140: Separating information and structure from presentation to enable different presentations
  4. Making information and relationships conveyed through presentation programmatically determinable using the following techniques:
1.3.2
1.3.3G96: Providing textual identification of items that otherwise rely only on sensory information to be understood
2.1.1
  1. G202: Ensuring keyboard control for all functionality
  2. Ensuring keyboard control by using one of the following techniques.
  3. G90: Providing keyboard-triggered event handlers using one of the following techniques:
2.1.2G21: Ensuring that users are not trapped in content
2.4.3
  1. G59: Placing the interactive elements in an order that follows sequences and relationships within the content
  2. Giving focus to elements in an order that follows sequences and relationships within the content using one of the following techniques:
  3. Changing a Web page dynamically using one of the following techniques:
2.4.5G161: Providing a search function to help users find content
2.4.7
  1. G149: Using user interface components that are highlighted by the user agent when they receive focus
  2. C15: Using CSS to change the presentation of a user interface component when it receives focus (CSS)
  3. G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over
  4. G195: Using an author-supplied, highly visible focus indicator
  5. SCR31: Using script to change the background color or border of the element with focus (Scripting)

3.2.1

G107: Using “activate” rather than “focus” as a trigger for changes of context

Note: A change of content is not always a change of context. This success criterion is automatically met if changes in content are not also changes of context.

3.2.2
  1. G80: Providing a submit button to initiate a change of context using a technology-specific technique listed below
  2. G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
  3. SCR19: Using an onchange event on a select element without causing a change of context (Scripting)

Note: A change of content is not always a change of context. This success criterion is automatically met if changes in content are not also changes of context.

3.2.4

G197: Using labels, names, and text alternatives consistently for content that has the same functionality AND following the sufficient techniques for Success Criterion 1.1.1 and sufficient techniques for Success Criterion 4.1.2 for providing labels, names, and text alternatives.

Note 1: Text alternatives that are “consistent” are not always “identical.” For instance, you may have an graphical arrow at the bottom of a Web page that links to the next Web page. The text alternative may say “Go to page 4.” Naturally, it would not be appropriate to repeat this exact text alternative on the next Web page. It would be more appropriate to say “Go to page 5”. Although these text alternatives would not be identical, they would be consistent, and therefore would satisfy this Success Criterion.

Note 2: A single non-text-content-item may be used to serve different functions. In such cases, different text alternatives are necessary and should be used. Examples can be commonly found with the use of icons such as check marks, cross marks, and traffic signs. Their functions can be different depending on the context of the Web page. A check mark icon may function as “approved”, “completed”, or “included”, to name a few, depending on the situation. Using “check mark” as text alternative across all Web pages does not help users understand the function of the icon. Different text alternatives can be used when the same non-text content serves multiple functions.

3.3.1

Situation A: If a form contains fields for which information from the user is mandatory.

  1. G83: Providing text descriptions to identify required fields that were not completed
  2. SCR18: Providing client-side validation and alert (Scripting)

Situation B: If information provided by the user is required to be in a specific data format or of certain values.

  1. G84: Providing a text description when the user provides information that is not in the list of allowed values
  2. G85: Providing a text description when user input falls outside the required format or values
  3. SCR18: Providing client-side validation and alert (Scripting)
  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)
3.3.2
  1. G131: Providing descriptive labels AND one of the following:
  2. H44: Using label elements to associate text labels with form controls (HTML)
  3. H71: Providing a description for groups of form controls using fieldset and legend elements (HTML)
  4. H65: Using the title attribute to identify form controls when the label element cannot be used (HTML)
  5. G167: Using an adjacent button to label the purpose of a field

Note: The techniques at the end of the above list should be considered “last resort” and only used when the other techniques cannot be applied to the page. The earlier techniques are preferred because they increase accessibility to a wider user group.

3.3.3

Situation A: If a mandatory field contains no information:

G83: Providing text descriptions to identify required fields that were not completed

Situation B: If information for a field is required to be in a specific data format:

  1. G85: Providing a text description when user input falls outside the required format or values
  2. G177: Providing suggested correction text
  3. SCR18: Providing client-side validation and alert (Scripting)
  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)

Situation C: Information provided by the user is required to be one of a limited set of values:

  1. G84: Providing a text description when the user provides information that is not in the list of allowed values
  2. G177: Providing suggested correction text
  3. SCR18: Providing client-side validation and alert (Scripting)
  4. SCR32: Providing client-side validation and adding error text via the DOM (Scripting)
3.3.4

Situation A: If an application causes a legal transaction to occur, such as making a purchase or submitting an income tax return:

  1. G164: Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request
  2. G98: Providing the ability for the user to review and correct answers before submitting
  3. G155: Providing a checkbox in addition to a submit button

Situation B: If an action causes information to be deleted:

  1. G99: Providing the ability to recover deleted information
  2. G168: Requesting confirmation to continue with selected action
  3. G155: Providing a checkbox in addition to a submit button

Situation C: If the Web page includes a testing application:

  1. G98: Providing the ability for the user to review and correct answers before submitting
  2. G168: Requesting confirmation to continue with selected action

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

WCAG 2.0 Common Failures

SC 1.1.1 Non-text Content

The following are common mistakes that are considered failures of Success Criterion 1.1.1 by the WCAG Working Group.

FailureDescription
F65Failure of Success Criterion 1.1.1 due to omitting the alt attribute on img elements, area elements, and input elements of type “image”

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 1.3.1 Info and Relationships

The following are common mistakes that are considered failures of Success Criterion 1.3.1 by the WCAG Working Group.

FailureDescription
F2Failure of Success Criterion 1.3.1 due to using changes in text presentation to convey information without using the appropriate markup or text
F17Failure of Success Criterion 1.3.1 and 4.1.1 due to insufficient information in DOM to determine one-to-one relationships (e.g., between labels with same id) in HTML
F42Failure of Success Criterion 1.3.1 and 2.1.1 due to using scripting events to emulate links in a way that is not programmatically determinable

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 1.3.2 Meaningful Sequence

The following are common mistakes that are considered failures of Success Criterion 1.3.2 by the WCAG Working Group.

FailureDescription
F1Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 1.3.3 Sensory Characteristics

The following are common mistakes that are considered failures of Success Criterion 1.3.3 by the WCAG Working Group.

FailureDescription
F14Failure of Success Criterion 1.3.3 due to identifying content only by its shape or location

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 2.1.1 Keyboard

The following are common mistakes that are considered failures of Success Criterion 2.1.1 by the WCAG Working Group.

FailureDescription
F54Failure of Success Criterion 2.1.1 due to using only pointing-device-specific event handlers (including gesture) for a function
F55Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 2.1.2 No Keyboard Trap

The following are common mistakes that are considered failures of Success Criterion 2.1.2 by the WCAG Working Group.

FailureDescription
F10Failure of Success Criterion 2.1.2 and Conformance Requirement 5 due to combining multiple content formats in a way that traps users inside one format type

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 2.4.3 Focus Order

The following are common mistakes that are considered failures of Success Criterion 2.4.3 by the WCAG Working Group.

FailureDescription
F44Failure of Success Criterion 2.4.3 due to using tabindex to create a tab order that does not preserve meaning and operability
F85Failure of Success Criterion 2.4.3 due to using dialogs or menus that are not adjacent to their trigger control in the sequential navigation order
Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 2.4.5 Multiple ways

There are no common failures currently documented for the Success Criterion 2.4.5 in WCAG2.0. Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 2.4.7 Focus visible

The following are common mistakes that are considered failures of Success Criterion 2.4.7 by the WCAG Working Group.

FailureDescription
F55Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
F78Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.2.1 On Focus

The following are common mistakes that are considered failures of Success Criterion 3.2.1 by the WCAG Working Group.

FailureDescription
F55Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.2.2 On Input

The following are common mistakes that are considered failures of Success Criterion 3.2.2 by the WCAG Working Group.

FailureDescription
F36Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value
F37Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the status of a radio button, check box or select list is changed
F76Failure of Success Criterion 3.2.2 due to providing instruction material about the change of context by change of setting in a user interface element at a location that users may bypass
Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.2.4 Consistent Identification

The following are common mistakes that are considered failures of Success Criterion 3.2.4 by the WCAG Working Group.

FailureDescription
F31Failure of Success Criterion 3.2.4 due to using two different labels for the same function on different Web pages within a set of Web pages

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.3.1 Error Identification

There are no common failures currently documented for the Success Criterion 3.3.1 in WCAG2.0.

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.3.2 Labels and Instructions

The following are common mistakes that are considered failures of Success Criterion 3.3.2 by the WCAG Working Group.

FailureDescription
F82Failure of Success Criterion 3.3.2 by visually formatting a set of phone number fields but not including a text label

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.3.3 Error suggestions

There are no common failures currently documented for the Success Criterion 3.3.3 in WCAG2.0.

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]

SC 3.3.4 Error Prevention

There are no common failures currently documented for the Success Criterion 3.3.4 in WCAG2.0.

Copyright © W3C 11 December 2008 World Wide Web Consortium [Status: Recommendation]