Visa Accessibility - Error Messaging (INT-002)

VGAR Interaction Requirements

Interaction

Error Messaging (INT-002)

Provide robust error handling that alerts and informs

All pages that accept user input must check for errors and allow the user to correct them.

This method gives the screen reader user an overview of all errors without needing to look through the page for errors. Additionally, this benefits users with cognitive disabilities by reducing cognitive load and benefits overall usability by clearly presenting all errors in the same place on the page.

Requirements

Check for Errors (INT-WEB-002-01)

All pages that accept user input MUST check for errors and allow the user to correct them through in-line and post-submit validation and messaging as detailed in INT-002-3 and INT-002-04. Where users are prevented from submitting a form with errors, in-line validation is required but post-submit validation is not. Where users are able to submit a form with errors, post-submit validation is required.

Summary Before Submit (INT-WEB-002-02)

If user input is collected across multiple pages in order to execute a transaction of some kind the user MUST be presented with a summary of the input before submitting. The user MUST be able to change input prior to final submission after reviewing.

Use aria-invalid (INT-WEB-002-03)

The aria-invalid attribute MUST be managed programmatically, when an error is being detected aria-invalid MUST be set to true. Controls that are being validated for errors MUST include aria-invalid="true" inside the field when an error is present.

Highlight Errors Visually (INT-WEB-002-04)

When an error is detected using in-line validation, highlight the field (e.g., with a bold red border, error icon with proper alternative text) and place error helper text near it.

In-line Error Messaging for Screen Reader (INT-WEB-002-05)

When an error is detected using client side validation, any previous role="alert" instances MUST be removed from the DOM, and role="alert" MUST be set on the container of the error_helpertext.

In-line Error Messaging for Screen Reader (INT-WEB-002-06)

When an error is detected using client side validation the following MUST be programmatically accommodated;

  1. Set aria-invalid="true"
  2. and add the ID of the error helper text container to the aria-describedby attribute if present
  3. or add an aria-describedby attribute if aria-describedby is not present

Example: aria-describedby="helpertext" changes to aria-describedby="error_helpertext helpertext".

Post-Submit Errors (INT-WEB-002-07)

When an error is detected using validation after the user submits the form (i.e., multiple errors may be detected at once):

  1. a list of the fields with errors MUST be placed in an alert box (messaging element)
  2. any previous role="alert" instances MUST be removed from the DOM
  3. the alert box/container MUST have role="alert" set for the messaging element
  4. focus MUST be automatically set to the first invalid form control
  5. fields with errors MUST include in-line error information per INT-002-03, INT-002-04, INT-002-05, and INT-002-06
  6. Inline errors SHOULD disappear when they have been corrected in the form.

Test Procedures

Keyboard (INT-WEB-002-01-T)

Confirm that if a page accepts user input it also checks for errors and allows the user to correct them.

Visual Inspection (INT-WEB-002-02-T)

  1. Examine the page to determine whether it allows users to:
    • Make any legal commitments or financial transactions, or
    • modify or delete data in a data storage system, or
    • Submit test responses.
  2. If the page does allow such actions, then verify that the following are true:
    • The user is presented with a summary of the input before submitting
    • user can review, confirm, and correct information before finalizing the submission.

Screen reader (INT-WEB-002-03-T)

Tab through each control on the page and confirm that no form controls announce as invalid if they are not invalid.

Keyboard (INT-WEB-002-04-T)

Confirm that when an error is detected using in-line validation, the visual UI highlights the fields with errors (e.g., with a red border) and places error helper text above or below each one.

Screen reader (INT-WEB-002-05-T)

Enter invalid data in a form field. Use the screen reader to navigate away from the field and confirm that after navigating away from the field aria-invalid="true" is added to the field and error helper text is associated using aria-describedby and this information is announced by the screen reader.

Screen reader (INT-WEB-002-06-T)

Fill out all client-side validated form controls with invalid data, return to the top of the form, and tab through all invalid form controls with each screen reader and confirm that on focus, invalid form controls are announced as such and that the text of the error helper text is read aloud.

Screen reader (INT-WEB-002-07-T)

  1. Use the screen reader to submit the form containing fields with errors
  2. Confirm that the screen reader announces the error message added to the top of the page on page/view refresh
  3. Confirm that focus is automatically set on the first invalid form control
  4. Confirm that moving to each field with an error causes the screen reader to announce that the field is invalid along with the error helper text
  5. Confirm that in-line field errors are identified correctly per INT-002-03, INT-002-04, INT-002-05, and INT-002-06
  6. Inline errors SHOULD disappear when they have been corrected in the form.