Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cover: (html output) UI accessibility issues #6623

Closed
cznic opened this issue Oct 19, 2013 · 11 comments
Closed

cmd/cover: (html output) UI accessibility issues #6623

cznic opened this issue Oct 19, 2013 · 11 comments

Comments

@cznic
Copy link
Contributor

@cznic cznic commented Oct 19, 2013

The color scheme has IMO some troubles:

1. It's inverted, ie. light text on dark background. Please be aware that some people
are not able to read comfortably it or read it at all for more than a brief time period
without physical troubles. I suggest to never ever default to inverted colors anywhere
whatsoever.

2. To make thing worse, the light gray text on black background has so low contrast that
the people having already trouble from the inversion scheme has now one more source of
pain. (Also a big sin of many Android UI screens.)

3. People can select default fonts they're comfortable with in the browser. Please
respect that and do not force another font where it's completely unnecessary. It's a
tooling report, not a design studio website front page or similar.

Suggestions:

- Select a font-family only, eg. 'monospace', not 'Menlo, monospace'.
- Remove 'font-weight: bold;'
- Support how many report styles you wish, but keep the default one which is plain black
text on white background by default (like this issues page.). The green/red emphasizes
on covered/not covered source lines is IMO ok.
- If a B/W scheme is considered too "plain", then I suggest to adopt the color
scheme already used for source code by the the godoc tool. It has no accessibility
problems I'm aware of. The typographical consistency would be a nice bonus, I believe.

My apologies for I haven't followed the design of the cover tool before so I could
provide such feedback earlier.
@adg
Copy link
Contributor

@adg adg commented Oct 21, 2013

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.
@kortschak
Copy link
Contributor

@kortschak kortschak commented Oct 21, 2013

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.
@cznic
Copy link
Contributor Author

@cznic cznic commented Oct 21, 2013

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
@adg
Copy link
Contributor

@adg adg commented Oct 21, 2013

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.
@cznic
Copy link
Contributor Author

@cznic cznic commented Oct 21, 2013

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.
@adg
Copy link
Contributor

@adg adg commented Oct 21, 2013

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.
@cznic
Copy link
Contributor Author

@cznic cznic commented Oct 21, 2013

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.
@robpike
Copy link
Contributor

@robpike robpike commented Oct 21, 2013

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.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
@dr2chase dr2chase reopened this Jan 21, 2020
@dr2chase dr2chase added this to the Go1.15 milestone Jan 21, 2020
@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Jan 21, 2020

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.

@golang golang unlocked this conversation Jan 21, 2020
@robpike
Copy link
Contributor

@robpike robpike commented Jan 21, 2020

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.

@dr2chase dr2chase closed this Jan 21, 2020
@dr2chase
Copy link
Contributor

@dr2chase dr2chase commented Jan 21, 2020

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

@golang golang locked and limited conversation to collaborators Jan 21, 2020
@dr2chase dr2chase removed this from the Go1.15 milestone Jan 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.