Skip to main content

User experience design

Feedback that helps a user complete tasks needs to be accessible. Users with disabilities may interact with content in atypical ways. Ensure error messages and other less critical feedback can be noticed and acted on, whether a user is blind, deaf, or unable to use a mouse.

Level 1

Provide errors accessibly

    Ensure error messages are obvious to everyone

  • What to do

    Designing error messaging involves finding a balance between alerting and disrupting users. On one hand, you want to ensure alerts are noticed and actionable. But you do not want to disrupt users more than is necessary.

    This balance is crucial for accessibility. Users with visual and cognitive disabilities are less likely to notice errors that are not directly brought to their attention. But they also do not want to have their work interrupted unnecessarily, either by design or unintentionally.

    In many cases, errors warrant changes of focus. This ensures that all users are aware of the problem. You can reposition users to the field in error, or to an error message that appears in-line after a page reload. You can alert users with modal dialogs. All of these can be done accessibly. Notations in the wireframes can help developers use the right techniques.

    In-line errors are the easiest for the user to correct, as they clearly show the error message near the field where the error occurs. Depending on the circumstances, these can be surfaced programmatically to the user through alerts or supplemental descriptions (such as `aria-describedby’).

    Dialogs require immediate user attention. They are good for surfacing and resolving a single error. Use modal dialogs, which prevent navigation to the background web page. In your wireframes, indicate where focus should go when the dialog is opened and closed. When the dialog is dismissed, put focus on the item in error, or return to the element that opened the dialog (or another logical place, especially if the error was not surfaced due to a user action).

    If the design requires the page to reload before validation, the preferred location for errors is at the top of the page or form. Errors at the bottom are more difficult to locate and pose an increased cognitive load to fix.

    Lost network connection dialog with error message, followed by Cancel and Reconnect buttons

    Error message in a modal dialog

    Login failed dialog with error message, 'Incorrect username or password', followed by red outline on both Username and Password input fields

    Error message at the top of the form

    Login failed dialog with red outline on Username field immediately followed by error message 'This is not a valid username'

    Error message in-line with the input in error

    Resources

    Requirements

    Related toolkit topics

  • Carry out validation in an accessible way

  • What to do

    For all users, form validation requires a balance between alerting and disrupting users. However, certain validation practices can be especially disruptive to some users with disabilities.

    Many screen reader users will orient themselves by navigating through the entire form before entering any data. If validation interrupts the user each time a required field is left empty, these users will be hindered. For the same users, validation that takes place while the user is entering values can be problematic, since messages may be repeated to the user after each key press. Where possible, use validation that occurs after a user completes input (when the user leaves the field).

    Play

    Use validation that occurs after users complete and leave the input field.

    Play

    Avoid using validation while users are still entering values in the input field.

    Resources

    Requirements

    Related toolkit topics

  • Ensure the user can easily get to form elements that need to be fixed

  • What to do

    For all three of the feedback interactions described in Ensure error messages are obvious to everyone, you need to ensure that users can easily get from the message to the item in error.

    • For inline errors detected after form submission, you will typically move the focus to the first input in error at the same time you display the message. However, do not reset focus if the error is detected as a user exits an input, which can effectively trap a user in an input.
    • For dialogs, one of the user actions should cause focus to move to the item in error. Be sure to designate both the item that takes focus and which dialog response triggers that action.
    • For error summaries at the top of a form, provide a link to each of the inputs in error, and consider placing focus on the error summary on page load.
    at the top of a webpage is a title '2 errors found' followed by two errors listed as hyperlinks

    In the list of errors at the top of the page, this example provides links to each field in error.

    a modal dialog titled 'Missing input' with text 'Phone number is a required field and must be filled in'

    This modal dialog only reports one error. After pressing OK, the user should be relocated to the Phone number field.

    Email and Phone number input fields, both with red outlines and error messages directly below each: 'Please enter an email address' and 'Phone number can only contain numbers'

    After the user attempts to submit the form, keyboard focus is moved to the first field needing attention, and an in-line message explains the error.

    Resources

    Requirements

    Related toolkit topics

Help avoid unintended user consequences

    For important transactions, allow users to verify, correct, or reverse actions

  • What to do

    Users with disabilities may be more likely to make mistakes. They may transpose numbers and letters or hit keys by mistake. Providing the ability to reverse actions allows users to correct a mistake that could cause serious consequences. Providing the ability to review and correct information gives the user an opportunity to detect a mistake before completing a transaction. This could make the difference between overpaying a bill, overdrawing a bank account, or paying the correct amount.

    When a user carries out important transactions, provide opportunities for them to review and correct information, and to confirm, cancel, or reverse the action. This applies to workflows that cause a legal commitment or financial transaction to take place, that change or delete data in data storage systems, or that submit test responses. Be sure to make the validation process accessible by using the guidance in this toolkit.

    There are many ways to meet this requirement. The particular workflow will dictate the best way to help users avoid unintended consequences of transactions.

    modal dialog titled 'delete data?' followed by text 'are you sure you want to delete XXX?' with cancel and delete buttons

    Allow users to confirm or cancel important transactions.

    notification saying 'XXX was moved to Trash' with undo button

    Allow users to reverse actions for important transactions.

    Resources

    Requirements

    Related toolkit topics

Level 2

Help users notice updates and suggestions

    Determine whether feedback is important enough to disrupt users

  • What to do

    As discussed in Ensure error messages are obvious to everyone, designers need to determine how disruptive to make user feedback. If you want to get a user’s attention, a modal dialog takes focus and must be responded to by users before they can proceed. A warning or other critical piece of feedback may warrant such a dialog. However, most other feedback to users, including almost all suggestions, should not disrupt their current activity. There are non-disruptive ways of providing feedback and messages, such as dynamically adding text to the UI. There are accessibility considerations, especially regarding non-modal dialogs. Designers should flag feedback in the wireframes and indicate its level of importance. Where appropriate, developers can programmatically indicate a status message, ensuring it is surfaced to assistive technologies such as screen readers.

    modal dialog titled 'delete data?' followed by text 'this action will permanently delete the selected data' with cancel button and delete button

    You can flag errors or warn users by changing the focus (such as by using a dialog)

    error notification with text 'error: please fill out all required fields'

    If you need to provide important information without disrupting users (by causing a change of focus), mark the new content as “alert role” in the wireframe for developers.

    success notification with text 'success: your file has been successfully uploaded!'

    When you need to provide a status update based on user actions or system’s state, provide a screen update and mark as “status” for developers.

    informational notification with text 'system update is available'

    When you want to promote a new product or tell the user about an available update, provide information but do not assign any “alert role” or “status role.”

    Resources

    Requirements

    Related toolkit topics

  • Optimally position pop-ups and overlays

  • What to do

    Some dynamically appearing content appears over other content but does not take focus. Non-modal dialogs, toasters and most pop-ups are examples. Such new content has competing considerations to be balanced. The content needs to be discoverable and potentially actionable, while not unnecessarily disrupting the user or obscuring important content.

    Any overlaid content that does not take focus risks obstructing important information in the background. Work with visual designers to ensure the overlay is visually distinct so users can easily tell when it covers something else. Work with content writers to minimize the amount of content in the overlay. Doing so will reduce the potential impact of covering important information.

    In cases where new content appears in response to a user action, position the content near the triggering element. This makes it more likely the user will notice it. Discoverability is especially challenging for users with low vision who enlarge content in order to more easily read it. Magnification reduces the field of view, so new content not in close proximity may go unnoticed.

    New non-critical content can also appear without an overt user action. Communication notifications often appear as non-modal dialogs or flyouts. A low vision user will probably be unaware of such notices, especially if they appear outside the magnified area. As a best practice, avoid adding new content without a user action driving its appearance. Where content does appear that is not in response to a user action, follow guidance elsewhere on this page to determine its relative importance.

    Play

    Position new content near the trigger, as shown with this information icon.

    Play

    Don't position new content far from the trigger, which decreases its discoverability.

    Resources

    Requirements

    Related toolkit topics

  • Mark non-disruptive feedback as status messages, when appropriate

  • What to do

    Users with no or low vision can miss feedback that does not disrupt them (by taking focus). Flag important notices about user or system actions, so that development can treat them as status messages, a requirement in WCAG 2.1. Such status messages can include changes to a user’s shopping cart or the results of a search query or form submission. However, do not flag informational and promotional messages this way. Work with content designers to determine the relative importance of messages.

    error notification with text 'error: please fill out all required fields' notated as 'implement as status'

    Flag important notices so developers can implement them as status messages.

    informational notification with text 'system update is available' notated as 'implement as status'

    Do not flag informational or promotional notices for developers to implement as status messages.

    Requirements

    Related toolkit topics

Level 3

Make time limits adjustable