In the App I designed, there is a component that can be swiped horizontally, but the accessibility team said that the functionality is not operable using a single pointer and without requiring a specific path/gesture.

Their requirement: Where functionality is provided through gesture-based or multitouch controls, ensure that an alternative is available which does not require the user to perform a path-based gesture, and which can be operated using a single pointer. Provide accessible "Previous" and "next" buttons or carousel thumbnail tabs to focus and select.

The rule is from WCAG SC 2.5.1:Pointer Gestures

But I don't want to add a button to this area, which increases the complexity of the interface and seems redundant. I checked a lot of the world's popular products, and similar components also exist. I'm wondering do these products solve this accessibility issue? Any elegant and less-prominent way to solve the issue in my app?

Chrome,Google search Google App-homepage
Original image link Original image link

2 Answers 2


If it's needed for accessibility, it's better to implement either the auto scrolling animation or pointers, indicating that the carousel is scrollable. If you've decided to go with the pointers, I'd highly suggest to use pointers inside the carousel, not at the top of the section, as in your demo the pointer could be understood as opening the section, not sliding the images inside carousel. I've provided an example below.

enter image description here

  • Auto scrolling animations are generally not good for accessibility, so probably not that.
    – exp
    Jan 5 at 8:36
  • Could you elaborate on why scrolling carousel is not good for accessibility? I only managed to find that the content might scroll too quickly and users might find it difficult to read, but then again - the speed could be lowered a lot and it could play a role as an indicator that the carousel can be scrolled.
    – fakermaker
    Jan 5 at 9:11
  • 1
    Sure. It comes down to anything that has time restrictions should be avoided (WCAG 2.1, §2.2 in general and §2.2.3 in particular) as well as movement animations should have extra controls with the ability to pause, stop, restart, etc (WCAG 2.1, §2.2.2)
    – exp
    Jan 5 at 9:24
  • Just curious about the pictures of mainstream products posted in the original post, and their horizontal scrolling only provides a sliding way. Do they meet the accessibility requirements?
    – Ph X
    Jan 8 at 9:45

Please don't neglect accessibility, it's much more important that you'd think.

There's this whole section about carousels on APG that, of course, suggests you have to add buttons for both "next" and "previous" buttons among other suggestions.

Features needed to provide sufficient rotation control include:

  • Buttons for displaying the previous and next slides.
  • Optionally, a control, or group of controls, for choosing a specific slide to display. For example, slide picker controls can be marked up as tabs in a tablist with the slide represented by a tabpanel element.
  • If the carousel can automatically rotate, it also:
    • Has a button for stopping and restarting rotation. This is particularly important for supporting assistive technologies operating in a mode that does not move either keyboard focus or the mouse.
    • Stops rotating when keyboard focus enters the carousel. It does not restart unless the user explicitly requests it to do so.
    • Stops rotating whenever the mouse is hovering over the carousel.

The NNG article about carousels on mobile suggests that it might not be a good idea to use carousels on mobile at all, since it introduces multiple problems:

The temptation to use a carousel to save space on a small screen can be big, yet carousel items can have little discoverability, especially when not advertised well with strong cues such as the illusion of continuity or arrows. If you end up with a carousel on your mobile site or in your mobile app, make sure that it doesn’t have an excessive number of elements and that it supports swipe.

Now on mobile, where interaction are widely gestures-based, the OS is usually taking care of making sure basic gestures are accessible and give you tools to let you make sure you implement necessary functionality. There's a whole section on accessible gestures in Apple's Human Interface Design guidelines. Pay attention to this part:

When possible, make your app’s core functionality accessible through more than one type of physical interaction

In conclusion, please find a way to comply with WCAG and APG guidelines. It's very important. It doesn't have to clutter you UI or make it uglier.

Here are some ok examples from the same apps you've mentioned above:

  • AirBnB (web version):

AirBnB category selector carousel with the button

  • Bing:

Bing news carousel with navigation buttons

  • Instagram (web version):

Instagram stories with navigation buttons

  • Just curious about the pictures of mainstream products posted in the original post, and their horizontal scrolling only provides a sliding way. Do they meet the accessibility requirements?
    – Ph X
    Jan 8 at 9:45
  • Doesn't seem like it, if you check them against "WCAG SC 2.5.1:Pointer Gestures" and the APG guidelines. But, again, maybe they should be checked while the assistive technologies on the device are on. I'm pretty sure, those enable additional features.
    – exp
    Jan 8 at 10:54
  • Thank you. I'll check that later. By the way, do you mean that if the assistive technology is turned on and the corresponding function is provided, then this one can be considered as passed, right? It is no need to provide corresponding functions in the default situation?
    – Ph X
    Jan 8 at 15:50
  • I mean it needs to be checked, but i think that might be how they view it
    – exp
    Jan 8 at 15:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.