[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Blind user complaining on Adobe web site
Re: Blind user complaining on Adobe web site
Tue, 04 May 2021 19:43:34 -0600
I realize this thread has drifted somewhat from the original subject
line, but I just had to put my $0.02 (USD :) ) in on this comment. So,
On Wed, 2021-04-28 at 22:20 -0400, Arthur Torrey wrote:
> (yeah! something other than flagellating RMS's deceased equine....)
> I sort of agree, but at the same time, it appears to me that the
> FLOSS software world is far less 'disability friendly' than the fruit
> company or the other big name OS....
Seconded! I have a disability that pretty much makes "Sticky Keys"
mandatory for me. I'm therefore quite sensitive to support, or lack
thereof, for this (seemingly) simple feature. This varies from one
Linux distribution to another and from one Desktop Environment (DE) to
another. I can't remember how many times a new "stable" release of
Debian GNU/Linux has come out with some significant flaw in Sticky
Keys. Some examples:
1. IIRC, in the "early" days, DEs had no support despite a plethora of
other settings available both through GUI tools, and by "tweaking"
config files. Fortunately, one could just add '+accessx' to the X
command-line and get Sticky Keys in any X program.
2. Some DEs added GUI support for Sticky Keys but level/quality of
support varied widely. Some offered little more than on/off support
while others had options to also turn Sticky Keys on/off via various
methods (e.g. press the <Shift> key five times in a row, press two
modifier keys simultaneously, etc.), whether or not to "lock" a
modifier when pressed twice, and whether or not to play a sound when a
modifier was pressed.
Personal note: The last feature (modifier beeps) has, IMO, been on a
long, slow downward spiral ever since it was first introduced. When
first introduced it mimicked the version on Windoze. It played one
sound when a modifier was first pressed (stuck), a second sound when it
was pressed again (locked), and a third sound when pressed a third time
(released). These days most of the distributions I "play" with don't
actually play _any_ sound "out of the box" for one reason or another.
3. Most "modern" distributions have a fairly standard GUI interface for
turning Sticky Keys on/off ... but little else (including whether or
not to beep). However, handling of beeps seems to have diverged "under
the hood" with some DEs (e.g. GNOME and MATE) using what I'll call a
third party library (libcairo? lib<something>) while others (e.g.
Xfce) rely on 'pulseaudio' to catch X11 "bell" events ... but for at
least a few years this has not worked without tinkering in undocumented
ways with how 'pulseaudio' gets started by the Display Manager and/or
DE. Indeed, in Debian 'bullseye', Ubuntu since 19.xx, and Pop!_OS also
since 19.xx I have to write my own Bash script which I then add to each
De's "Startup Programs" list, and which tnhen invokes 'pactl' to get
this to work. Come _on_ folks! NOTE: Just to be clear, 'folks' here
refers to some unknown collection of developers, distribution
integrators, testers, etc. and _not_ specifically the FSF.
4. The Linux console. For a long time it's been possible to get a
limited form of Sticky Keys in the Linux console using 'loadkeys' and
an appropriate "keymap". It used to be easy to integrate this into the
boot sequence. Just drop your customized keymap file in the right
place and it'd be one of the first things loaded during boot. But
_now_, this is apparently done through "console-setup", which in turn
uses "XKB", which in turn requires some obscure machinations to get it
included in the initramfs. Ugh! And I have yet to see a major Linux
distribution offer to set this up during installation.
5. ... and so on, and so on.
And this is just Sticky Keys we're talking about here. Something
Windoze (and presumably Apple, etc.) have had since at least the late
1990s. I can't imagine what others with more difficult/complex
requirements have to go through/suffer with. I'm not surprised many
wind up going for proprietary solutions.
> My S.O has just become legally blind due to medical issues, and
> while I've been looking at what might be available in the way of low-
> vision setups, I've been rather underwhelmed...
My sympathies. :( I'd be curious to know whether you ever find a
suitable Free, or even Open Source solution.
> It seems every resource person she has heard from is pointing at the
> fruit company products as being most 'low vision friendly'. As a
> paraplegic I have minimal (no) need for accessibility stuff on my
> computers, but when I look at what the quads I know who need more
> adaptive setups are also using fruit machines almost entirely.
> I'm not a programmer of anything more complex than an Arduino, so not
> a lot I can do to fix things personally.
And even if you were, the bar for this seems to get higher and higher
all the time. I got my Ph.D. in computer science (computer vision)
during the 1990s. At the time I built 'gcc', 'emacs', and a host of
other GNU sofware, plus TeX, from source for the SGI workstations I was
using. I've written a considerable amount of C/C++ code both for my
dissertation and in industry. And yet, every time I try to fix Sticky
Keys I feel like I've got a hold of the proverbial end of the ball of
> It seems like a lot of the lower level of accessibility in GNU/Linux
> seems to be a combination of a (somewhat understandable) lack of
> 'itch that needs scratching' among mostly able bodied developers,
Indeed. Every time my current "fix" for Sticky Keys stops working I
first search for solutions on The Internet. And low and behold, the
first page or two of results are _users_ who want to know how to
permanently _disable_ some accessibility feature, with not a few
wondering why they're even available at all (i.e. they feel they
shouldn't be there _at_all_ unless specifically requested during
installation or some such).
> and the wide range of interfaces / API's / not sure what to call
> them that exist in the FLOSS world.
Yummm. As I alluded to above, this is even affecting something as
"simple" as Sticky Keys. It's been a long time since I could be
reasonably certain one "fix" would work for all DEs, and, of course the
DE and the Linux console have always been two different worlds.
> While usually this diversity is a strength, IMHO it is a problem
> when trying to come up w/ a consistent UI that works w/ every
> application. OTOH the fruit co's "One Way to Do Things" seems to
> make it easier to design an accessible UI that works w/ everything,
> and then focus on making it better....
... I'm not sure how to weigh in on this one. Having people implement
different approaches, then finding out what works and what doesn't
should be a Good Thing. But it seems to me that the second part of
that "equation" never gets evaluated. I could offer speculation as to
why, but it's already taken me about 3 hours to peck out this reply so
I'll leave that for others, or another "thread", or something.
> I don't know what the solution is, I just wish there was one.
[... rest of original below ...]
Leland C. Best | Creationists make it sound as though a 'theory' is
email@example.com | something you dreamt up after being drunk all night.
| -- Isaac Asimov
Arthur Torrey - <firstname.lastname@example.org>
> Date: Tue, 27 Apr 2021 14:34:30 -0400
> From: Greg Knittl <email@example.com>
> To: Jean Louis <firstname.lastname@example.org>
> Cc: email@example.com
> Subject: Blind user complaining on Adobe web site
> Message-ID: <firstname.lastname@example.org>
> Content-Type: text/plain; charset=utf-8; format=flowed
> fyi. pdf accessibility issues may be bigger than just XFA...
> I see enormous convergence of interest between Linux and the
> disabled as
> we are both 2 small and often overlooked minorities. The disabled
> have more formal legal rights than regular Linux users that we can
> piggyback on...
libreplanet-discuss mailing list