Ask Slashdot: How To Handle Unfixed Linux Accessibility Bugs?

dotancohen (1015143) writes "It is commonly said that open source software is preferable because if you need something changed, you can change it yourself. Well, I am not an Xorg developer and I cannot maintain a separate Xorg fork. Xorg version 1.13.1 introduced a bug which breaks the "Sticky Keys" accessibility option. Thus, handicapped users who rely on the feature cannot use Xorg-based systems with the affected versions and are stuck on older software versions. Though all pre-bug Linux distros are soon scheduled for retirement, there seems to be no fix in sight. Should disabled users stick with outdated, vulnerable, and unsupported Linux distros or should we move to OS-X / Windows?

The prospect of changing my OS, applications, and practices due to such an ostensibly small issue is frightening. Note that we are not discussing 'I don't like change' but rather 'this unintentional change is incompatible with my physical disability.' Thus this is not a case of every change breaks someone's workflow."

Comments

RMS mentions a comparable situation

[Krishnoid]

From The Law of Success 2.0:

RMS: So if I'm using the free program and I make a change in it, which I know how to do, then I could publish my modified version and then you. Perhaps you're not a programmer; you would still be able to get the benefit of the change I make. Not only that, you could pay somebody to change the program for you, or you could join an organisation whose goal is to change a certain program in a certain way, and all the members would put in their money, and that's how they would hire a programmer to change it.

Re:RMS mentions a comparable situation

[WaywardGeek]

Kudos to RMS for believing accessibility is a human right, and taking action personally to promote accessibility in Linux. Fixing accessibility in Linux is a mess, but if we can get enough people involved, it's doable. This is the mission of multiple efforts, and the one I'm involved in is the ACF (Accessible Computing Foundation). The free software movement, and the goal of people with disabilities taking control of their computing environments are well aligned. GNU/Linux provides a platform where at least in theory any and all accessibility issues can be corrected, unlike Windows and Mac OS X.

Unfortunately there are considerable obstacles to "fixing" accessibility in Linux. I believe they can be overcome if enough people come together to make it happen, but there are huge challenges. There are also people who devote a lot of their lives to improving the situation, often for free or very low financial incentive. I spearheaded the 3.0 release of Vinux, which is Linux for the Vision Impaired. I fixed a dozen or so accessibility bugs, but the right fix in many cases would involve major changes to GNU/Linux. I'll list a few.

The accessibility API in GNU/Linux, atk/at-spi, should have shared more functionality with Windows. For typical corporate and FOSS anti-Windows reasons, the accessibility stack was built intentionally in a Windows incompatible way. The result is that accessibility in Firefox and many other major applications never works as well in Linux as it does in Windows. It simply is not reasonable to make every software vendor do all their accessibility coding N times for N operating systems. There is even an effort called Iaccessible2, which is basically a FOSS accessibility stack for Windows, which the creators seemed to hope could also work for Linux. The code was even donated to the Linux Foundation. However, there was never any money or motivation in FOSS land to actually port the software to Linux, SFAIK. Building a single accessibility API that works in Windows, GNU/Linux, Android, and Mac OS X would go a long way towards fixing accessibility in all of those places, but especially in GNU/Linux, since it is usually the OS vendors put the least effort into. As it stands, few GNU/Linux distros are able to keep FireFox and LibreOffice accessibility working.

Then there's the problem of Linux being a multi-headed Hydra monster with no one in charge. At Microsoft, Bill Gates took a personal interest in accessibility, and that's all it took for the entire company to take accessibility seriously. In GNU/Linux land, RMS also takes a strong personal interest in accessibility, but it's not like most of the devs work for the guy. RMS can make his case, but when your boss is asking for prettier GTK+ widgets in Gnome 3 and you're late delivering, accessibility fixes fall by the wayside. When we are lucky enough for a patch to be developed, many times the GNU/Linux authors refuse to include them, because the "fix" is not perfect. For example, I added accessible descriptions to pixmaps in GTK+, which enabled blind users to hear 'star' for a star icon in a table containing pixmaps. The devs could not decide if pixmap was the right place for this accessible description, enabling them to justify doing nothing, and the continued lack of support for accessible icons was the result. It saved them a few hours of work in testing, which was their real priority. Multiply this asinine situation 100X, and you begin to understand why making Linux accessible is hard. GNU/Linux land seems to take pride in making it hard to fix accessibility, because we make it almost impossible to override any given stupid author's decision not to support accessibility. I should be able to patch GTK+, and have that patch automatically distributed to every user of every distro who believes my accessibility patches are something they want. Instead, we've built a system where patches have to be accepted by the authors, and then distributed slowly over years to the stable distros. Stupid, stupid, stupid...

Re:Mmm

[Sigma 7]

do it yourself (I get that this is often not an option, but including for completeness)

Sometimes it isn't an option because your fix gets rejected (or left to idle in an obscure bug report)

For example, one build utility had a bug where it checked for the presense of a compiler, but not if it was functional. The fix was rejected because the build utility doesn't check path - despite the fact that it does so for a different compiler. (Explicitly defining which compiler to use defeats the purpose of using said tool in the first place - I'd just use Makefile instead.)

Did you know it took 10+ years for Mozilla to fix the alert() denial loop? That bug is older than Mozilla itself, and the most obvious fix of "checkbox to stop further dialogs" was dismissed as a hack (compared to the destructive hack of force-killing Mozilla.)

Re:It's been bisected and confirmed

[VortexCortex]

It seems likely that there are enough people affected by this that if they all threw in a dollar it would have been done by the next day. What we might have here is a community coordination problem, not just a software bug.

Or, you know, just giving a head's up to the dev who was already bisecting the bug and what not. That the bug was left for months without follow-up from "affects me too on $OS $VERSION" is the problem. Instead of being so hyperbolic and moronic as to resorting to paying people and bitiching about it on a tech news site and saying, OH, SHOULD I JUST SWITCH TO $PROPRIETARY SOFTWARE like some kind of moron or shill, the affected party could have opened a new (duplicate) bug, but seeing as they already knew about the bug, it makes one wonder why the anti-FLOSS sentiment when they rejected the FLOSS model of fixing shit even having known about said model's existence as demonstrated by TFS.

I think the answer is more approachable issue trackers, so that laymen can more easily find bugs. They're a bit too unruly for joke six-pack to interact with directly, and may cause him to bitch loudly to his peers in frustration. Why, I'm no conspiracy theorist, but were I aware of what appears to be a glaring disregard for a disabled community and harbored any degree of malice towards FLOSS operating systems, I think that submitting vitriolic bullshit on popular tech-news sites and promoting proprietary software while doing so would be exactly the MO for my political propaganda.