Add non-color indicator to vote button state #162

Open
opened 2026-08-05 14:28:48 +02:00 by retoor · 4 comments
Owner

Summary

Vote buttons (+/-) on posts and comments currently indicate the voted state only by a color change. This is insufficient for users with reduced vision or color vision deficiencies. The state should also be conveyed through a non-color cue such as a glyph, shape, outline, or fill change.

Steps to Reproduce

  1. Open any post or comment with + / - vote buttons.
  2. Click the + button (upvote).
  3. Observe that the only visual change is a color change of the button.

Expected Behaviour

The pressed/voted state should be distinguishable by more than color — e.g., a change in the glyph/shape of the character, an outline, a fill, or another non-color cue — so users with color vision deficiencies can reliably tell whether they have voted.

Actual Behaviour

The button's state is indicated solely by changing color; no non-color cue is provided.

Environment

Not provided.


Reported by D-04got10-01 via DevPlace.

## Summary Vote buttons (+/-) on posts and comments currently indicate the voted state only by a color change. This is insufficient for users with reduced vision or color vision deficiencies. The state should also be conveyed through a non-color cue such as a glyph, shape, outline, or fill change. ## Steps to Reproduce 1. Open any post or comment with + / - vote buttons. 2. Click the + button (upvote). 3. Observe that the only visual change is a color change of the button. ## Expected Behaviour The pressed/voted state should be distinguishable by more than color — e.g., a change in the glyph/shape of the character, an outline, a fill, or another non-color cue — so users with color vision deficiencies can reliably tell whether they have voted. ## Actual Behaviour The button's state is indicated solely by changing color; no non-color cue is provided. ## Environment Not provided. --- *Reported by **D-04got10-01** via DevPlace.*
Author
Owner

Design suggestion from the reporter:

The ideal solution would be to use characters very similar to the ones already in use. If there is a Unicode equivalent for '+' and '-' that e.g. sits inside a square box or similar, that would be best — the character count between the pressed and not-pressed states would remain identical (one character either way), so the layout would not shift at all.

An alternative would be to wrap the pressed button in brackets, e.g. show '[+]' or '[-]' when voted. The downside of that approach is that the pressed state would display three characters instead of one, which may break the GUI design by shifting elements around and possibly misaligning the vote buttons relative to their surroundings.


Posted by D-04got10-01 via DevPlace.

Design suggestion from the reporter: The ideal solution would be to use characters very similar to the ones already in use. If there is a Unicode equivalent for '+' and '-' that e.g. sits inside a square box or similar, that would be best — the character count between the pressed and not-pressed states would remain identical (one character either way), so the layout would not shift at all. An alternative would be to wrap the pressed button in brackets, e.g. show '[+]' or '[-]' when voted. The downside of that approach is that the pressed state would display three characters instead of one, which may break the GUI design by shifting elements around and possibly misaligning the vote buttons relative to their surroundings. --- *Posted by **D-04got10-01** via DevPlace.*
Author
Owner

Would a circle around the button work?


Posted by Alice via DevPlace.

Would a circle around the button work? --- *Posted by **Alice** via DevPlace.*
Author
Owner

On iOS use circles with + and - inside. The active vote becomes a filled circle.


Posted by Lensflare via DevPlace.

On iOS use circles with + and - inside. The active vote becomes a filled circle. --- *Posted by **Lensflare** via DevPlace.*
Author
Owner

Yup. These would work. My suggestion was mainly to avoid the need to create new art. Some of those do seem to be standardized art assets, though.


Posted by D-04got10-01 via DevPlace.

Yup. These would work. My suggestion was mainly to avoid the need to create new art. Some of those do seem to be standardized art assets, though. --- *Posted by **D-04got10-01** via DevPlace.*
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: retoor/devplacepy#162
No description provided.