Skip to main contentIBM Accessibility

Design

Consider the different ways users interact with web applications via the keyboard or assistive technologies.

Level 1 - core

    Tab order

  • Keyboard users, especially users who are blind, navigate interactive elements on a page by pressing the Tab key. The tab order is the sequence that the interactive elements follow. The standard behavior follows the reading order: top to bottom, left to right.

    What to do
    • Annotate the tab order if it doesn’t follow the standard behavior
    • Reduce tabbing by grouping components
    arrow keys are notated between individual components, with the group of components notated as 'single tab stop'

    Consider grouping components as a single tab stop. Annotate that arrows are used to navigate between items.

    Resources
    Requirements
    Related toolkit topics

    • Keyboard interaction

  • Standard HTML elements have default keyboard behaviors, however complex or custom components will need annotations on intended keyboard behavior for implementation. Another option is to surface keyboard instructions directly in the UI.

    What to do
    • Annotate intended keyboard interaction for modified or custom components
    • Provide keyboard instructions in the UI for unfamiliar keyboard operations
    accordion with annotations 'Enter or Space bar expands or collapses accordion'

    Annotate intended keyboard interaction for components that aren’t standard HTML elements.

    annotations show keyboard navigation and tab stops in the content

    Provide keyboard instructions in the UI for components where keyboard operation is less familiar. For this drag and drop component, the instructions appear on keyboard focus.

    Resources
    Requirements
    Related toolkit topics

    • Mouse-operable components

  • Users who are blind rely heavily on keyboard navigation. Any component that can be operated with a mouse should be reachable and operable by keyboard, or have a keyboard equivalent.

    What to do
    • Ensure all mouse-operable components are reachable by keyboard
    • Provide a keyboard equivalent for drag and drop
    • Annotate keyboard equivalents for components with multiple mouse operations
    Play

    For drag and drop components, provide the keyboard equivalent for how to select the item, how to move the item, and where to drop the item.

    annotate keyboard equivalents for components

    Annotate the keyboard equivalent for components (such as these tiles) that have multiple mouse operations.

    Resources
    Requirements
    Related toolkit topics

    • Pop-ups and overlays

  • Blind users navigating a page via keyboard can get stuck in a UI if keyboard navigation is not properly implemented. An easy way to reduce keyboard traps is to ensure the Esc key performs the same function as Cancel or Close mouse actions.

    Sighted keyboard users have a different challenge with overlays. If the new content persists after the user has left it, it can potentially obscure other content, and prevent some controls from being visible as they get focus. One option is to position pop-ups in white space. Another is to ensure notices are dismissed automatically when they no longer have focus.

    What to do
    • Communicate that Esc key is always the keyboard equivalent for Cancel or Close
    • Position pop-ups so they do not obscure other content, or dismiss pop-ups on loss of focus
    modal dialog with annotations saying 'Esc also activates the close button'

    Communicate for development that the Esc key always triggers the same function as Cancel or Close buttons.

    Resources
    Requirements
    Related toolkit topics

    • Input components

  • Blind users rely on proper implementation for screen readers to relay the label that an input is associated with. Communicate with development any such relationships in your designs.

    What to do
    • Connect each label and input in your wireframes
    Annotate labels and UI elements

    Annotate the association between the labels and UI elements for implementation.

    Requirements

    • Custom components keyboard guidance

  • Custom components often don’t have standard HTML keyboard behavior. The ARIA authoring practices provide detailed guidance to ensure such components meet expected keyboard behavior and are accessible to users with assistive technology.

    What to do

    – Follow the ARIA keyboard guidance for custom components

    Resources
    Requirements
    Related toolkit topics

    • Surfacing error messages

  • Users with visual and cognitive disabilities are likely to miss errors that are not directly brought to their attention, but it’s important to surface error messages in a way that alerts users without being overly disruptive. Screen reader users who navigate an entire form before entering data can also be disrupted if validation occurs each time a required field is left empty.

    What to do
    • Ensure error messages are obvious to everyone
    • Avoid carrying out validation before users fill out the input and exit focus
    • Ensure users can easily get to form elements that need to be fixed
    at the top of a webpage is a title '2 errors found' followed by two errors listed as hyperlinks

    If design requires the page to reload before validation, an error summary at the top of page and provide a link to each input in error. Also consider placing focus on error summary on page load.

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

    For dialogs, one of the user actions should move the focus to the item in error. In this example, pressing the Ok button should move the focus 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'

    For inline errors detected after form submission, focus should move to first input in error.

    Resources
    Requirements
    Related toolkit topics

    • Transactions

  • To prevent serious consequences, allow users to review their input data in a concise form, especially for transactions that involve money, legal commitments, or user-controlled data.

    What to do
    • Summarize pending transactions so that users can check and confirm
    Delete data? dialog with message that says, 'This action CANNOT be undone. This action will permanently delete the selected data.', followed by black Cancel and red Delete buttons

    A dialog box confirms with the user whether or not to go through with the permanent result of deleting selected data.

    Resources
    Requirements

    • Reverse and undo

  • To prevent serious consequences, allow users to reverse actions in order to correct a mistake, especially for transactions that involve money, legal commitments, or user-controlled data.

    What to do
    • For important transactions, allow users to verify, correct, or reverse actions
    • Provide clear instructions when users can reverse an action
    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, such as selecting the Undo button.

    Resources
    Requirements
    Related toolkit topics

Level 2 - continued

Level 3 - complete