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

Chosen.js and usability/accessibility #1109

Closed
jadudm opened this issue Jun 17, 2020 · 5 comments · Fixed by #1161
Closed

Chosen.js and usability/accessibility #1109

jadudm opened this issue Jun 17, 2020 · 5 comments · Fixed by #1161
Assignees
Labels

Comments

@jadudm
Copy link
Member

jadudm commented Jun 17, 2020

The chosen.js library was a significant stumbling point in front-end testing. It obscures/hides the original HTML select element, and replaces it with a javascript-y div. Doing some reading around the web, It is unclear from community discussions whether Chosen plays well with screenreaders (e.g. harvesthq/chosen#264, https://stackoverflow.com/questions/45936179/accessibility-jaws-dropdown-list-with-jquery-chosen-library).

Do we need it? Does it work against us (especially with regards to usability)? Should we consider pulling it from timecard.js/the time entry interface?

It certainly added complexity for testing.

@adunkman
Copy link
Member

I used to maintain Chosen for a period of time, and it’s an accessibility nightmare. It would require rewriting to fix, an investment that Harvest is unlikely to make (and is unlikely to accept a PR to take).

In cv_faq I used accessible-autocomplete and found it worked great and was accessible — it’s probably a nice path forward here as well.

@tbaxter-18f
Copy link
Contributor

Thank you @adunkman. My own experience with Chosen was also not good. At one point I was on a team that investigated forking it and trying to make some improvements, but the more we dug in the more we felt it was best to back away slowly and pretend we'd never looked under the hood. If we have a good, accessible alternative that provides the needed functionality, I'd definitely be open to switching.

@adunkman
Copy link
Member

the more we dug in the more we felt it was best to back away slowly and pretend we'd never looked under the hood

It was the same experience maintaining it! 😂 That project is a great demonstration of the value of automated testing… (or perhaps, the mess you’re in when you don’t have automated testing!).

Yay, learning. 😄

@jadudm
Copy link
Member Author

jadudm commented Jul 7, 2020

@tbaxter-18f, you highlighted in the thread that we could consider removing this if we had an alternative that had the required functionality. What is considered the "required functionality" that chosen.js provides?

It seems like it provides:

  • The ability to type into the project drop-down for quick search/selection
  • The ability to increment the hours box by 0.5
  • It makes things look fancy

Are these the features you're thinking of?

At this point, I figured out how to test around the library (by interacting with the magic DIV elementss that it creates), so I've navigated around the testing issues. But, if removing chosen.js as part of jQuery removal is a thing to do, I'm currently in that headspace... hence why I'm asking.

@tbaxter-18f
Copy link
Contributor

I'll be honest, I've never looked into what we're relying on it to do. I'd say it feels like extra scope creep for the JS removal, though, which has already proven to be thornier than I expected, so I'm inclined to investigate removing chosen on another date, especially if we can work around it now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants