-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Make buttons to vote more accessible #4776
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
javierm
changed the title
Improve accessibility of the buttons to vote
Make buttons to vote more accessible
Feb 9, 2022
javierm
force-pushed
the
vote_accessibility
branch
4 times, most recently
from
February 10, 2022 17:58
3559e93
to
2e3db9a
Compare
taitus
approved these changes
Feb 10, 2022
javierm
force-pushed
the
refactor_votes
branch
from
February 21, 2022 17:47
2baf316
to
86ad2df
Compare
This way blind screen reader users will know which proposal they're supporting. In a list of proposals, context might not be clear when a link saying "Support" or "Support this proposal" is announced, but a link saying "Support Create a monthly transport ticket" is less ambiguous. Just like we did with investments in commit de436e3, we're keeping the title attribute because when visiting a proposal page, the connection between the "Support" link and the proposal is not as clear as it is in the proposals index page, so it might not be clear what you're supporting.
Note we're using the `budgets.investments.investment.add_label` and `budgets.ballots.show.remove_label` internationalization keys so they're consistent with the `budgets.investments.investment.add` and `budgets.ballots.show.remove` keys which were already present. We aren't unifying these keys in order to keep existing translations.
Having buttons (previously links) with the text "I agree 75%" is confusing; people might believe they're saying they only partially agree with the content. Besides, the results percentages is a different piece of information which shouldn't be related to whether one person agrees/disagrees with the content. This problem might be solved for people using screen readers since we added the aria-label attribute. However, for sighted keyboard users, the percentage was being outlined on focus as part of the button, which might be confusing.
This way we can simplify the code in the views a little bit.
Using the `flex-with-gap` mixin we avoid the left margin in the second element when the screen space isn't wide enough to show both buttons. Setting the margins with CSS also allows as to simplify the view and makes it easier to customize styles.
As mentioned in commits 5311daa and bb958da, using links combined with JavaScript to generate POST requests to the server has a few issues. We're also improving the keyboard access. Previously, the links were focusable and clickable with the keyboard. Now we're disabling the buttons when voting isn't allowed. Since these elements can no longer be focused, we're adding an element with `tabindex="0"` so the "participation not allowed" message is shown, like we do in most places. Note we're slightly changing one test because now when hovering over the button on Chrome, the "participation not allowed" text isn't shown; it's only shown when hovering on the parts of the `div.ballot` element outside the button. Since we're already rewriting the behavior of the "participation not allowed" text in a different pull request, we aren't going to fix this behavior.
Note we're using the in-favor HTML class instead of the in_favor class so we're consistent with our conventions for HTML classes and because we use the in-favor class in similar places. Also note the styles of the legislation process annotations/comments buttons is now similar to the styles in the other sections. Previously, the colors didn't have enough contrast and there was a very strange margin between the "thumbs up" icon and the number of people agreeing (that margin wasn't present between the "thumbs down" icon and the number of people disagreeing).
javierm
force-pushed
the
vote_accessibility
branch
from
February 21, 2022 17:48
2e3db9a
to
aa2c551
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
References
Objectives
Visual Changes
Most of the changes in this pull request aren't visual; here are some which are indeed visual.
Before these changes
Debates index:
Legislation annotation comments:
After these changes
Debates index:
Legislation annotation comments: