You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Typically people try to resolve these inherent UX issues by either forcing keyboard focus to move to slides when they come up (see #11) or turning the carousel into an ARIA live region that automatically announces content when slides change, but both of the approaches tend to make things worse for users with disabilities, not better. Here are some reasons why:
Keyboard users rely heavily on their ability to control and track their focus position at all times, so their focus should be considered sacrosanct. Forcefully moving it is usually a very disruptive experience for them, especially when they aren't expecting it. WCAG 3.2.1, 3.2.2, and 3.2.5 all make it clear that keyboard focus should never be moved except in very specific use cases, which carousels don't quite qualify for.
ARIA live regions force screen readers to read out content even if the user is in a completely different part of the page, so they should only be used in very rare situations, and generally only announce very clear, succinct messages. Making the carousel a live region will mean that screen reader users will be overwhelmed with content no matter where they are on the page, and probably won't even finish hearing an entire slide before the next slide comes in and starts being read out. Users will not know where these announcements are coming from or why they are getting them, and therefore have no idea how to make them stop. These constant announcements can make the entire page impossible to use, so a screen reader user is very likely to just leave your site and never come back.
By far the best solution to these issues is to just not have autoplay functionality at all. Unfortunately, that tends to not be practical in the real world because of the mistaken views that many leadership and marketing teams have about the efficacy of autoplay carousels.
Per WCAG 2.2.2, all auto-updating content on a page that lasts more than 5 seconds must have a mechanism for pausing, stopping, or hiding it. Therefore in order to be accessible, the autoplay setting must automatically come with a pause or stop button. Think of this like the previous/next buttons - they automatically show up by default when they are needed.
It might be a good idea to expose a new setting (like hideAutoplayPauseButton) that people can use to explicitly disable this functionality, but this should probably come with documentation and a console warning informing them of the WCAG violation.
Automatically add pause/play icon button as the first child of the slider when autoplay is enabled.
Document the change in the main README.
The text was updated successfully, but these errors were encountered:
Using fontastic.me, I created new font files that include the pause and play icons from FontAwesome 5.0, mapped to the Unicode ⏸ and ▶ characters respectively.
Autoplay functionality is pretty distracting for most users, and its a downright experience breaker for screen reader users.
Typically people try to resolve these inherent UX issues by either forcing keyboard focus to move to slides when they come up (see #11) or turning the carousel into an ARIA live region that automatically announces content when slides change, but both of the approaches tend to make things worse for users with disabilities, not better. Here are some reasons why:
By far the best solution to these issues is to just not have autoplay functionality at all. Unfortunately, that tends to not be practical in the real world because of the mistaken views that many leadership and marketing teams have about the efficacy of autoplay carousels.
Per WCAG 2.2.2, all auto-updating content on a page that lasts more than 5 seconds must have a mechanism for pausing, stopping, or hiding it. Therefore in order to be accessible, the autoplay setting must automatically come with a pause or stop button. Think of this like the previous/next buttons - they automatically show up by default when they are needed.
It might be a good idea to expose a new setting (like
hideAutoplayPauseButton
) that people can use to explicitly disable this functionality, but this should probably come with documentation and a console warning informing them of the WCAG violation.The text was updated successfully, but these errors were encountered: