From: "Pádraig Brady" <P@draigBrady.com>
To: Felix Miata <mrmazda@earthlink.net>, util-linux@vger.kernel.org
Subject: Re: tty[1-6]: colors a negative accessibility/usability trend
Date: Thu, 12 Feb 2015 11:04:31 +0000 [thread overview]
Message-ID: <54DC88BF.5040702@draigBrady.com> (raw)
In-Reply-To: <54DC762E.2090404@earthlink.net>
On 12/02/15 09:45, Felix Miata wrote:
> Red, blue and green in particular produce poor contrast on the black
> background of a typical framebuffer screen.
Agreed, though the bold variants are better.
Better again are 256 color variants.
The Linux console lagged xterms in support, but does support it now.
> As these screens are configured
> as functional twins of those modes we find ourselves in at rescue time, it
> amounts to an unfortunate and unnecessary accessibility/usability obstacle
> that is IMO is a subset of a larger general problem found under the moniker
> A11Y[1].
>
> A very good, very recent article discusses the mindset that leads to default
> settings that thwart use by the disadvantaged[2], however slight that
> impediment may be.
I agree completely. color is useful but one has to be very careful
in how it's used. ls --color for example is too aggressive IMHO,
and I adjust to highlight rather than color with:
http://www.pixelbeat.org/scripts/l
I've been pusing back upstream against adding new color combinations.
> With util-linux >= 2.25 we can turn colors off via
>
> # touch /etc/terminal-colors.d/disable [3]
>
> for some commands, but far too few. It should apply to all, including many
> outside the purview of util-linux, and more importantly, do so by default.
coreutils will keep this scheme in mind too.
thanks,
Pádraig.
next prev parent reply other threads:[~2015-02-12 11:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-12 9:45 tty[1-6]: colors a negative accessibility/usability trend Felix Miata
2015-02-12 11:04 ` Pádraig Brady [this message]
2015-02-13 3:21 ` Dale R. Worley
2015-02-13 9:21 ` Karel Zak
2015-02-13 10:33 ` Sami Kerola
2015-02-13 11:25 ` Karel Zak
2015-02-15 11:12 ` Mike Frysinger
2015-02-16 9:10 ` Karel Zak
2015-02-16 9:35 ` Mike Frysinger
2015-02-16 9:47 ` Karel Zak
2015-02-16 10:32 ` Samuel Thibault
2015-02-16 13:49 ` Karel Zak
2015-02-27 13:48 ` Karel Zak
2015-03-01 13:32 ` Pádraig Brady
2015-03-01 15:14 ` Peter Cordes
2015-03-02 8:59 ` Karel Zak
2015-03-02 9:31 ` Samuel Thibault
2015-03-02 11:03 ` Karel Zak
2015-02-15 17:38 ` Dale R. Worley
2015-02-16 9:18 ` Karel Zak
2015-02-13 17:55 ` Bruce Dubbs
2015-02-12 13:21 ` Karel Zak
2015-02-12 13:56 ` Samuel Thibault
2015-02-12 14:38 ` Karel Zak
2015-02-12 15:25 ` Edward d'Auvergne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DC88BF.5040702@draigBrady.com \
--to=p@draigbrady.com \
--cc=mrmazda@earthlink.net \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.