Accessibility considerations
No accessibility annotations are needed for date pickers, but keep these considerations in mind if you are modifying Carbon or creating a custom component.
The date picker labels should clearly describe the dates that the user needs to input, such as arrival date or departure date when making travel arrangements.
W3C WAI-ARIA Authoring Practices Date Picker Design Pattern covers the usage of ARIA names, state and roles, as well as the expected keyboard interactions.
IBM Accessibility Requirements:
1.3.1 Info and Relationships (WCAG Success Criteria 1.3.1)
1.3.2 Meaningful Sequence (WCAG Success Criteria 1.3.2)
2.1.1 Keyboard (WCAG Success Criteria 2.1.1)
2.1.2 No Keyboard Trap (WCAG Success Criteria 2.1.2)
2.4.3 Focus Order (WCAG Success Criteria 2.4.3)
2.4.6 Headings and Labels (WCAG Success Criteria 2.4.6)
2.4.7 Focus Visible (WCAG Success Criteria 2.4.7)
4.1.2 Name, Role, Value (WCAG Success Criteria 4.1.2)
Accessibility testing status
Latest version: 1.114.0 | Framework: React (@carbon/react)
| Component | Accessibility test | Status | Link to source code |
|---|---|---|---|
| Date Picker | Test(s) that ensure the initial render state of a component is accessible. | Passes all automated tests with no reported accessibility violations. | GitHub link |
| Tests that ensure additional states of the component are accessible. This could be interactive states of a component or its multiple variants. | Some tests are incomplete, in progress, invalid, or temporarily skipped. | ||
| Tests that ensure focus is properly managed, and all interactive functions of a component have a proper keyboard-accessible equivalent. | Passes all automated tests with no reported accessibility violations. | ||
| This manual testing ensures that the visual information on the screen is properly conveyed and read correctly by screen readers such as JAWS, VoiceOver, and NVDA. | A human has manually tested this component, e.g. screen reader testing. | ||
| Fluid Date Picker | Test(s) that ensure the initial render state of a component is accessible. | Passes all automated tests with no reported accessibility violations. | |
| Tests that ensure additional states of the component are accessible. This could be interactive states of a component or its multiple variants. | Passes all automated tests with no reported accessibility violations. | ||
| Tests that ensure focus is properly managed, and all interactive functions of a component have a proper keyboard-accessible equivalent. | Passes all automated tests with no reported accessibility violations. | ||
| This manual testing ensures that the visual information on the screen is properly conveyed and read correctly by screen readers such as JAWS, VoiceOver, and NVDA. | A human has manually tested this component, e.g. screen reader testing. |
Feedback
Help us improve by providing feedback, asking questions, requesting features, or leaving any other comments on GitHub.