Error Messages
Demo
<form id="errorForm">
<h1>Account Information</h1>
<!-- It is important to include an indication at the start of the form for how required fields are visually identified. In this example we use a short phrase to explain. -->
<p>Fields marked with * are required</p>
<!-- Here I have a paragraph tag that will become visible when a failed submission happens. This is a generic error message that will automatically communicate to users when it appears. An alternative option for this message is the "STATUS" role which will only communicate content that is present on page load and after it's visibilty is changed. A best practice is to include all of the errors that are present in the form in this message. -->
<p id="genericError" role="alert" aria-live="polite" class="hidden">There are errors present in the form.</p>
<div>
<!-- Every INPUT element needs a LABEL of some sort. The LABEL element is the best and most robust option. -->
<label id="labelOne" for="input1">First Name: *</label>
<!-- The REQUIRED attribute communicates to users that this field is required programmatically. The ARIA-DESCRIBEDBY attribute points to the error message associated with this field and will announce the value when a screen reader navigates to this form input. -->
<input required aria-describedby="error1" id="input1" type="text">
<p class="hidden" id="error1"></p>
</div>
<div>
<label id="labelTwo" for="input2">Last Name: *</label>
<input required aria-describedby="error2" id="input2" type="text">
<p class="hidden" id="error2"></p>
</div>
<div>
<label id="labelThree" for="input3">Password: *</label>
<input required aria-describedby="error3" id="input3" type="text">
<p class="hidden" id="error3"></p>
</div>
<div>
<label for="input4">State:</label>
<select id="input4">
<option>Oregon</option>
<option>California</option>
<option>Washington</option>
</select>
</div>
</form>
<div id="submitDiv">
<button id="submitButton">Create Account</button>
</div>
/* Basic form styling */
#errorForm {
width: 30%;
border: 1px solid black;
text-align: center;
margin: auto;
width: 40%;
padding-bottom: 10px;
}
#input1, #input2, #input3 {
margin: 5px;
}
#submitDiv {
display: flex;
justify-content: center;
margin-top: 10px;
}
/* By default our error messages are hidden */
.hidden {
display:none;
color: #A30C0C;
}
// Here I define all of my variables for my error message elements and label elements
let button = document.getElementById("submitButton");
let errorOne = document.getElementById("error1");
let errorTwo = document.getElementById("error2");
let errorThree = document.getElementById("error3");
let genericError = document.getElementById("genericError");
let labelOne = document.getElementById("labelOne");
let labelTwo = document.getElementById("labelTwo");
let labelThree = document.getElementById("labelThree");
// This function will target the input value of each input.
// It then checks if the input is blank and if so applies text to the error message element and makes them visible.
// It will also apply additional styling to the labels to satisfy success criterion 1.4.1 and 1.3.1.
let submit = function() {
if (input1.value === "") {
errorOne.textContent = "This field is required.";
labelOne.style.textDecoration = "underline";
labelOne.style.color = "#A30C0C";
};
if (input2.value === "") {
errorTwo.textContent = "This field is required.";
labelTwo.style.textDecoration = "underline";
labelTwo.style.color = "#A30C0C";
};
if (input3.value === "") {
errorThree.textContent = "This field is required.";
labelThree.style.textDecoration = "underline";
labelThree.style.color = "#A30C0C";
};
errorOne.style.display = "inline";
errorTwo.style.display = "inline";
errorThree.style.display = "inline";
genericError.style.display = "block";
};
button.addEventListener("click", submit);
Why use error messages?
Error messages play a crucial role in guiding users through the digital experience, helping them understand what went wrong and how to rectify the situation. Whether it’s submitting a form, completing a transaction, or interacting with a feature, error messages contribute to transparency and user empowerment. They communicate errors, validation issues, or unexpected outcomes, allowing users to correct mistakes and proceed with confidence. Thoughtfully crafted error messages contribute to a user-friendly interface, reducing frustration and promoting a positive interaction with the website or application. Ultimately, the strategic use of error messages aligns with best practices in usability and accessibility, ensuring that users can navigate the digital landscape seamlessly.
What are some accessibility concerns?
Clear and Understandable Language:
- Concern: Ambiguous or complex language in error messages can be challenging for users with cognitive disabilities or those with limited literacy skills.
- Mitigation: Use clear and simple language to convey error messages. Avoid technical jargon and provide concise instructions on how to resolve the issue.
Color Contrast and Visibility:
- Concern: Low color contrast between text and background may make error messages difficult to read, especially for users with visual impairments.
- Mitigation: Ensure sufficient color contrast for text and background in error messages to enhance readability. Use high-contrast combinations to cater to users with varying levels of visual acuity.
Error Location and Focus:
- Concern: After encountering an error, users may have difficulty locating the specific form field or element that needs attention.
- Mitigation: Include information in the error message about the location or nature of the error. Use ARIA attributes to set focus on the problematic element, helping users navigate directly to it.
Timing and Persistence:
- Concern: Errors presented too quickly or unexpectedly can be overwhelming, while errors that disappear too quickly may not allow users sufficient time to process.
- Mitigation: Provide a reasonable delay before displaying error messages to allow users to complete their input. Ensure that error messages persist until the issue is addressed or until the user dismisses them.
Accessible Form Validation:
- Concern: Users with disabilities may have difficulty perceiving and addressing form validation errors.
- Mitigation: Combine visual indicators with programmatically associated text or ARIA alerts to notify users of form validation errors. Ensure that screen reader users receive clear and timely feedback.
Alternative Notification Methods:
- Concern: Relying solely on visual or text-based error messages may exclude users with specific disabilities.
- Mitigation: Implement multiple notification methods, such as visual cues, text, and ARIA roles, to ensure that users with diverse needs can effectively perceive and understand error messages.
Tested using
Chrome
with NVDA
Firefox
with NVDA
- Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
- Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
- 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.
-
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.
- In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.