Skip to main content

Content design

All users must be able to understand and fill in forms. Many accessibility issues occur when users can’t connect labels with the correct input. Forms are harder for users with low vision who have their screens magnified; an input and its matching label may not be visible at the same time. Blind users cannot see how close a label is to a field, so cannot understand the relationship unless the two are programmatically linked. Users with some cognitive disabilities may not understand complex labels. The Content designer’s job is to help address or capture such considerations so that developers can code accessibly.

Level 1

Make labels clear, consistent, and persistent

  • What to do

    Ensure that each label succinctly and clearly describes the purpose of the element. A good label helps the user understand both the function of a control and what input is expected. Wherever possible, all inputs, buttons, and controls should have a label.

    Use consistent text labels throughout the product when elements do the same thing. Use the same wording for:

    • Links that go to the same content
    • Buttons or icons that perform the same function
    • Input elements that gather the same information
    Promo label immediately above input field followed by button 'Apply to order'

    Ensure labels describe its purpose so users understand they can insert a code in the input field.

    Input answer label immediately above input field followed by button 'Submit'

    Don't use vague labels that don't clearly describe to users what they should put into the input field.

    Resources

    Requirements

Establish a clear association between labels and inputs

  • What to do

    In wireframe notations, show the association between the text label you developed and the UI element it describes. Developers will use this information to implement the association in a programmatic way. This in turn lets users with disabilities understand the relationships through assistive technologies.

    Annotations show the association between an Email label and an input field directly below

    Show the association between the labels and UI elements in wireframes.

    Requirements

  • What to do

    Ideally, every input will have a label. Where a label does not exist, or where the same text describes multiple inputs, work with UX to improve the design. For example, can you use a single input for the telephone number? Where any input cannot be visibly labelled, content designers should notate a label in the wireframe. This allows developers to provide what is called the “accessible name.” Carefully consider and develop labels for groups of text inputs that visually look like they share one visible label. Common examples include:

    • Phone numbers
    • Zip codes with extended routing
    • Credit card numbers

    Such fields can be confusing if the labeling isn’t clear, especially for someone who cannot see the visual association. How do they know to enter the area code or the first four digits of a card? Be clear about what input is needed.

    Wireframe annotations indicate the Phone label as group label for two unlabelled inputs, and indicate non-displayed aria-label values of 'number' and 'area code' for these two inputs

    Notate any group labels that apply to more than one input field, and notate hidden aria labels where each input lacks a unique label.

    Requirements

  • What to do

    Required fields usually involve two content decisions: how to mark each required field, and how to show what the marks indicate. Where a symbol such as an asterisk is used to indicate a required field, annotate that the symbol is part of the label for the field. This will position it for maximum visibility. In addition, for users who cannot see the symbol, by making it part of the label, it will be programmatically linked to the input.

    The meaning of the symbol used should be explained in text (traditionally called a legend) that precedes the form inputs. Consider including a notation for developers, suggesting this legend text be associated with the first use of the required symbol (using aria-describedby or an equivalent technique). That way, the text can be surfaced to assistive technologies. Another accessible way of indicating required fields is to include “(required)” in the label, which removes the need for a legend.

    A design trend is to visually indicate optional input fields rather than the required ones. This practice is an effort to simplify the amount of information in the form when most (if not all) of the fields are required. Remember, flagging the optional fields is the opposite of what many users are accustomed to. This means users may misunderstand which fields are required. Be sure to precede the inputs with a message such as “All fields are required, unless they are marked optional.”

    four input fields, 3 marked with a red asterisk in the label and a legend that says '* indicates required fields'

    Indicate required fields in an accessible way, such as including a red asterisk in the label. Be sure to provide a legend as well.

    four input fields, one marked with '(optional)' in label and a legend that says 'All fields are required, except where marked (optional)'

    When only optional fields are labeled, provide a legend that says 'all fields are required, except where marked 'optional'

    Resources

    Requirements

    Related toolkit topics

Level 2

