godoc web accessibility

[jimmy frasche]

I've been poking around in the godoc source lately and have noticed
some accessibility issues, though I have by no means run a full audit
so I'm sure there are some yet to be discovered. For the most part
it's not that bad, but there are definite areas of improvement.

(For anyone unfamiliar with the concept, web accessibility is really
just about making sure the site is usable no matter how it's used,
which includes things like making sure that everything works if you
don't use a mouse and that the site is still understandable when
spoken aloud by a screen reader.)

I can't claim to be an accessibility expert by any means, but I'm
familiar enough to contribute some improvements when I have time, at
least. Realistically getting 100% accessible is quite difficult and
requires a lot of access to equipment and specialized software for
testing that I do not have access to, but 95+% shouldn't be too
difficult.

Generally I find that in practice accessibility issues fall under one of:

· things that can be easily fixed without seeming to change anything
· things that can be easily fixed but that alter the look and feel so
require discussion
· things that are hard to fix but don't seem to change anything,
though the scope of the change will require discussion in the review
· things that are hard to fix and alter the look/feel so require discussion

I find that the majority of changes tend to be in the "low hanging
fruit" end of the spectrum and that the majority of changes tend to
not require visible changes. Given that it seems unwise to create an
issue/CL per issue since a lot of them will be a single change to a
single line of a single file. But, while most of them wouldn't require
much discussion, I'm sure there are some that would necessitate a lot.

I'm leaning toward:
· opening a meta issue
· starting off with a grab-bag CL of small changes from the first
category with individual CLs for the noisier diffs
· starting discussions in the meta issue for controversial but small
changes before creating CLs
· starting new issues, which ref the meta issue, for anything that
ends up in the last category before creating CLs

I'm posting here first because I'm not the one who has to review any
of this so I'd like to know if this sounds a sensible approach or if
there are better ways to proceed.

[Robert Griesemer]

This sounds reasonable to me (creating a grab bag/meta issue #n and then marking CLs as "For #n."). I suppose discussion can happen with CLs that are perhaps more controversial or seriously change the look and feel.

- gri

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[jimmy frasche]

Awesome. Filed https://github.com/golang/go/issues/22171 with
everything that I've noticed so far.

>> email to golang-dev+...@googlegroups.com.