Closed Bug 1545331 Opened 5 years ago Closed 5 years ago

I can't see which of defect/enhancment/task is currently selected during editing

Categories

(bugzilla.mozilla.org :: Bug Creation/Editing, defect)

Product:
bugzilla.mozilla.org
Component:
Bug Creation/Editing
Version:
Production
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: pbone, Assigned: kohei)

References

(Depends on 1 open bug, Regression)

Details

(Keywords: access)

Attachments

(6 files)

screenshot
20.66 KB, image/png
Details
screenshot of improved button design
87.19 KB, image/png
Details
screenshot of improved button design, inveted
77.16 KB, image/png
Details
Screenshot: Updated toggle buttons with high contrast theme support
144.54 KB, image/png
Details
GitHub Pull Request
46 bytes, text/x-github-pull-request
Details | Review
Screenshot 2019-08-05
19.84 KB, image/png
Details
Attached image screenshot —

I love the new defect/enhancement/task field, but I can't see which one is currently selected when I'm editing a bug (see screenshot).

I have low vision and use a high-contrast mode in firefox: https://paul.bone.id.au/2017/11/26/how-i-see-the-web/ scroll to the bottom for the firefox plugin. This means that colour is often stripped or altered on web pages and doesn't always work to convey meaning, I see that when I disable my plugin colour is used to show the selected button.

The most accessible choice here is a combo box.

The same problem exists on the new bug pages.

I'm using Firefox 68 on Linux with the plugin from the end of the above blog post.

I see this is accessible to screen reader users by way of an off-screen <input type="radio">. Thanks! However, it's worth noting that anything (like this) which uses colour alone to communicate information is going to be inaccessible to several groups of users, including users like Paul who need contrast alterations and users with different kinds of colour blindness.

That makes me think. Having the radio buttons on screen in place of the buttons that are currently there would be perfect. More convenient than the combo box I suggested since there are only 3 options.

Keywords: access

We need to have the prefers-contrast CSS media query to solve this kind of issues smartly, but unfortunately it’s not implemented yet in Firefox. I’ll modify the design of the pressed button to see how it looks.

Assignee: nobody → kohei.yoshino
Version: Staging → Production

Why not use radio buttons? wouldn't that work for everyone and be less complex?

Because people prefer switcher-like UI than native radio buttons, which are more complicated UX-wise.

Regressed by: 1541133

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #3)

We need to have the prefers-contrast CSS media query to solve this kind of issues smartly

That would be great, but it still doesn't address the needs of all users; e.g. those with colour blindness . Note that this would fail WCAG criterion 1.4.1:

1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. (Level A)

I’ll modify the design of the pressed button to see how it looks.

Thanks!

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #5)

Because people prefer switcher-like UI than native radio buttons, which are more complicated UX-wise.

I don't mean to nitpick, but we need to be considering all people in UX, not just an (unspecified) subset. And aside from being more accessible, multiple cues help to reinforce a concept. I'm not suggesting a native HTML input is the only solution, but whatever solution we have should provide multiple visual cues, not just colour.

I’d change the style of the buttons like this. Apple uses similar design in macOS, including Calendar. Unfortunately, this won’t change the high-contrast mode that :pbone is seeing. I’m sure it’s a bug/limitation of the extension.

When I invert colours with the Accessibility pref in macOS, it will look like this. Doesn’t Linux have a similar system-level accessibility tool?

By the way, we’ll soon offer native Dark Mode.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #7)

Unfortunately, this won’t change the high-contrast mode that :pbone is seeing. I’m sure it’s a bug/limitation of the extension.

This same problem affects Windows' built-in High Contrast mode and anyone using it. It's not merely an extension issue. Is there some way to invert the colors on the selected item so that Widows high contrast mode works?

I don’t think we have much control here until the prefers-contrast CSS media query is implemented. No browsers support it at this time.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #7)

Created attachment 9060772 [details]
screenshot of improved button design

I’d change the style of the buttons like this. Apple uses similar design in macOS, including Calendar. Unfortunately, this won’t change the high-contrast mode that :pbone is seeing. I’m sure it’s a bug/limitation of the extension.

