-
-
Notifications
You must be signed in to change notification settings - Fork 20
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
Match capy click selectors with underlying html #1856
Conversation
8631c39
to
f19662e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good change, thank you!
You're going to have to fix a bunch more Capybara-based specs for this to go green tho.
You can add exceptions for the newly-failing files if you want, and check this in. That way you are making some progress, but don't need to sink a bunch of time into fixing all these other occurrences. |
Yea, we have some work to do to clean up how we're using links and buttons. It was my second project using ViewComponent and Turbo; and I basically brute-forced things to work. But getting to the point where buttons == change data and display and links == change display will be a huge win. Probably not the most urgent project but something to look out for as we make other changes. |
d6c4f9e
to
0f1ab2a
Compare
Wooo! Thank you! |
Regarding #1848 (comment)
The difference between buttons and links are syntactically and semantically confusing. I would love to better understand the accessibility standards around this. Having some expertise here would be helpful. But until we dig into that, what I was thinking is that we could force the developer into a syntactically correct choice to remove any ambiguity in the code about whether an element is a
<button>
or<a>
.