Forms – Section 508 Accessibility Guidelines

Info and Relationships #

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Content/Design Considerations

• The border around the grouped fields can be hidden programmatically if it conflicts with the design.
• Best Practice: Put form instructions at the top of the form, instead of the middle.

Development Considerations

• To hide the border around fieldset elements, put in the or in a CSS file

• Grouping related form controls:

  • Refer to ARIA (radio buttons, segmented inputs)

• Fieldset/Legend and Label/ID (see also WCAG H44 and WCAG H71)

• Techniques for WCAG Success Criteria:

  • H44: Using label elements to associate text labels with form controls
  • H71: Providing a description for groups of form controls using fieldset and legend elements)
  • H85: Using OPTGROUP to group OPTION elements inside a SELECT

• ARIA techniques:

  • aria-labelledby – Reference ID(s) that have been assigned to the form instruction(s); useful if the instructions are on the page but not together or next to the input form
  • aria-label – useful if the form instruction is not visible on the page
  • aria-describedby – reference ID(s) that have been assigned to information on the page that supports the form instruction

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. Examples of changes in context are:

1. Opening a new window
2. Moving focus to a different component
3. Going to a new page (or anything that would look to a user as if they had moved to a new page)
4. Significantly re-arranging the content of a page

Content/Design Considerations

• Automatic changes should not be initiated when a user makes a selection or enters information. Provide a clearly named to control (like a button) to initiate such changes.

Development Considerations

• Example – using an onchange event on a select element without causing a change of context

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.

Content/Design Considerations

• Provide a description of the error that includes the location of the error.
• Do not use ONLY color to indicate errors, such as a red outline around the field.

Development Considerations

• Identify input errors by describing the errors. (Including only a mark without further explanation on a form field error is not adequate.)
• If error is detected immediately when exiting the form, ensure the error notification is keyboard accessible.

Best Practices:

1. Move focus to error/success message.
2. Set error/success message container to tabindex=”-1”. Otherwise, focus cannot be set successfully on the message.
3. Provide a count of errors.
4. Associate error descriptions with form fields using aria-describedby so that screen reader users know how to fix the problem.
5. Make error messages visible so that sighted users know how to fix the problems.
6. Place error messages adjacent to the inputs so that screen magnification users can easily see which messages belong to which fields.

Tip: How to use “Alert” versus “Alert Dialog”

1. An alert (role=”alert”) does not require a user action. It does not move the keyboard focus. No part of the page is hidden or obscured or made unavailable at any time.
2. An alert dialog (role=”alertdialog”) requires a user action. It acts like a regular dialog, but it is supposed to convey more of a sense of urgency. Screen readers typically say “Alert dialog” when an alert dialog pops up. The focus moves to the dialog and the user is required to take action. Usually this means clicking a button, even if it may just be an “OK” button or a “Close” button. The user cannot navigate out of the dialog by just tabbing, and screen reader users cannot use keyboard shortcuts to access semantic elements (headings, landmarks, form elements, etc.) that are outside of the dialog.

Labels or Instructions #

Labels or instructions are provided when content requires user input.

Content/Design Considerations

• Provide adequate labels and instructions to help users accurately complete form fields.
• Make all of the instructions easy to find.

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.

Content/Design Considerations

• Provide suggestions on how to correct an error if known fixes are available.

Development Considerations

• Provide this information with the error notification (3.3.1)

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:

• 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.

Content/Design Considerations

• If your form is of the covered type, choose from the available options (Reversible, Checked, Confirmed) to meet this requirement.