Closed Bug 1564999 Opened 2 years ago Closed 2 years ago

Add menu with simulation options to the accessibility panel

Categories

(DevTools :: Accessibility Tools, enhancement)

enhancement
Not set
normal

Tracking

(firefox70 fixed)

RESOLVED FIXED
Firefox 70
Tracking Status
firefox70 --- fixed

People

(Reporter: mislam, Assigned: mislam, Mentored)

References

(Depends on 1 open bug)

Details

Attachments

(14 files)

We would like to add color blindness simulation functionality to the accessibility panel and start with something similar to the NoCoffee extensions that are available for Chrome and Firefox (https://addons.mozilla.org/en-CA/firefox/addon/nocoffee/) as well as the simulator on Android (https://developer.android.com/studio/debug/dev-options#hardware).

Add a simulation menu to the accessibility panel in the accessibility toolbar following the audit checks. The menu should contain the major types of color blindness: Protanomlay, Deuteranomaly, Tritanomaly and Achromatomaly, as well as an option to Disable the simulation mode.

Flags: needinfo?(victoria)
Blocks: 1564966
Depends on: 1564993
No longer depends on: 1564966

Hi Victoria!

We need some icons for this bug; in particular: an icon for the simulation menu button and an icon for each of the five options. I attached a rough mockup of the menu I prototyped. In the menu item icons, the letters R, G, B correspond to reduced sensitivity to the colors red, green or blue for the corresponding color blindness. The letter M refers to monochromatic vision for people with the Achromatomaly condition. The mockup is just a suggestion, feel free to take as little or as much from it. Please let me know if you need clarification on anything.

Thanks!

Summary: Create simulator front and add simulation menu to the accessibility panel → Add menu with color blindness simulation options to the accessibility panel

Hi Maliha,

Wonderful to see this being worked on!!! And great mockup :).

I wonder if it would be worth adding a little extra explanatory text to the options, since most people won't recognize any of the names, and just seeing the first letter of the colors might not be obvious enough. Also, we could perhaps put Deuteranomaly first since it's the most common.

No simulation
Deuteranomaly (low green)
Protanomlay (low red)
Tritanomaly (low blue)
Achromatomaly (grayscale)

As far as icons, one thing I thought of is showing a little palette of 2-3 colors for each one to show what the vision generally looks like. So for Deuteranomaly, we'd see reddish tones and blue. Also, it's possible that instead of the more medically accurate negative wording (low green) we could describe it in a positive (red-toned), but maybe that's starting to get confusing for those who are familiar with the terms.

Flags: needinfo?(victoria)

Great ideas!

Regarding describing the conditions in more positive wording, Android developer options describe the type of color blindness, e.g. Deuteranomaly (red-green), Protanomaly (red-green), Tritanomaly (blue-yellow) (see http://parseyourtime.blogspot.com/2015/05/color-space-simulation-in-android.html). Does that seem better?

Regarding showing little palettes of 2-3 colors for each icon, I was wondering if this would be a bit inconvenient for developers with a particular color blindness who would want to use this feature to simulate the other types of color blindness. I don't have any stats on whether this is a problem area, but just wanted to point out some things to consider.

Flags: needinfo?(victoria)

Ah, I've seen this red-green, etc wording as well. It's probably a more standard way to summarize the different types, though unfortunate that Deuteranomaly and Protanomlay would end up with the same description.

Would it make sense to flip the description for one of them so it looks like this, with the stronger resulting color effect first?

Deuteranomaly (red-green)
Protanomlay (green-red)
Tritanomaly (yellow-blue)
Achromatomaly (grayscale)

Regarding showing little palettes of 2-3 colors for each icon, I was wondering if this would be a bit inconvenient for developers with a particular color blindness who would want to use this feature to simulate the other types of color blindness. I don't have any stats on whether this is a problem area, but just wanted to point out some things to consider.

I was thinking of the color palettes as a visual summary for regularly-sighted users (and a way to make the UI more appealing to regularly-sighted users, who will need more convincing to use this feature :)). It's true it would not be useful for those with color blindness, but hopefully this wouldn't harm their experience. Maybe we could instead identify each type with a single coloring for the eye icon.

For the first version of this patch in Nightly, we could go without icons. We do have a new photon-style eye icon from Florens in this bug.

Flags: needinfo?(victoria)

Hi Victoria,

After some discussion with the team, we decided to add and remove some simulation options. The color blindness types are ordered from most to least common (See table in https://www.alanzucconi.com/2015/12/16/color-blindness/2/). We might exclude the monochromat color blindness types- Achromatomaly and Achromatopsia- since they are extremely rare (What do you think?). In addition, a contrast loss option is added which can be applied simultaneously with a color blindness. We are also thinking of adding a css style to the simulation menu button icon when one/more simulation options are selected so that it indicates that simulation is "ON" (similar to how the timer icon in the Performance tab turns blue when activated).

We removed the "No simulation/None" option since the user can disable the simulation by unchecking the selected options. The "Learn more" option will link to an MDN doc which will contain more info on this feature, as well as a disclaimer to users that the simulations might not be medically accurate.

I took your first advice for the descriptive wording in the brackets for each color blindness type since it allows for more specific wording (i.e. low green vs. no green) with the added options. Also, I'm on board with your ideas for the individual icons for a later iteration (if they still make sense with the added options)! :)

Let us know your thoughts!
Thanks.

Flags: needinfo?(victoria)

Oooh, great to see how the descriptions work here! Yes, makes sense to drop the monochromat types.

Sounds great to add an indicator when something is selected! In addition to blue coloring, we could potentially change the icon. E.g. it could be a crossed-out eye for No simulation. (Second comment to follow re: eye icons)

I feel that it may be best to leave in a "No simulation" option just to make it very easy to quit out of the modes, since they're such a non-neutral change, and generally temporal. (in the way Network has "No throttling"

I wonder, is "contrast loss" kind of like "low vision," and would the latter be a clearer way to describe it?

Flags: needinfo?(victoria)
Attached image image.png

Some eye icons to consider for the simulation dropdown.

On the left, made for Firefox passwords, we have more realistic/friendlier eye. On the right, the eye made by Florens for Firefox prettifying of code. (I think the closed eye part of this is very clever but getting a bit creepily watchful-eye-esque :D. So I suggested the off-mode also be a crossed out eye.)

The problem with eye vs. crossed-out eye is that it could be a bit confusing which one means "eye with impaired vision." Maybe there's some other way to indicate normal vision vs simulated vision (beyond the color change)? So that the regular eye is normal vision, and eye with (some graphical indicator) is simulated vision.

Also, instead of "simulate," the text could be potentially be: Normal Vision/Simulated Vision. (Or whatever is a better way to say "Normal"). In Network, I feel the "no throttling" terminolgy is kind of weird due to the negative phrasing.

Blocks: 1567249
Attached image simulating-state
Attached image menu-button-active-1
Attached image menu-button-active-2

This and the one before are two different options for the simulation menu button active state.

As you can see, design 1 matches the styling for the audit filters in the accessibility panel. Please ignore the height difference for the simulation button compared to the other buttons- this should be fixed with a smaller eye icon (12px by 12px). Also note that the audit filters are toggle buttons (no menus contained within), while the simulation button is a menu button (opens up a menu).

Design 2 matches the main panel tabs (i.e. Inspector, Accessibility, Console,etc) selected state.

Which one do you prefer?

I wonder, is "contrast loss" kind of like "low vision," and would the latter be a clearer way to describe it?

Low vision is an umbrella term for other pervasive issues like blur (low acuity), glare, contrast loss, etc. So, I think Contrast loss would be more clear.

The problem with eye vs. crossed-out eye is that it could be a bit confusing which one means "eye with impaired vision." Maybe there's some other way to indicate normal vision vs simulated vision (beyond the color change)? So that the regular eye is normal vision, and eye with (some graphical indicator) is simulated vision.

I agree that the crossed-out eye may be confused with eye with impaired vision. Another thing is that the eye icon may already specify "vision" simulations, which is not really the case as we are planning to have other options in this menu in the future such as reduced motion simulation. For now, why don't we just keep the same icon for both simulation and no simulation cases, and only change the text instead? May I suggest a VR glasses icon instead? I'm also fine with sticking to just the open eye.

Also, instead of "simulate," the text could be potentially be: Normal Vision/Simulated Vision. (Or whatever is a better way to say "Normal"). In Network, I feel the "no throttling" terminolgy is kind of weird due to the negative phrasing.

This is a great suggestion since only changing the icon color presents accessibility issues! We are experimenting with the wording Simulate/Simulating... What do you think of that?

I have attached updated UI changes for the menu and menu button above. Please give us some feedback :) Thanks!

Flags: needinfo?(victoria)
Summary: Add menu with color blindness simulation options to the accessibility panel → Add menu with simulation options to the accessibility panel
Attachment #9079762 - Attachment description: Bug 1564999 - Add menu with simulation options to the a11y panel → Bug 1564999 - Add menu with simulation options to the a11y panel, r=yzen

I like this idea of Simulate/Simulating! If we also just add the double-arrow icon at the end of <select> inputs (see the menus in RDM), then that can keep it looking like a menu.

As for the style of the Simulating state, I'm not sure, and I realize it's going to affect this other patch as well. I think my preference is to remove the ellipsis and Design 2, for now.

Flags: needinfo?(victoria)
Attached image eye12x12_i.svg

Here's the smaller eye icon

Attachment #9079762 - Attachment description: Bug 1564999 - Add menu with simulation options to the a11y panel, r=yzen → Bug 1564999 - Add menu with simulation options to the a11y panel, r=yzen,nchevobbe

Hi Victoria!

Thanks for all the suggestions. Here's the updated simulation menu. For now, we have decided to allow the user to select one option at a time (Contrast Loss can no longer be co-selected with a color blindness option). In the future, we may allow multiple simulations at a time.

Please let us know what you think!

Flags: needinfo?(victoria)
Attached image button-states

This looks wonderful! So excited to see this land :D

Flags: needinfo?(victoria)
Blocks: 1567200
Pushed by yura.zenevich@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/82ffbd60679f
Add menu with simulation options to the a11y panel, r=yzen
Duplicate of this bug: 1564966
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
Depends on: 1582439
You need to log in before you can comment on or make changes to this bug.