EIR Accessibility Policy, Chapter 4 - Electronic Forms

In This Chapter

4.1 Overview

All forms must be accessible and usable to everyone including people with disabilities and who may use assistive technologies. HHS Agencies use forms in a variety of formats including:

  • MS Word
  • PDF
  • HTML. These forms may be present as part of web applications, log-in screens, or online surveys.

4.2 Applicable Standards

In the Web Content Accessibility Guidelines (WCAG) 2.0, these success criteria (SCs) pertain to the design and coding of accessible electronic forms.

SC 1.1.1 Non-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. (Refer to Guideline 4.1 for additional requirements for controls and content that accepts user input.) [All formats]

Form fields require labels that are associated with the input in a manner that can be reported by screen readers and other assistive technologies. Common examples include:

  • Status bar and help text in MS Word forms
  • Tool Tips in PDF forms
  • Label elements in HTML forms.

SC 1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

When forms are divided into multiple sections the sections should be separated using headings to allow users of assistive technologies to identify and navigate to the different sections.

When groups of radio buttons or checkboxes are used the user of assistive technology must be able to determine that the answer choices are associated with a particular question.

When form fields are required to be completed or must be completed in a particular format the information about the form field being required and/or the acceptable format must be available when the label is read by the assistive technology.

For people using screen magnification the form field labels must be located in a manner that allows the user to determine which prompt is associated with each field.

SC 1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined. (Level A)

The instructions, form field prompts and other information are presented in an order that makes sense when read by a screen reader or other assistive technology. Examples of preferred reading order include:

  • Form field prompts and instructions are read before the input.
  • Tab order is correct.

SC 1.3.3 Sensory 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)

Good examples:

  • Press the Submit button.
  • If you answered yes to question 5, fill out all of the information in the user account section.

Bad examples:

  • Press the square button.
  • If you answered yes to question 5, fill out the information on the right hand side of the page.

SC 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding.

Good examples:

  • Required items say “Required” after them.
  • Changed items are marked with an asterisk.
  • Click the submit button.

Bad examples:

  • Required items are in red.
  • Changed items are in green.
  • Click the chartreuse button.

SC 1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Provide enough contrast between text and its background so that it can be read by people with moderately low vision. To verify the contrast between two colors, use a tool such as the Colour Contrast Analyser.

Although large-scale text may meet the requirement at a contrast ratio of 3:1 it is better to ensure that all text has a minimum contrast ratio of 4.5:1 because there is no such thing as large text on a mobile device that may be used in an environment where contrast is critical, such as outdoors.

Developers should also consider color differences that may be indistinguishable for some people with certain types of color blindness.

SC 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)

Content satisfies this success criterion if it can be scaled up to 200 percent — that is, up to twice the width and height. Ideally, text size can be scaled independently of overall magnification.

1.4.5 Images of Text: If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following: (Level AA)

  • Customizable: The image of text can be visually customized to the user’s requirements.
  • Essential: A particular presentation of text is essential to the information being conveyed.

Note: Logotypes (text that is part of a logo or brand name) are considered essential.

Use text that relies on system fonts to allow users to adjust the appearance of the text and make it easier for them to read. For example, do not use image buttons but instead use buttons that display actual text.

2.1.1 Keyboard: 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)

Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.

Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

Any program function that can be performed with a mouse can also be performed using the keyboard. The use of mousekeys would not satisfy this success criterion because it is not a keyboard equivalent to the application; it is a mouse equivalent—in other words, it looks like a mouse to the application.

2.1.2 No 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)

Note: Since any content that does not meet this success criterion can interfere with a user’s ability to use the whole page, all content on the Web page (whether it is used to meet other success criteria or not) must meet this success criterion. See Conformance Requirement 5: Non-InterferenceExternal site.

Good example:

  • A calendar widget allows users to add, remove or update items in their calendar using the keyboard. The controls in the widget are part of the tab order within the Web page, allowing users to tab through the controls in the widget as well as to any links or controls that follow.

2.2.1 Timing Adjustable: For each time limit that is set by the content, at least one of the following is true: (Level A)

  • Turn off: The user is allowed to turn off the time limit before encountering it; or
  • Adjust: The user is allowed to adjust the time limit before encountering it over a wide range that is at least ten times the length of the default setting; or
  • Extend: The user is warned before time expires and given at least 20 seconds to extend the time limit with a simple action (for example, “press the space bar”), and the user is allowed to extend the time limit at least ten times; or
  • Real-time Exception: The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible; or
  • Essential Exception: The time limit is essential and extending it would invalidate the activity; or
  • 20 Hour Exception: The time limit is longer than 20 hours.

Note: This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit. This success criterion should be considered in conjunction with Success Criterion 3.2.1, which puts limits on changes of content or context as a result of user action.

Provide options to disable time limits, to customize the length of time limits, or to request more time.

2.4.2 Page Titled: Web pages have titles that describe topic or purpose. (Level A)

Provide a unique title for each unique page. The title of the page is the first thing that is read to a screen reader user and it confirms that the user is where they expected to be.

2.4.3 Focus 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)

The order in which you tab through a form should match the intended order in which you fill out the form.

2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. (Level A)

If the form contains a link, the text of the link tells you where the link goes. If the form is printable, the active link should be in plain text and the URL should also be presented.

2.4.6 Headings and Labels: Headings and labels describe topic or purpose. (Level AA)

Form field labels describe what goes into the input. Headings are used to introduce sections of the form.

2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA)

When navigating a form using the tab key there is a clear visual indication of which form control or input is currently selected.

3.1.1 Language of Page: The default human language of each Web page can be programmatically determined. (Level A)

For HTML forms, include the lang attribute in the <html> tag and set its value to the language of the form.

For PDF forms, set the language property to the language of the form.

For MS Office forms, set the language through the language selection dropdown control on the Productivity tab.

For any other format, use the corresponding setting in that format.

3.1.2 Language of Parts: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

For HTML forms, set the lang attribute for the containing element for each change in language.

For PDF forms, set the language property for the containing tag for each change in language.

For MS Office forms, set the language for any part of the form where there is a language change.

For any other format, use the corresponding setting in that format.

3.2.1 On Focus: When any component receives focus, it does not initiate a change of context. (Level A)

Tabbing into or out of a form control does not cause the interface to change.

3.2.2 On 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)

Selecting an item from a dropdown menu, toggling a button, selecting a checkbox or entering text in a text field does not change the interface unless the user is provided instructions prior to selecting the control.

3.2.4 Consistent Identification: Components that have the same functionality within a set of Web pages are identified consistently. (Level AA)

Form fields and other controls are used consistently within a form.

3.3.1 Error 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)

If form errors are indicated automatically then the type of error and its location in the form is identified using text.

3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level A)

Text labels and instructions indicate to the user what is expected in the input.

3.3.3 Error 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)

If errors are automatically detected then the error indication provides information to the user about how to fix the error.

Good examples:

  • The user does not complete First Name, which is a required field. An error message says: "First Name is required."
  • In the Birthdate field, the user enters a future date. An error message says: "Birthdate cannot be in the future."

3.3.4 Error 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)

  1. Reversible: Submissions are reversible.
  2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
  3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

For Web-based forms and applications that create legal or financial commitments the user is provided with an opportunity to review the information that they have submitted and make changes prior to the final submission of the form.

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features. (Level A)

Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quotation mark, are not complete.

Best practice is to validate HTML code.

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. Standard HTML controls already meet this success criterion when used according to specification.

When scripting custom form components in HTML the developer is responsible for scripting all information presented through the accessibility API in a manner that is properly understood by the assistive technology.