Alan, on  bug 737271  Allen has been updating things to properly match the 0.2a spec.

I happen to agree with the sentiment of comment 0 here -- 0.2a is way too light (hard to distinguish from disabled, not very accessible), and 0.3a would be better.  But since it's been 9 months since this was filed I need to know if you agree, or if you rethought this and decided 0.2a should stand.

Once you clarify and update the spec, we can make the code match.

This is P1 since we're in the midst of changing this and should get this answered immediately.

Fwd'ing my reply from email: 

We can try raising the opacity to 0.28 (?) or whatever the value is of the omnibox. Is that reasonable? I think doing anything further begs into question what's acceptable UI for the majority of our users and what decisions should be delegated to a a11y mode/extension. 

An a11y compliant 1px stroke would be #000 0.50. That's not a pleasant experience for the majority of our users and arguably a degraded usability experience. 

Deleted: image.png 54.9 KB

	image.png 54.9 KB View Download

Let's give it a shot.  The task here is now to figure out precisely what the omnibox border stroke is computed as and try to do something similar for button borders and the like.

Changing the title to reflect

> Is that reasonable? I think doing anything further begs into question what's acceptable UI for the majority of our users and what decisions should be delegated to a a11y mode/extension.

I think what you're overlooking is that while a 1px 0.2a stroke might be acceptable on a 1x screen, that same 1px stroke is almost invisible on a 2x screen. I shouldn't need an accessibility mode to see the UI on a Retina machine (I don't need one now).

Jayson, is the omnibox stroke 1 px and still visible on a 2x monitor?  If so the proposal here to match it for buttons should help.

I know on views this stroke is indeed 1 px, but I'm not sure about Mac.

Do we have an option to special-case Retina, as we do from Cocoa? eg for the global update error motion work, spqchan added a Retina-specific behavior.

Hi pkasting@,

The stroke is 1px on Mac Retina. But, the situation is different because there's a light gray background around the omnibox which also helps define its bounds. If the toolbar were white (similar to secondary ui dialogs) I'm not sure how well the omnibox border stroke would hold up.

Fair enough.  Let's see how different the omnibox stroke would be from 0.3a, and if they're not quite the same, we could probably try both and see if at least the darker one is good enough.  If not, we can investigate a scale-factor-specific solution if need be.

monorail likes to show 2x screenshots at "full size" on the bug page (IIRC), which means that if I add a 2x screenshot directly from my Retina Mac you'll see the dialog larger than it really is when viewing the bug on a 1x monitor.

To get around this I added the 2x screenshot to Sheets and was able to take a correctly-proportioned screenshot of the that on my 1x machine. What I'm attaching should be roughly representative of my 2x experience.

Deleted: Screen Shot 2017-08-08 at 3.40.18 PM.png 23.6 KB

	Screen Shot 2017-08-08 at 3.40.18 PM.png 23.6 KB View Download

Yeah, I agree that the current situation isn't good.  Frankly I don't think it's good at 1x either.  Something closer to what we use for the dialog border would make me happier.

Partial fail. But if you download the image and open in the image viewer of your choice (except for Chrome, which seems to scale it up), you should see the actual-size image.

I opened it in an image viewer. Yikes. The lines are barely there at all.

This is how the button stroke looks with 000000 @ 0.3a as the color.

Deleted: OmniBoxVsButtonStrokeColor.png 1.2 KB

	OmniBoxVsButtonStrokeColor.png 1.2 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/79ef01a95afe237fdc31c3cbd2db2f8f0ab0fbd7

commit 79ef01a95afe237fdc31c3cbd2db2f8f0ab0fbd7
Author: Allen Bauer <kylixrd@chromium.org>
Date: Wed Aug 16 14:04:50 2017

Adjusted the button stroke color to be 000000 @ 0.3a.

Bug:  660414 
Change-Id: Idd3c3b6b2cd69c6c4cca481e1d133ab43f455132
Reviewed-on: https://chromium-review.googlesource.com/614755
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Allen Bauer <kylixrd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#494766}
[modify] https://crrev.com/79ef01a95afe237fdc31c3cbd2db2f8f0ab0fbd7/ui/views/controls/button/md_text_button.cc