#input assistance

no. 136

Make sure users are notified of required fields left blank as soon as the page reloads

There are many ways to successfully convey to assistive technologies users that required fields might have been left blank, using client-side scripting techniques or even ARIA. But when no such technique is used and the information submitted is processed directly on the server, it is important that screen reader users be quickly made aware when the form returns errors. One reliable way to do this is to notify users of a problem, as soon as the page reloads.

To do so, simply make sure that a notification of the presence of errors is indicated directly in the title element of the page. While the value of the page title should retain all relevant information about the page itself, in cases where notification error messages are required, the title element value should include such a notification, letting users know about the problem. As the page reloads, authors can dynamically modify the value of the title element, so it begins with a warning that some required fields were omitted on the previous screen. While other mechanisms must also be implemented to help track input errors returned in the page itself, providing such a notification in the page title will guarantee that the first thing screen reader users hear when reloading the page will be that the form was not successfully submitted, and that input errors or omissions need to be addressed.

User Story

As a user using assistive technology, I want to be made aware when required fields are overlooked and left blank as soon as the page reloads, so that I can enter the required data and successfully submit the form.

Simple Code Example

<title>Required fields were left blank and as a result, the form was not successfully submitted. Please fix the errors below. Contact Us – XYZ MegaCorp</title>

Testing Methodology

Fill out a form and submit it, while deliberately leaving one or more required (mandatory) fields blank. As the page reloads, validate that the page title indicates the presence of errors. Make sure that any data previously entered by the user is re-displayed, unless the data is in a security related field where it would be inappropriate to retain the data for re-display.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.3 Error Suggestion

Related Technique: G83

Make sure users are given the opportunity to review and correct data before submission

Form interactions dealing with legal commitments or financial transactions carry more implications than others. It is therefore important that there be no errors in the data submission, as users will not have the opportunity to fix errors once it has been committed. Whenever users are dealing with forms meant to transfer sensitive data, authors should take extra steps to ensure users have a fair chance of catching errors before it’s too late. In order to avoid input errors that would be otherwise difficult or impossible to fix once data has been transferred over, authors should provide users with ways to ensure input is correct before completing an irreversible transaction.

To do so, simply make sure that whenever sensitive data is involved, users get a chance to review and correct information before activating the submit button. Doing so on a simple, one-page form is easy since users can simply review the form before submitting it. On a form that spans across multiple pages however, where data is collected from users in multiple steps before the transaction is committed, users may not recall all of the data that was entered in previous steps. One way enable them to review the data would be to cache the results of each step and allow users to navigate back and forth to review as a final step. Another way would be to provide a summary of all data collected in all steps, for users to review prior to the final commitment of the transaction.

User Story

As a user using assistive technology, I want to be given the opportunity to double check all data committed to a form, so that I can avoid potential errors that would be difficult to fix once the data is submitted.

Simple Code Example

Not Applicable

Testing Methodology

Before submitting a form, check that users are prompted to review and confirm data. If user data is collected in multiple steps, validate that users are allowed to return to previous steps to review and change data. Determine whether a summary of all data input by users is provided before the transaction is committed and a method is provided to correct errors if necessary.

Specification Details

WCAG 2.0: Level AA

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.4 Error Prevention (Legal, Financial, Data)

Related Technique: G98

Make sure the aria-describedby property is used to identify form control labels

Buttons intended to close modal dialog windows are often represented as simple “X” characters, located in the upper right corner of the windows. While this use has become a widely accepted user interface design convention throughout websites, it can still confuse some users, especially those who cannot actually see the screen and would only hear about an actionable page component called X. In order for these buttons to be meaningful to all users, including those who use screen readers, authors need to make sure the value conveyed through assistive technologies is much more descriptive.

To do so, simply make sure to explicitly and programmatically associate the “X” value with complementary information that will provide context and purpose for the button. This complementary information can reliably be conveyed through the use of the aria-describedby property, assigned to the button itself. While it will not provide additional information to sighted users, doing so will allow non-sighted users who cannot benefit from the visual indicators of the page to still get a clear understanding of the button’s purpose or function.

User Story

As a user using assistive technology, I want every button to be clearly labelled, so that I can quickly understand what their purposes or functions are.

Simple Code Example

<button aria-describedby="descClose" onclick="myDialog.close()">X</button> ... <div id="descClose">Closing this window will discard any information entered and return you back to the main page.</div>

Testing Methodology

Using the Jim Thatcher’s Favelets for Firefox, select the “Aria” test and look for any instances of aria-describedby attributes on buttons and for each occurrence, check whether the text description associated with that button appropriately informs about the button’s purpose or function.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels and Instructions

Related Technique: ARIA1

Make sure indications of required form controls are conveyed using the required attribute

Before looking into options like aria-required properties to identify mandatory form controls, authors should always consider using the HTML required attribute, which natively conveys the information about the mandatory state of a form control to all user agents and assistive technologies. While this approach will work great for users of screen readers, it has the distinct disadvantage of not displaying visual indications to sighted users, and as such, other methods should generally be preferred. However, as most screen readers don’t read the asterisk symbol by default, resorting to the required attribute as a complementary mechanism to the popular asterisk symbol indicator can be a convenient way to make sure the mandatory indication is provided to both sighted and non-sighted users.

To do so, simply make sure the mandatory form control is assigned a required attribute. The attribute can either be empty, or set with a value of "required" (required=”required”). To avoid repetition in cases where the mandatory indication would be announced more than once, make sure that whenever the required attribute is used, that there are no text indications of the required fields provided for the same form control except for the asterisk symbol. Providing an aria-required property to the form control or a true text indication in the form control label on top of the required attribute will cause the required state to be conveyed twice, which will prove annoying to screen reader users.

User Story

As a user, I want to be made aware of required form controls in a form, so that I know without a doubt which fields are mandatory and I can safely avoid errors.

Simple Code Example

<label for=”user”>Username</label> <input type=”text” id=”user” required>

Testing Methodology

Using the Jim Thatcher’s Favelets for Firefox, select the “Form Labels” test and look for any instances of required attributes on form controls and for each occurrence, check whether the text label associated with that form control also conveys the information visually.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels or Instructions

Related Technique: H90

Make sure examples of data formats are provided when specific formats are expected

Another important factor that contributes to generating multiple issues with form submissions is the expectation of specific input formats in form controls. Whenever a specific input format is expected for a credit card, a phone number or a calendar date for example, authors should make sure that this information is clearly conveyed in text, directly next to the text label that is associated with the form control. Providing this information to users will help them avoid common input errors and frustration, by informing them first hand about restrictions on the data format they are expected to enter.

To do so, simply make sure the expected format is clearly defined as part of the form control’s text label. This can be done by describing characteristics of the format in text, or by providing a sample of the expected data format. However, in the spirit of a truly international and accessible experience, authors should make sure that multiple formats can be recognized and approved by the system, whenever that is possible. Rather than imposing users with a specific data format that may be different from their own, authors should work on validation scripts that can generously accepting different internationally recognized formats whenever possible. Doing so will dramatically reduce the number of submission errors and end users will thank you for it.

User Story

As a user, I want the text label of every form control expecting a specific input format to provide clear and descriptive examples of that format, so that I can reliably input data in the expected format and submit the form successfully.

Simple Code Example

<label for="date">Date (dd-mm-yyyy)</label> <input type="text" name="date" id="date">

Testing Methodology

For each form control that requires a specific input format, check that this expected format is clearly and programmatically defined as part of the form control’s text label.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels and Instructions

Related Technique: G89

Make sure required fields identified with asterisks are also announced as such in text

Using the asterisk symbol (*) to identify required form controls in a form is perhaps the most universally recognized method of visually conveying which fields are mandatory in a form. However, as we’ve seen in previous tips, the asterisk symbol is not part of the characters that are naturally conveyed at the default verbosity level of most screen readers. Consequently, non-sighted users often miss this indication, which prevents screen reader users from being made aware of the presence of mandatory fields. In order to efficiently use asterisk symbols to identify required fields, author need to make sure the mandatory indications will be picked up regardless.

To do so, simply make sure that either an image of an asterisk is used instead of the actual character, so a default ALT text value of “required” or “mandatory” can be set to the image. Alternatively, use the text asterisk symbol on the text label, but make sure the form control is assigned an aria-required attribute set to true (aria-required=”true”), so screen readers can still convey the state to end users. Whichever option is preferred will yield equivalent results, but make sure not to use both on the same form control, so screen reader users don’t end up receiving the information twice (one from the ALT attribute value and another one from the aria-required property).