No matter what you do with colour there will be some percentage of users that will find this inaccessible. Weather they use a setting in their OS, any OS, a setting in the browser, an extension, different browsers, different eye coniditons, a screen reader, colour blindness etc.

You can use colour, provided that you also have some other non-markup non-style change to show this meaning. Eg a tick mark with the text in the bottom. Or replace the 3 buttons with a single combo box which the OS and browser already know how to make accessible.

(In reply to Paul Bone [:pbone] from comment #11)

No matter what you do with colour there will be some percentage of users that will find this inaccessible. Weather they use ... a screen reader,

Note that this is already screen reader accessible by way of an off-screen input. However, that doesn't solve the problem for colour blind users. See comment 6, noting that use of colour alone to indicate state explicitly fails WCAG criterion 1.4.1.

Depends on: 1548954

I think the current design works except if you're in high contrast mode on Windows. When in regular mode (not high contrast) the selected button has inverted text/background color from the un-selected buttons. That should be enough to make it distinct. The problem is that high contrast mode on Windows doesn't do the inversion. Invert colors on Mac does do the inversion and everything looks reasonably good on Mac.

It (at least what's live on BMO now) doesn't work with https://addons.mozilla.org/en-US/firefox/addon/dark-background-light-text/?src=userprofile on Linux.

Assignee: kohei.yoshino → nobody

This is still broken.

Flags: needinfo?(ehumphries)

In the meanwhile, can we make this a dropdown so that it is accessible?

Flags: needinfo?(ehumphries) → needinfo?(kohei.yoshino)

Using radio buttons here is okay; dropdown lists are not suitable for a small number of items. I recently read this article about toggle buttons and a simple solution here is probably adding a border to the selected item.

Assignee: nobody → kohei.yoshino
Status: NEW → ASSIGNED
Flags: needinfo?(kohei.yoshino)

So here we go. I could show an extra border and underline only in the high contrast theme (because these are in the same colour as background.) I’ve updated the default design as well, which is less distracting now.

Attached file GitHub Pull Request —

Merged to master.

Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #18)

Created attachment 9082139 [details]
Screenshot: Updated toggle buttons with high contrast theme support

So here we go. I could show an extra border and underline only in the high contrast theme (because these are in the same colour as background.) I’ve updated the default design as well, which is less distracting now.

It looks like there's a separate bug there. Are the labels missing or just have terrible contrast in the "high contrast black" image?

Attached image Screenshot 2019-08-05 —

Is it deployed already? I don't see a difference today 5th of August.

Flags: needinfo?(kohei.yoshino)

(In reply to Paul Bone [:pbone] from comment #21)

It looks like there's a separate bug there. Are the labels missing or just have terrible contrast in the "high contrast black" image?

It’s the default link colour of the browser. Maybe my configuration is wrong.

(In reply to Paul Bone [:pbone] from comment #22)

Is it deployed already? I don't see a difference today 5th of August.

Not yet. We could deploy this sometime this week.

Flags: needinfo?(kohei.yoshino)

Can this get deployed to bugzilla-dev for :pbone to review?

Flags: needinfo?(kohei.yoshino)

Bug 1571515 will update bugzilla-dev tomorrow so let’s see if this can ride along.

Flags: needinfo?(kohei.yoshino)

Ah, this one is already included in the commits being pushed to dev tomorrow. I’ll update this bug once it’s deployed.

https://bugzilla-dev.allizom.org/ is just updated with this change. You can sign in with GitHub to test the stuff.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #27)

https://bugzilla-dev.allizom.org/ is just updated with this change. You can sign in with GitHub to test the stuff.

It doesn't seem to work with github authentication:

Unable to log in with GitHub because two-factor authentication is enabled on your account.

Please log in using your username and password.

I don't want to disable two factor authentication.

The fix has been pushed to production today. You can see the difference now :-)

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #29)

The fix has been pushed to production today. You can see the difference now :-)

It's a subtle border, I have to concentrate to notice it. but it does work. Thank you.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: