ARIA Form Error Example
Notes
This is a draft. It is for discussion only.
- The form control is not labeled (the heading should be referenced via aria-labeledby)
- The extra instructions should be tagged via aria-describedby
- Required element should be tagged
- Error handling: Example should use aria invalid
- Error handling: Message should not disappear
- Error handling: Use aria live region on error message so that the user know it is there, or direct focus to the text box and use aria-describedby on the message.
Example (not clean)
search form
Search box must not be empty.
From the specification
aria-invalid (state)
Indicates the entered value does not conform to the format expected by the application.
If the value is computed to be invalid or out-of-range, the application author SHOULD set this attribute to true. User agents SHOULD inform the user of the error. Application authors SHOULD provide suggestions for corrections if they are known. Authors MAY prevent form submission when an associated form element has its aria-invalid attribute set to true.
When the user attempts to submit data involving a field for which aria-required is true, authors MAY use the aria-invalid attribute to signal there is an error. However, if the user has not attempted to submit the form, authors SHOULD NOT set the aria-invalid attribute on required widgets simply because the user has not yet entered data.
For future expansion, the aria-invalid attribute is an enumerated type. Any value not recognized in the list of allowed values MUST be treated by user agents as if the value true had been provided. If the attribute is not present, or its value is false, or its value is an empty string, the default value of false applies.
aria-label (property)
Defines a string value that labels the current element. See related aria-labelledby.
The purpose of aria-label is the same as that of aria-labelledby. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.
If the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. There may be instances where the name of an element cannot be determined programmatically from the content of the element, and there are cases where providing a visible label is not the desired user experience. Most host languages provide an attribute that could be used to name the element (e.g. the title attribute in HTML [HTML]), yet this may present a browser tooltip. In the cases where a visible label or visible tooltip is undesirable, authors MAY set the accessible name of the element using aria-label. User agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
aria-labelledby (property)
Identifies the element (or elements) that labels the current element. See related aria-label and aria-describedby.
The purpose of aria-labelledby is the same as that of aria-label. It provides the user with a recognizable name of the object. The most common accessibility API mapping for a label is the accessible name property.
If the label text is visible on screen, authors SHOULD use aria-labelledby and SHOULD NOT use aria-label. Use aria-label only if the interface is such that it is not possible to have a visible label on the screen. User agents give precedence to aria-labelledby over aria-label when computing the accessible name property.
The aria-labelledby attribute is very similar to describing an object with aria-describedby, where a description is intended to provide additional information that some users might need.
aria-required (property)
Indicates that user input is required on the element before a form may be submitted.
For example, if the user needs to fill in an address field, the author will need to set the field's aria-required attribute to true.
Note: The fact that the element is required is often presented visually (such as a sign or symbol after the widget). Using the aria-required attribute allows the author to explicitly convey to assistive technologies that an element is required.
Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.