VGAR Interaction Requirements
Interaction
- Accessible Forms (INT-001)
- Error Messaging (INT-002)
- System Messages (INT-003)
- Modal Windows (INT-004)
- Onchange / Onfocus (INT-005)
- Buttons and Links (INT-006)
- Control Moving Content (INT-007)
- No Blinking/Flashing (INT-008)
- Give Users Time (INT-009)
- Custom Controls (INT-010)
- Diverse User Needs and Preferences (INT-011)
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 <input> field when an error is present.
<label for="fname">First Name</label>
<input id="fname" aria-required="true" aria-invalid="false" type="text" class="dirty error" />
<span class="helper-error">Enter your first name</span>
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.
.dirty.error {
border:1px solid red;
}
.err-help {
color:red
}
<label for="firstName">First Name</label>
<input id="firstName" aria-required="true" aria-invalid="true" type="text" class="dirty error" />
<span class="err-help" style="display:block;">Enter your first name</span>
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.
<div id="validationError" class="error-message" style="display:none;">
Please fill out all required fields before submitting
</div>
$('[role=alert]').attr('role', null)
$('#validationError').css('display', 'block').attr('role', 'alert');
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;
- Set aria-invalid="true"
- and add the ID of the error helper text container to the aria-describedby attribute if present
- or add an aria-describedby attribute if aria-describedby is not present
Example: aria-describedby="helpertext" changes to aria-describedby="error_helpertext helpertext".
<label for="fname">First Name</label>
<input id="fname" aria-required="true" aria-invalid="false" type="text" />
<span id="errHelp_fname" class="help-err" style="display:none;">Enter your first name</span>
$('#fname').attr({
'aria-describedby': 'errHelp_fname',
'aria-invalid': 'true'
});
$('#errHelp_fname').show();
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):
- a list of the fields with errors MUST be placed in an alert box (messaging element)
- any previous role="alert" instances MUST be removed from the DOM
- the alert box/container MUST have role="alert" set for the messaging element
- focus MUST be automatically set to the first invalid form control
- fields with errors MUST include in-line error information per INT-002-03, INT-002-04, INT-002-05, and INT-002-06
- Inline errors SHOULD disappear when they have been corrected in the form.
<h1>The Best Form Ever</h1>
<div id="sysError" class="error-message" style="display: none;">
Please fix these errors:
<ul><li><!-- supply list of errors from server --></li></ul>
</div>
$('[role=alert]').attr('role', null)
$('#sysError').css('display', 'block').attr('role', 'alert');
$('input.error').first().focus();
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)
- 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 repsonses.
- 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)
- Use the screen reader to submit the form containing fields with errors
- Confirm that the screen reader announces the error message added to the top of the page on page/view refresh
- Confirm that focus is automatically set on the first invalid form control
- 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
- Confirm that in-line field errors are identified correctly per INT-002-03, INT-002-04, INT-002-05, and INT-002-06
- Inline errors SHOULD disappear when they have been corrected in the form.
Related Content
WCAG Success Criteria
W3C Techniques
- ARIA18: Using aria-alertdialog to identify errors
- ARIA19: Using ARIA role=alert or live regions to identify errors
- ARIA21: Using aria-invalid to indicate an error field
- H89: Using the title attribute to provide context-sensitive help
- SCR18: Providing client-side validation and alert
- SCR32: Providing client-side validation and adding error text via the DOM
- G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
- G71:Providing a help link on every web page
- G83: Providing text descriptions to identify required fields that were not completed
- G84: Providing a text description when the user provides information that is not in the list of allowed values
- G85: Providing a text description when user input falls outside the required format or values
- G98: Providing the ability for the user to review and correct answers before submitting
- G99: Providing the ability to recover deleted information
- G139: Creating a mechanism that allows users to jump to errors
- G155: Providing a checkbox in addition to a submit button
- G164: Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request
- G168: Requesting confirmation to continue with selected action
- G184: Providing text instructions at the beginning of a form or set of fields that describes the necessary input
- G193: Providing help by an assistant in the web page
- G194: Providing spell checking and suggestions for text input
- G177: Providing suggested correction text
- G199: Providing success feedback when data is submitted successfully
These materials and steps outlined on this website are provided “AS IS” and are intended for illustrative purposes only. They should not be relied upon for marketing, legal, tax, financial, regulatory or other advice. You are responsible for the legal aspects of any implementation of the concepts illustrated herein. Further, Visa neither makes any warranty or representation as to the completeness or accuracy of this information, nor assumes any liability or responsibility that may result from reliance on such information. You should not act or rely on such content without seeking the advice of a professional. All brand names, logos and/or trademarks are the property of their respective owners, are used for identification purposes only, and do not necessarily imply product endorsement or affiliation with Visa.