Accessibility: Forms

Guidelines for accessible web forms reflect general content guidelines, but the instructions for applying these recommendations are unique to interactive input fields, buttons, and user submissions.

In this page:

1. Form Labels and Associations
2. Grouping Related Fields
3. Keyboard Navigation and Focus Order
4. Error Identification and Validation
5. Placeholders, Date Formatting, and Helper Text
6. Accessible Submit Buttons and Actions
7. Color Contrast and Visual Indicators
8. Marking Required Fields

---

1. Form Labels and Associations

Every input field, checkbox, radio button, and dropdown must have an explicit, programmatically associated text label so screen readers can announce what information is expected.

• Use native <label> elements: Connect labels directly to inputs using the for attribute matching the input’s unique id (e.g., <label for="first-name">First Name</label><input id="first-name" type="text">).
• Wrap inputs inside labels (alternative): Alternatively, you can nest the input element directly inside the <label> tag for seamless association.
• Avoid orphan labels: Never rely on visual proximity alone (like placing static text next to a box); screen readers will not associate unlinked text with the input field.
• Use aria-label or aria-labelledby when visible labels are absent: If design constraints require a field to have no visible label (such as a standalone search bar), assign an explicit aria-label="Search HCU website" directly to the input element.

---

2. Grouping Related Fields

When presenting a series of related options—such as multiple checkboxes or radio button groups—screen readers need context to understand how the individual choices relate to the overall question.

• Use <fieldset> and <legend>: Wrap related form controls in a <fieldset> container, and use the <legend> element to state the overarching question or category (e.g., “Select your preferred contact method:”).
• Keep legends descriptive: Ensure the legend clearly explains the grouping so screen reader users hear the context before encountering each individual choice.

---

3. Keyboard Navigation and Focus Order

Many users navigate forms entirely via the keyboard using the Tab key rather than a mouse or trackpad.

• Maintain a logical DOM tab order: The sequence of interactive elements in your HTML code must match the visual top-to-bottom, left-to-right flow of the page.
• Provide clear focus indicators: Ensure all active form elements display a highly visible outline or background shift when focused via keyboard navigation. Never use CSS rules like outline: none; unless you replace it with an accessible custom focus style.
• Avoid positive tabindex values: Do not use tabindex="1" or higher, as this disrupts the natural reading and navigation order; rely on natural DOM ordering and use tabindex="0" only when necessary to make custom interactive elements focusable.

---

4. Error Identification and Validation

When form validation fails, users must be immediately alerted to the exact nature of the error and how to correct it.

• Provide clear error text: Avoid vague warnings like “Invalid submission.” Instead, explain precisely what went wrong (e.g., “Please enter a valid HCU email address ending in @hc.edu”).
• Do not rely on color alone: Never use a red border or red text as the sole indicator of an error; pair color changes with text messages and error icons.
• Connect error messages to inputs: Use aria-describedby="email-error" on the input field so screen readers automatically announce the error message when the field receives focus.
• Programmatically manage focus: Upon submission failure, automatically shift keyboard focus to the error summary box or the first invalid form field so users do not have to hunt for the mistake.

---

5. Placeholders, Date Formatting, and Helper Text

Placeholder text provides temporary example input inside a form field, but it should never replace a permanent label. Additionally, choosing accessible input types for complex data (like dates) is critical for accessibility.

• Avoid date picker dropdowns: Do not force users to scroll through extensive select/dropdown menus or complex graphical calendar widgets to choose a date (such as month, day, and year dropdowns for Date of Birth). Instead, use simple text input fields (or split text inputs for MM, DD, and YYYY).
• Provide clear date format instructions: Always display the required format explicitly next to or below the label (e.g., “Date of Birth (MM/DD/YYYY)”). Connect this instruction to the input using aria-describedby.
• Never use placeholders as labels: Placeholder text disappears the moment a user begins typing, which causes severe memory and cognitive barriers for users relying on screen readers or those with short-term memory impairments.
• Use placeholders strictly for supplementary examples: Reserve placeholder text for formatting hints (e.g., placeholder="e.g., 05/14/1990") rather than core instructions.
• Use persistent helper text: For instructions that must remain visible while filling out a field (such as password strength requirements or date format instructions), place the text outside the input and link it using aria-describedby.

---

6. Accessible Submit Buttons and Actions

Form action buttons trigger submissions or data resets, and they must be fully accessible to screen readers and keyboard users.

• Use native button elements: Code submit and reset actions using native <button type="submit"> or <input type="submit"> tags rather than styled generic <div> or <span> elements.
• Use clear button text: Ensure button labels describe the exact action (e.g., “Submit Application” or “Send Message” instead of generic terms like “Click Here” or “Go”).
• Ensure large touch targets: Design buttons with a minimum interactive target size of 44×44 pixels to accommodate mobile users and individuals with motor tremors.

---

7. Color Contrast and Visual Indicators

All text, form boundaries, and interactive controls must meet strict contrast standards so users with low vision can easily perceive them.

• Meet contrast minimums: Ensure form field borders and text maintain a contrast ratio of at least 4.5:1 against their background.
• Ensure clear field boundaries: Form input boxes must have a defined border or high-contrast background so users can easily distinguish active input areas from surrounding white space.
• Follow HCU brand guidelines: Stick to approved HCU Brand colors when styling interactive elements and buttons.

---

8. Marking Required Fields

Screen reader users and visual users alike need immediate clarity on which fields are mandatory before attempting submission.

• Indicate required fields visually and textually: Include a clear indicator (such as an asterisk with a legend or the word “Required”) next to mandatory form labels.
• Use the aria-required attribute: Programmatically identify mandatory fields in the underlying code by adding aria-required="true" (or the native required attribute) so screen readers explicitly announce “required” when the field is reached.