User Story

As a user, I want to be made aware of required form controls in a form, so that I know without a doubt which fields are mandatory and I can safely avoid errors.

Simple Code Example

<label for=”user”>Username <img src=”asterisk.png” alt=”required”></label> <input type=”text” id=”user”> or <label for=”user”>Username *</label> <input type=”text” id=”user” aria-required=”true”>

Testing Methodology

For each required form control, check that the required status is indicated in the form control's label by looking at the ALT attribute value of the image or, using the Jim Thatcher’s Favelets for Firefox, select the “Aria” test and look for any instances of aria-required on form controls.

Specification Details

WCAG 2.0: Level A

Principle: Understanding

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels or Instructions

Related Technique: H90

Make sure indications of required form controls are conveyed through ARIA-REQUIRED

Whenever authors run into a situation where it is inconvenient to clearly identify required fields with a strong visual indicator, they can look towards the aria-required property to indicate in a programmatically determined way that the completion of a user input field is mandatory for successful submission of a form. While this approach will work great for users of screen readers, it has the distinct disadvantage of not displaying visual indications to sighted users, and as such, other methods should generally be preferred. However, as most screen readers don’t read the asterisk symbol by default however, resorting to aria-required as a complementary mechanism to the popular asterisk symbol indicator can be a very convenient way to make sure the mandatory indication is provided to both sighted and non-sighted users.

To do so, simply make sure the mandatory form control is assigned an aria-required property with a value set to true (aria-required=”true”). To avoid repetition in cases where the mandatory indication would be announced more than once, make sure that whenever aria-required is used, that there are no text indications of the required fields provided for the same form control except for the asterisk symbol. Providing a required attribute to the form control or a true text indication in the form control label on top of the aria-required property will cause the required state to be conveyed twice, which will prove annoying to screen reader users.

User Story

As a user, I want to be made aware of required form controls in a form, so that I know without a doubt which fields are mandatory and I can safely avoid errors.

Simple Code Example

<label for=”user”>Username *</label> <input type=”text” id=”user” aria-required=”true”>

Testing Methodology

Using the Jim Thatcher’s Favelets for Firefox, select the “Aria” test and look for any instances of aria-required on form controls and for each occurrence, check whether the value of the aria-required attribute is the correct required state of the user interface component.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels or Instructions

Related Technique: ARIA2

Make sure indications of required form controls are conveyed through IMG elements

Informing users about required form fields and programmatically conveying that information to assistive technologies is critical in making sure the most basic form submission errors are avoided. However, providing that information in plain text is often considered to be inelegant by visual designers, who will often prefer to rely on symbols to convey that information. As a result, another option that is often found is to use the asterisk (*) symbol and position it right next to the label of the field that is mandatory. As the asterisk text symbol is not a recommendable solution due to most screen readers ignoring it by default, a favoured accessible approach is to use an image instead.

To do so, simply make sure the text label wrapped into the LABEL element that is tied to the required form control also carries an image of the asterisk symbol, complete with an ALT attribute value describing its function (alt=”required”). As long as the image and the content of the LABEL element are programmatically bound to the form control, setting focus on the control will automatically convey the mandatory status to assistive technology users. Note that in cases where all fields are mandatory, it is perfectly acceptable to simply provide users with a notification at the beginning of the form, stating that all form controls are required. If so, authors may consider using the aria-labelledby property to programmatically bind all form controls to this text indication.

User Story

As a user, I want to be made aware of required form controls in a form, so that I know without a doubt which fields are mandatory and I can safely avoid errors.

Simple Code Example

<label for=”user”>Username <img src=”asterisk.png” alt=”required”></label> <input type=”text” id=”user”>

Testing Methodology

For each required form control, check that the required status is indicated in the form control's label by looking at the ALT attribute value of the image. Whenever an indicator of required status is not provided, check that the meaning of the indicator is explained before the form control that uses it.

Specification Details

WCAG 2.0: Level A

Principle: Understandable

Guideline: 3.3 Input Assistance

Success Criterion: 3.3.2 Labels or Instructions

Related Technique: H90