Contributing Accessibility Guide

This guide defines minimum accessibility expectations for all contributions.

Scope

Applies to:

• UI components
• Content and documentation with interactive examples
• Visualizations and diagrams
• Forms and workflows

Before Opening a PR

• Read ACCESSIBILITY-template.md and project-specific guidance in this repository.
• Review component references in the examples/ directory.
• Ensure your changes do not introduce new accessibility regressions.

Required Checks

Contributors must pass:

1. Local accessibility checks (lint/tests) before commit.
2. Pre-commit accessibility checks where configured.
3. PR CI accessibility checks.

See:

• Shift-Left Accessibility Automation
• A11Y Shift-Left Workflow

Definition of Done (A11y)

A change is complete only when:

• Keyboard access is verified.
• Focus behavior is visible and logical.
• Form labels, errors, and status messages are accessible.
• Automated checks pass.
• Any known exception is documented with owner and expiry.

Severity and Escalation

• Critical and High accessibility defects should block merge.
• Medium and Low issues require documented follow-up in tracked issues.

PR Checklist (Suggested)

• Keyboard-only interaction tested
• Screen reader behavior spot-checked for changed flows
• Color/contrast requirements reviewed
• Relevant docs in examples/ updated
• No broken links in Markdown docs

Related References

• Keyboard Accessibility Best Practices
• Forms Accessibility Best Practices
• SVG Accessibility Best Practices
• Mermaid Accessibility Best Practices