-
Notifications
You must be signed in to change notification settings - Fork 37
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
Comments
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. |
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. |
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. 😄 |
@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:
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. |
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. |
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-ydiv
. 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.
The text was updated successfully, but these errors were encountered: