All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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.