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

Deprecate focusOnChange and focusOnSelect settings #11

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

Deprecate focusOnChange and focusOnSelect settings #11

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

Per WCAG 3.2.2, keyboard focus should not be moved automatically when a user interacts with a UI component (like a prev/next button or slide dot button) unless they have been informed of this behavior ahead of time.

To fulfill the criteria we could add some warning text to tell users about this behavior ahead of time, but this text would need to be visible to be effective for sighted / low-vision keyboard-only and screen reader users. This would annoy a lot of designers, and could be considered a breaking change that would make this package undesirable for real teams, so that doesn't seem like the way to go.

From a usability perspective, real users would not expect their focus to be forcefully moved onto non-actionable elements anyway, so the best solution here is really to eliminate this behavior altogether.

It is critical that these settings are not deprecated in a way that breaks existing configurations. Be sure to thoroughly test that configs that pass these settings in via the init method or data attributes do not cause any errors. Instead they should just be silently ignored.

  • Remove all functionality associated with these two settings in the JavaScript without introducing any breaking changes. In other words, if an existing config is passing in these values they should just be ignored, not cause the slider to break.
  • Consider emitting a console.warn or console.info message if the option has been passed in an existing config to let devs know that this functionality has changed.
  • Add documentation about these changes to the main README.
@losmurfs
Copy link

losmurfs commented Aug 9, 2023

So, as a blind user, after I activate "Next" how do I then have my screen reader read the alt attribute of the img that is now being displayed. Before interacting with "Previous", "Next" or "Pause" I can up arrow and down arrow to get to an img but after interacting with "Next" a/img become invisible to the screen reader and the keyboard navigation. Is there a special "read slide" command? and a special "follow slide navigation" command?

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

2 participants