Document submit button behavior: avoid disabling submit for form validation

[asuwebdesign]

Summary

PatternFly documentation currently shows inconsistent submit button behavior during form validation. This proposal recommends adding guidance that submit buttons should not be disabled solely for validation purposes, and documenting accessible, predictable alternatives.

This is a documentation recommendation, not a breaking change or hard requirement.

Current State

Across PatternFly examples and downstream implementations:

• Some forms disable submit buttons until required fields are complete
• Others allow submission and show validation errors afterward

Without guidance, teams frequently default to disabling the primary action, resulting in inconsistent behavior and avoidable accessibility issues.

Proposed Documentation Guidance

1. Recommendation

Do not disable submit buttons solely to enforce validation.

Instead:

• Keep the submit button visible and enabled
• Allow submission attempts
• Provide clear, field-level validation feedback

2. Accessibility Rationale

According to W3C WAI guidance:

• Disabled controls may be skipped or poorly announced by assistive technologies
• Keyboard users may lose awareness of available actions
• Screen readers often do not convey why a control is disabled

Allowing submission ensures validation requirements are discoverable and announced.

3. Usability Rationale

Industry research and guidance (Nielsen Norman Group, GOV.UK) show that:

• Users expect to attempt submission and be informed what needs correction
• Disabled primary actions hide system rules and increase cognitive load
• Always-visible submit buttons preserve affordance and layout stability

4. Recommended Pattern

• Submit button remains enabled
• On submit:
  • Focus moves to the first invalid field
  • Inline error messages explain what is required
  • aria-invalid and aria-describedby are applied

5. Explicit Exceptions

Disabling a submit button may still be appropriate when:

• Preventing duplicate submissions during async processing
• A destructive action requires explicit confirmation
• System state (not user input) makes submission impossible

These cases should be documented as exceptions, not defaults.

Why This Matters

• Accessibility: Improves screen reader and keyboard usability
• Predictability: Matches user expectations across platforms
• Consistency: Reduces divergent patterns across PatternFly examples

Anticipated Concerns & Clarifications

• This is guidance, not a mandate
• Client-side validation is still supported
• This aligns with GOV.UK, Material Design, and Nielsen Norman Group guidance

Acceptance Criteria

• Add submit button behavior guidance to Forms documentation
• Include do/don’t examples
• Clarify default behavior vs documented exceptions
• Align examples across PatternFly form components

Closing

Disabling submit buttons for validation is a common but avoidable source of friction. Clear guidance here would help product teams using PatternFly deliver more accessible, predictable, and human-centered forms.