Accessible Carousel (non-rotating)
Visual is kept minimal, enough to see what's going on. This example concentrates on the functionality of the buttons and sections, and the DOM order layout, with the aim to present a robust, understandable, and operable interface to assistive technologies such as screen-readers.
The currently selected carousel slide dictates the content which appears beneath, more like a tab control but without needing arrow keys to navigate.
Example
Debit card content
Fake test link ACredit card content
Fake test link BSavings card content
Fake test link CFeatures
- Controls appear before the content in the keychain. The dot indicators are also buttons, and appear before the left and right buttons. This order, I'm led to believe, is the best for screen-readers, even though it breaks focus order guidance.
- Semantic HTML: The HTML structure utilises semantic elements such as <div>, <button>, and appropriate ARIA roles (role="region", role="group", etc.), which help convey the structure and purpose of the content to assistive technologies. This supports WCAG Success Criteria 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).
- ARIA attributes: ARIA attributes such as aria-label, aria-roledescription, aria-controls, and aria-labelledby are used to provide additional context and association between elements, enhancing accessibility for screen reader users. This aligns with WCAG Success Criteria 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).
- Hidden content: Content that is not currently visible (e.g., hidden slides and content sections) is marked as hidden using the hidden attribute. This ensures that screen reader users are not presented with irrelevant or redundant information, supporting WCAG Success Criteria 1.3.1 (Info and Relationships) and 4.1.2 (Name, Role, Value).
- Live region: A live region (live-region) with aria-live="polite" is included to announce dynamic updates, such as changes in slide content. This ensures that screen reader users are informed of important changes without requiring manual interaction, supporting WCAG Success Criteria 4.1.3 (Status Messages) and 4.1.4 (Live Regions).
- Keyboard accessibility supporting WCAG Success Criteria 2.1.1 (Keyboard) and 2.1.2 (No Keyboard Trap).