Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve accessibility of the autoplay setting #13

Closed
2 tasks done
jasonwebb opened this issue Aug 16, 2020 · 1 comment
Closed
2 tasks done

Improve accessibility of the autoplay setting #13

jasonwebb opened this issue Aug 16, 2020 · 1 comment
Labels
feature change Change to an existing feature or functionality

Comments

@jasonwebb
Copy link

jasonwebb commented Aug 16, 2020

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:

  1. 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.
  2. 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.
@jasonwebb jasonwebb added the feature change Change to an existing feature or functionality label Aug 16, 2020
jasonwebb added a commit that referenced this issue Aug 26, 2020
@jasonwebb
Copy link
Author

jasonwebb commented Aug 27, 2020

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.

Updated font files were added in a977853.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature change Change to an existing feature or functionality
Projects
None yet
Development

No branches or pull requests

1 participant