Comment 2:

We spent a significant effort finding the current color scheme, consulting many people
during its design (specifically, the color blind).
Rather than saying what it should not be, please suggest (and present) alternatives.
It's harder than you think.

Comment 3:

If colours are needed, it may be worth having a look at http://colorbrewer2.org/ which
has a collection of colour sets that have been designed for clarity and have associated
metadata describing accessibility and viewability in different settings. The qualitative
sets would likely be most appropriate here.

Comment 4:

@2: "Rather than saying what it should not be, please suggest (and present)
alternatives. It's harder than you think."
I was not aware you know what I think ;-) Anyway, in the OP above I've actually
suggested using two color schemes:
1) Black text on white background without changing user-set or default monospace font.
2) Adopt the style godoc uses when showing source code (after eg. clicking a function
name).
Wrt 2, the approximative patch I use is at [0].
I'm not pushing for a specific change, I'm happy with my patched version, it's an easy
solution for me.
However, I believe that inverted color schema should never be used by default anywhere.
Golang.org is not inverted. Godoc is not inverted. Go profiler tool SVG is not inverted.
Go playground is not inverted. The Go project at code.google.com is not inverted. Go
issues are not inverted. Go blog is not inverted. No Google search or other service I'm
aware of is inverted neither.
But suddenly, the Go cover tool is inverted colors. Surprising at minimum, isn't it? Is
there a good reason for it to be inverted? If so, why it seems to not apply to the
examples above?
  [0]: https://gist.github.com/cznic/7056369#file-gistfile1-diff

Comment 5:

What is important in the coverage output is a clear distinction between what is covered
and what is not. And for the -count cover mode, you need to see a distinction between
the various levels of coverage.
We found that colored text on a white background was very hard for people to read, while
a black background made it much more legible. We use very dark text to signify the code
that is not tracked by coverage, because that code is irrelevant in the context of the
coverage report.
Again, this scheme was the result of much experimentation with the input of many people
with various vision impairments. If someone wants to do the work to improve this (and do
user testing, like we did) then I'm happy to take a look at it, but I don't want to
spend more time defending the current situation.
I hope that clears up the reasons why we took this route.

Comment 6:

OK, let's forget it, NP (with my patch). The only thing left what I still think is a
real mistake is that "very dark text" on black background. Yes, it's not relevant to the
coverage but it's very relevant to visual navigation in the source. Yet its contrast is
so low that it's a challenge to read it, probably even for young eyes. I'd guess that
any typographer/graphic designer would judge the contrast unacceptably low in the same
way there are lower limits on font sizes for anyone to read comfortably.
And lastly, I was not aware my slight visual impairment is so rare. I thought that's the
reason why there are AFAIK no books with white (or "very dark" for that matter) text on
black paper.

Comment 7:

I think the main reason why books are black-on-white is that ink is black and paper is
white (or, it's much easier to manufacture white paper and black ink).
Similarly, computer screens were originally light text on a dark background, because it
was easier to implement.

Comment 8:

"it's much easier to manufacture white paper and black ink".
Correct. To print a book with white text on black background a white paper and black
"ink" is used ;-)
There are magazines with light text on dark background. I think the point (nowadays) is
that books use to be read for much longer time spans than any graphically poor magazine
can ever hope for.
CRTs: Well, one NOT or XOR gate is all what was needed. I seem to recall some trouble
with the early luminophores, aging proportionally to the current (lightened pixel ==
more current) integral dt.

Comment 9:

My comments from the Google+ thread:
--
I am moderately red-green color blind*. The color scheme was designed with that in mind,
obviously, and also to make "heat maps" work. With a white background, the colors
indicating different levels of execution were too hard to decode.
To help with color blindness, the green has a lot of blue in it and the intensity alone
is used to define the value, so that the color is not discriminatory.
*Most people do not understand red-green color blindness. It's a contrast problem more
than an inability to see red and green. See
http://jfly.iam.u-tokyo.ac.jp/color/index.html
--

Status changed to WorkingAsIntended.

Recently on golang-nuts, "Is it possible to get code coverage information in a way that does not assume you can see color?"

https://groups.google.com/g/golang-nuts/c/DY4O9UXMr9M?pli=1

In this case, "see color" refers to a screen reader for a totally blind person.
That's not what this bug was originally exactly about, but the bug title is very general and includes this problem.

Reopening, so this can get some attention.
This is a bug, not an enhancement, because accessibility is important.
It does need someone who knows something about UI accessibility to look at it.

Reopening this issue is perhaps not the right action. The problem mentioned on the list is about having a non-visual way to see the data; this issue is arguing about the colors.

See also, for the screen reader version of html UI accessibility issues, #36685.