Ask Slashdot: How To Handle Unfixed Linux Accessibility Bugs? 266
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."
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."
Re:It's been bisected and confirmed (Score:5, Informative)
Goddamn that was painful, but I found the actual patch:
http://cgit.freedesktop.org/xo... [freedesktop.org]
I would say it is rather shocking that this Peter Hutterer actually did about 90% of the work, then posted something that is not a clue as to how to see the answer.
And that the original poster (who I assume made this Slashdot story) did not post any followup for 3 months, probably leading Peter to forget all about fixing this.
Use older version.. (Score:4, Informative)
Some distros are supported for a long time, like CentOS, Ubuntu LTS and others (I dont' know them) and debian is half-decent with three years.
So it's easy to install a distro based on Ubuntu 12.04, you get support till 2017 so that buys you time till the bug is fixed! (or even some Wayland and graphics driver that work well enough, if the accessibility feature is implemented)
Debian wheezy uses Xorg 1.12.4 (I've just checked) and works till 2016, it has many derivates too (like Crunchbang)
I don't know too much about the rpm world, if not for CentOS, it is dated but has very long support. till 2020.
Contact the Linux Foundation (Score:5, Informative)
Basically what you want is to escalate this issue so that it gets more attention. As this affects people with disabilities I suspect you may get some results if you try to contact the Linux Foundation [linuxfoundation.org], who may then be able to twist a few arms or throw some resources at the problem as needed. You could, for example, point this very thread out to "pr@linuxfoundation.com" and let them know that this is a bit of a black eye against Linux.
Re:What the hell is wrong with some people? (Score:2, Informative)
No kidding, eh?
Not the only instance. Here's one from ages ago, identified initially as an accessibility issue:
https://bugreports.qt-project.org/browse/QTBUG-24304
even prodvided test case to demonstrate it. Finally gets a response ~ 1 1/2 *years* later:
"... Believe it or not, we have other priorities (this is actually not the only open bug!) and some of them even support our jobs so that we can continue working on Qt. ..."
This kind of lack of interest in accessibility is why we don't use any Linux on the desktop. Macs & Windows make it a priority.
Solution: donate to disability development program (Score:0, Informative)
There is a foundation and distribution specifically working towards disability accessibility in GNU/Linux.
The distribution is Sonar GNU/Linux and the foundation is the Accessible Computing Foundation: http://theacf.co/
Jonathan Nadeau, a blind GNU/Linux user who interned at the Free Software Foundation has made strides in improving accessibility in various distributions. He worked with Rubén Rodríguez (lead developer of the Trisquel distribution) to improve accessibility in one distribution and then ran an indiegogo campaign to raise funds for a new distribution specifically targeted at fixing disability related problems in GNU/Linux. His distribution is called Sonar GNU/Linux. Jonathan Nadeau is also the Executive Director of the Accessible Computing Foundation and Vice President of IAVIT. He also is responsible for the Northeast GNU/Linux Fest. While not disabled or blind I'm proud to have donated a significant amount of money to the project. However more users need to donate. Particularly those with the means to do so. This is one organization that is in particular in need of funds. Often disabled users are not in a position to contribute significant due to accessibility difficulties that limit there means. To improve the means and self-sufficiency of such users more people outside this community need to make an effort to fix it.
If you want these types of issues fixed I'd highly recommend contributions to these organizations and these types of organizations/projects.
Re:It's been bisected and confirmed (Score:2, Informative)
Spitzak your "not post any follow up for 3 months" statement seems to easy to disprove.
https://bugs.freedesktop.org/show_bug.cgi?id=73155
Dotan Cohen 2013-12-30 14:46:05 UTC - Original post
Dotan Cohen 2013-12-30 18:46:10 UTC - response same day
Dotan Cohen 2014-01-10 13:25:23 UTC - initial response to Peter Hutterer
Dotan Cohen 2014-02-14 10:20:39 UTC - second response to Peter Hutterer (includes a thank you)
Dotan Cohen 2014-03-21 12:35:54 UTC - inquiry on possible schedule to fix
Slashdot post
Dotan Cohen 2014-03-28 21:34 - public request for assistance
Re:RMS mentions a comparable situation (Score:3, Informative)
There's one major problem there: most disabled people in the US are living on Supplemental Security Income of $600-850/month, and have no other source of money. Even a group of them are unlikely to be able to pool enough to hire somebody to fix a bug in something like Xorg.
Re:What did you expect? (Score:5, Informative)
The bug is asking for the wrong fix (Score:5, Informative)
Read the bug report. The accessibility feature works. The submitter (who also happens to be the bug reporter) found a fairly minor subfeature (the ability for sticky key modifiers to act as lock keys) has been broken recently. I say fairly minor, because the only key this might be critical for in certain use cases is the Shift key, where a separate Caps Lock is already available.
The bug is asking for the wrong fix
Different modifiers have different combinatorial effects. Caps Lock is not necessarily Caps Lock, in other words. I know that most Linux people hate them because they are cheap, and you have to do a "disable secure boot" dance to install Linux on them, but ChromeBooks, in particular, lack a Caps Lock key. Caps Lock is achieved by hitting both shift keys simultaneously.
If that isn't convincing enough, consider Alt-Gr vs. Right-Alt behaviour on international keyboards that report a USB HID country code of 00h.
While I was working on ChromeOS at Google, there were a number of obvious usability issues for the OS, but the majority of them stemmed from the need to upstream support into Linux, and the difficulty of doing this without involving an Alan Cox, Ingo Molnar, or similar personage when you were dealing with things which crossed area boundaries. Input is one of these areas, and it was rather difficult and roundabout to get support for non-adjusted raw system time stamps in evdev inputs, even as a non-default option.
Exaggerating the issue by claiming it makes accessibility on Xorg unusable and bitching on slashdot because its been a whole 11 weeks since he found the problem and noone has released a fixed version yet is just grandstanding.
I agree the issue is exaggerated, but mostly because I disagree about where in the input stack usability issues should be addressed. The usability belongs in the input stack, as does the internationalization, below the point at which events are reported to the console, or to X (or Wayland or whatever display server is handling the apps and forwarding the input events).
It's pretty easy to see where this breaks down by enabling "programmer mode" (meaning: disabling "secure boot mode") on a ChromeBook, and enabling root or other console logins. It's easy to see the shift-shift (or Caps Lock, if you plug in a standard USB keyboard) and internationalized input don't work the same on the console as they do in the graphical environment.
In general, the input stack in Linux has a *lot* of problems. A fun experiment to try is plugging in 3 or 4 USB keyboards, and playing with the Caps Lock; the light goes on or off on whatever keyboard you're playing with it on, but the actual Caps Lock state depends on whether you've hit the Caps Lock key on an even or odd number of keyboards, and the keyboard Caps Lock lights very quickly become desynchronized from the actual Caps Lock state (i.e. turning Caps Lock on on keyboard A lights the light on A, and hitting it on B turns it on on B, rather than off on A, even though the state is that Caps Lock is no longer in effect).
Similar issues occur when using sticky modifiers for usability, and when moving between virtual consoles with various modifier/Caps Lock/etc. states in effect.
I understand the idea that you may wish to explicitly allocate resources in a multihead environment, but the input stack really doesn't do that very well, either - these modifiers should happen in the input stream above a stream join as a resource allocate by a virtual console or display server, and not in the display server or the underlying driver.
Windows doesn't support multihead well (at all, for multiple sessions, without something like Citrix intermediating the process), but it also doesn't screw up on where it put the internationalization translation tables and the dispatch routines and the usability.
PS: In case you care, AFAIK, there are zero vendors who put the correct internationalization keyboard code type in the USB
Re:Childish (Score:3, Informative)
Agreed. It's even worse when you realize just how many accessibility features exist in Windows - they've got almost everything, and you can expect them to work given there's high visibility of the operating system compared to most Linux distros. But of course people prefer to joke instead of accept the fact that Linux distros simply don't have the same level of support for accessibility features as seen in the proprietary systems, and that continual joking is why I don't bother with Linux for my own system anymore.
fix for Gentoo Linux (Score:5, Informative)
stickykeysfix.patch [pastebin.com]
It simply reverts the problem causing commit and now sticky keys are released after a mouseclick on my system. I don't know if this introduces other bugs though.