Incorporate accessible instructions

  • What to do

    Frequently, instructional text may surround a form region. There may be general advice on providing brief or detailed responses. There may be information for outliers, such as instructions for someone who does not have a requested identity card. Content designers should become aware of the different ways this context can be surfaced appropriately to users with disabilities.

    Resources

    Requirements

  • What to do

    Sometimes input fields require data entry in a particular format, such as an 8-digit date or a complex password. When an input requires a specific format, provide instructions and optionally, an example that demonstrates that input format. Doing so will prevent the frustration of submitting information only to find out it wasn’t in the correct format.

    Instructions for user input can pose several challenges to persons with disabilities. Screen reader users typically navigate directly between form inputs. They will only hear instructions (and labels) directly associated with the inputs. Users with cognitive disabilities need specific guidance located near the input field, which reduces the amount of short-term memory required to recall and act upon the instructions. Finally, if instructions are not located near to the input, low vision users won’t see instructions because they aren’t within the magnified viewport. Where possible, locate instructions in a consistent location near the inputs, and mark the association with an input in the wireframe so that developers can programmatically capture the relationship.

    Birth date input field followed by 'MM/DD/YYYY' and Password input field followed by 'Password must have at least eight characters'

    Provide instructions when a specific format is required.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    When describing an interactive component, be sure to include its label in the instructions. Often instructions use sensory characteristics to describe elements in the content, such as the visual appearance (“green button”), spatial location (“right side”) or sound (“three beeps”). This is a useful way of contextualizing the instructions.

    However, someone who is blind or visually impaired may not be able to locate elements only described visually; a deaf person cannot hear beeps. While sensory language can be helpful to someone with a cognitive disability, be sure instructions don’t rely on a single sense for the description. The easiest way to do that is to always include the label or name of a component. Instead of “green button” say “green Submit button”. Instead of “right side” say “Profile menu on the right side.” That way all users can benefit from the instructions.

    Next button with text 'Click the blue Next button to go onto the next topic'

    Provide instructions that include the label or name of the component.

    Next button with text 'Click the blue button to go onto the next topic'

    Don't provide instructions that only use sensory characteristics.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    A current trend is to use placeholder text in input fields as a substitute for a label, example, or description. The influence came from mobile design, to save space by avoiding a label above or beside the input field. However, placeholders pose a variety of accessibility issues.

    Placeholder text disappears when the user starts typing, thus removing any guidance they provide. This increases the mental effort of form entry, a particular problem for users with cognitive disabilities. These users often have difficulty remembering the instructions as they attempt to complete the input. When users scan a form to verify all the input is correct, it becomes much more difficult to verify. When in doubt, one must delete the entry to re-display the placeholder text.

    Improper use of placeholders also affects people who have low vision or are blind. Many browsers display placeholder text below minimum contrast requirements, making it difficult to read. For some poorly implemented custom elements, placeholders disappear when focus moves to the input field, or get appended as text to what the user types. In addition, some screen readers don’t announce the placeholder as a label or description for the input.

    Avoid using placeholder text whenever there is a need for persistent guidance for users. Place important instructions near the input field instead of as a placeholder. If placeholders are used, consider ways to make the placeholder text still visible when the user enters text, such as using a float label. Ensure you meet minimum contrast.

    a populated 'passport number' input with instructions, followed by an active but empty 'passport expiry date' input with instructions on date formatting

    Keep labels and important instructions visible so user guidance is consistent.

    two input fields with no labels, one filled out with numbers, and the other with placeholder text 'passport expiry date MM/DD/YYYY'

    Don't use placeholders in place of labels or critical instructions.

    Resources

    Requirements

    Related toolkit topics

  • What to do

    While the Web Content Accessbility Guidelines (WCAG) don’t require the documenting of accessibility features, other worldwide accessibility standards do. The goal is to make it easy for users with disabilities to understand the accessibility features and workarounds available to them.

    If you have any of the following, they need to be documented:

    • Keyboard interaction for custom components that don’t have standard interactions
    • Shortcut keys unique to your content, including shortcuts to operate video players
    • Accessibility settings provided, such as font size, color, and contrast
    • How to configure assistive technology to work with the content
    • Limitations, workarounds, and alternative accessible content for assistive technology users, if known
    • Authoring tool capabilities for making authored content accessible

    The accessibility documentation can be inline, context-specific, available as separate documentation, or a combination of all three.

    Resources

    Requirements

    Related toolkit topics

Level 3

Indicate the purpose of common inputs

  • What to do

    Refer to requirements listed below.

    Requirements