Refine By

Carousel

  • Contents:
  • Carousels are used for presenting a sequence of content one slide at a time.
  • They can be embedded within a page or launched as a modal.

Guidelines

 

  • Do not overload carousels with too many slides. A general recommendation for non-image gallery carousels on web is a total of 6 slides.
  • Clearly indicate how many slides are in a carousel.
  • Always give the user control over navigating a carousel.
  • Ensure carousel controls are always visible to the user.

Style

 

 

 

 

 

 

 

 

 

 

 

Accessibility

 

 

 

Requirements for Automated Accessibility Testing: (to include what needs to be done to pass automated testing)
1. Put the user in control. If a carousel auto-rotates, make sure there’s a way for the user to stop or pause it. Make sure that users can navigate between slides using only the keyboard.
2. Provide more than one way for users to understand which slide they are viewing. For example. when a series of “dots” is used to show that there are five slides and the second is shaded to show the user is viewing the second of five slides, be sure that “2/5” also is visible.
3. Color contrast: Minimum color contrast must be met for all elements layered over the carousel, including next/previous arrows, CTAs, text over images, captions, etc.
4. Make sure that each image has an alt attribute.
5. Make sure that you can zoom the browser to 200% without losing any functionality of the carousel. If the design is responsive, this will trigger the mobile view, which is fine as long as all of the interactive elements can still be used.

Requirements for Manual Accessibility Requirements:
1. Validating Keyboard Accessibility (Using the desktop and keyboard only without a screen reader active):
a. Tabbing: Make sure that each “control” for the carousel can be reached with the tab key: This includes the buttons to move to the next and previous slides, the “dots” or other visual cues of how many slides are available (if a user can “click” on a dot to go to that slide, that “dot” must also be able to be activated from the keyboard). Similarly, if there is a full screen or other option to enlarge the image, this control must also be able to be tabbed to.
b. Visible focus: When tabbing to the carousel controls, make sure there is a visible focus indicator that shows what has focus. Visible focus varies by browser.
c. Keyboard selection of interactive elements: Make sure that you can use the spacebar or enter key to activate buttons and the enter key to activate elements that are links.
d. Focus states: If any effect or additional information is provided when a user hovers over an element, make sure that the same information is provided when the image receives keyboard focus.
e. Access to links (if present): If the information presented in the carousel includes links to related site content, ensure that those links can receive keyboard focus and can be activated using the enter key.
2. Validating Screen Reader Accessibility (Using the desktop with a screen reader turned on):
a. Make sure that you can tab to each of the controls and that the screen reader friendly text indicates what the control is for – example, “Go to next slide,” “Go to previous slide,” or “Enlarge image” (if applicable). If the user can select from a series of dots or other visual indicators of the number of slides, when each receives focus, make sure that it is announced – example: “slide 2 of 5” or “slide 3 of 3.”
b. Make sure that you can interact with the information within the slides as well:
– When an individual slide has a caption, use the down arrow key to make sure that you hear the screen reader friendly text and the caption text.
– When an individual slide contains headings, subhedings anc a CTA, use the down arrow key to make sure that you hear the screen reader friendly text, the heading, the subheading, and the CTA information.

Resources:
1. For a demonstration of the expected keyboard interaction and screen reader functionality, please see: http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wizards/Carousel%20(Flat%20from%20XML)/demo.htm
2. The Anatomy of an Accessible Carousel: http://www.accessiq.org/create/content/anatomy-of-an-accessible-carousel
3. On using ARIA to improve the accessibility of carousel elements: http://accessibility.athena-ict.com/aria/examples/carousel.shtml

Examples Implemented on OHW/Global Web
1. https://jira.hilton.com/browse/NHCRES-131

Requirements for Automated Accessibility Testing: (to include what needs to be done to pass automated testing)

  1. Put the user in control. If a carousel auto-rotates, make sure there’s a way for the user to stop or pause it. Make sure that users can navigate between slides.
  2. Provide more than one way for users to understand which slide they are viewing. For example. when a series of “dots” is used to show that there are five slides and the second is shaded to show the user is viewing the second of five slides, be sure that “2/5” also is visible.
  3. Color contrast: Minimum color contrast must be met for all elements layered over the carousel, including next/previous arrows, CTAs, text over images, captions, etc.
  4. Make sure that each image has an alt attribute.
  5. Make sure that you can pinch to zoom the view size to 200% without losing any functionality of the carousel.

 

 

Requirements for Manual Accessibility Testing:

  1. Validating Screen Reader Accessibility (Using a mobile device or iPad with with screen reader turned on – VoiceOver for iOS, Talkback for Android phones):
  2. Make sure that you can swipe to each of the controls and that the screen reader friendly text indicates what the control is for – example, “Go to next slide,” “Go to previous slide,” or “enlarge image” (if applicable). If the user can select from a series of dots or other visual indicators of the number of slides, when each receives focus, make sure that it is announced – example: “slide 2 of 5” or “slide 3 of 3.”
  3. Make sure that each of the controls can be activated by double tapping. For example, if there are three images in the carousel and they are indicated by three bars under the image, tap once on the middle bar, and make sure you hear something like “Select image 2 of 3” then double tap on the image and make sure the slide changes.
  4. Make sure that you can interact with the information within the slides as well:
  • Listen and make sure that you hear the images alternative text read.
  • If a slide has a caption, swipe down to make sure that you hear the image alt text text and the caption text.
  • If a slide contains headings, subheadings and a CTA, swipe down to make sure that you hear the alt text, the heading, the subheading, and the CTA information.

 

 

 

Resources:

  1. For a demonstration of the expected keyboard interaction and screen reader functionality, please see: http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wizards/Carousel%20(Flat%20from%20XML)/demo.htm
  2. The Anatomy of an Accessible Carousel: http://www.accessiq.org/create/content/anatomy-of-an-accessible-carousel
  3. On using ARIA to improve the accessibility of carousel elements: http://accessibility.athena-ict.com/aria/examples/carousel.shtml

 

Examples Implemented on OHW/Global Web

  1. https://jira.hilton.com/browse/NHCRES-131

 

 

Process for Manual Accessibility Testing

On an Android phone with TalkBack or an iPhone or iPad with VoiceOver active:

  1. Make sure that each image has an alt attribute. Swipe to each image, and listen to hear the screen reader read the text for each image on the full “gallery” view.
  2. When you swipe to each image on the gallery view, make sure that you see the corresponding focus outline. Both TalkBack and VoiceOver will show an outline around the content as it is read.
  3. In the gallery view, make sure that the screen reader indicates the image is interactive and will open a new view. TalkBack or VoiceOver should say “button” or “link” along with the alternative text.
  4. On the “detail” view, the user should be able to swipe to the “X” to close the window (and hear something like “close” or “cancel”). They should also be able to swipe to the image info (like “1 of 18”) and the gallery icon. Make sure the screen reader explains what the icon is for. The user should also be able to swipe to the image to hear the alternative text and to the text below. Again, make sure that you see the corresponding focus outline – both TalkBack and VoiceOver will show an outline around the content as it is read.

 

Resources:

  1. To check the accessibility of Android apps, developers can use the Accessibility Scanner from Google: https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditor
  2. To check the accessibility of elements within iOS apps, developers can use the Accessibility Inspector from Apple: https://developer.apple.com/library/content/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityiniOSSimulatorwithAccessibilityInspector/TestAccessibilityiniOSSimulatorwithAccessibilityInspector.html

 

Related Elements

Version History

Date/Time of ChangeWho Made the ChangeChange Details
Mar. 30 2018 8:41pm Updated accessibility testing notes to account for iOS/Android