Input

The input component provides styled form controls for text entry, numbers, and other data input types. Use inputs to collect user information in forms, search interfaces, and interactive applications. The component supports various input types, validation states, error handling, and accessibility features to ensure a consistent and usable form experience across all GNWT applications.

Do

  • Use appropriate input types for the data being collected (text, email, number, tel, etc.) to enable proper validation and mobile keyboards.
  • Provide clear, descriptive labels that explain what information is expected from users.
  • Include helpful description text when users might need additional context or formatting guidance.
  • Use required field indicators consistently across your forms to set clear expectations.
  • Implement proper error messaging that explains what went wrong and how to fix it.
  • Use consistent spacing and sizing to maintain visual hierarchy and form flow.
  • Include validation attributes (min, max, step, pattern) to provide immediate feedback to users.

Don't

  • Don't use placeholder text as labels — placeholders disappear when users start typing and aren't accessible to all users.
  • Don't make input fields too narrow — ensure adequate space for typical content without horizontal scrolling.
  • Don't use generic error messages — provide specific, actionable feedback that helps users correct their input.
  • Don't forget mobile considerations — test input behavior on touch devices and various screen sizes.
  • Don't overuse required fields — only mark fields as required when truly necessary for the process.
  • Don't ignore input formatting — provide clear examples or auto-formatting for complex data like phone numbers.
  • Don't make forms unnecessarily long — group related inputs and consider multi-step approaches for complex forms.

Text Input Optional

Standard text input field for optional information collection. Demonstrates proper labeling, description text, and form structure for non-required fields. Use this pattern for supplementary information that enhances the user experience but isn't critical for form submission.

Enter your current home address. Do not use a P.O. Box unless it is your only mailing address.
Open example in a new tab

Text Input Required with Error

Required text input showing error validation state. Demonstrates proper error messaging, visual indicators, and accessibility attributes for form validation. Use this pattern when user input is mandatory and validation has failed, providing clear guidance for correction.

Enter your name as it appears on official documents
Open example in a new tab

Height Input

Specialized numeric input group for collecting height measurements. Shows how to combine multiple related inputs (feet and inches) within a fieldset with proper labeling and validation. Use this pattern for complex data entry that requires multiple related values.

feet
inches
Open example in a new tab

Accessibility Best Practices

Input demonstrating comprehensive accessibility implementation with proper ARIA attributes, semantic markup, and keyboard navigation support. Shows how to structure form inputs for optimal screen reader experience and keyboard accessibility.

Screen Reader Support

  • Descriptive labels: Each input has a clear, specific label that describes the expected content.
  • Avoid tooltips for form guidance: Do not use tooltips to convey essential instructions or requirements. Tooltips are not consistently discoverable by keyboard and screen reader users. Use visible description text associated with the input.
  • Required field indication: Required inputs are properly marked with required attribute and visual indicators.
  • Error announcements: Invalid inputs include aria-invalid and connect to error messages for screen reader users.

Keyboard Navigation

  • Full keyboard access: All inputs are accessible via Tab key navigation and standard keyboard interactions.
  • Logical tab order: Form inputs follow natural reading order and logical completion sequence.
  • Focus indicators: Clear visual focus states help keyboard users identify their current position.
  • Validation on blur: Input validation occurs when users leave fields, providing immediate feedback.

Visual Accessibility

  • High contrast ratios: All input text, labels, and borders meet WCAG AA contrast requirements.
  • Clear error states: Invalid inputs use multiple visual cues (color, icons, borders) to indicate problems.
  • Adequate sizing: Input fields meet minimum touch target sizes (44px) for mobile accessibility.
  • Consistent styling: All input states (default, focus, error, disabled) are visually distinct and predictable.

Content Guidelines

  • Clear label text: Use specific, descriptive labels that explain exactly what information is needed.
  • Helpful descriptions: Provide additional context when input format or requirements might be unclear.
  • Specific error messages: Write error text that explains the problem and suggests how to fix it.
  • Consistent terminology: Use the same words for similar concepts across all forms and inputs.

Implementation Considerations

  • Form validation: Implement both client-side and server-side validation for security and user experience.
  • Input masking: Consider auto-formatting for structured data like phone numbers, dates, or postal codes.
  • Progressive enhancement: Ensure forms work without JavaScript while providing enhanced experiences when available.
  • Performance: Avoid excessive validation requests that could slow down form completion.

ARIA Attributes in Use

  • aria-describedby — Connects inputs to help text and error messages for screen reader context.
  • aria-invalid="true" — Indicates when input validation has failed.
  • aria-required="true" — Identifies required fields for screen reader users.
  • role="alert" — Applied to error messages to ensure they’re announced immediately when they appear.
Updated: Jan 27, 2026