Slashdot Mirror


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."

2 of 266 comments (clear)

  1. A few options by raymorris · · Score: 5, Insightful

    So far, we know that Peter caused the change, Peter knows that, and Peter knows how to put it back. Peter isn't sure that it's broken since it now follows the written spec. Ideally, we'd like Peter to fix it, but for that we need to convince Peter that the new behavior is wrong and it SHOULD be reverted. If he chooses to, it will take many seconds to revert the change.

    What I'd do next is find the written documentation of the behavior in earlier versions, in Windows, and OSX. YOU said they all work the other way, but the spec says otherwise. So prove your case by linking to written documentation. When you post the links, mention "the principle of least surprise", a term meaning that users should not be surprised by the behavior of the software.

    Also, right now ONE person on the planet has said they don't like the new behavior. If EVERYONE in a large group is having a problem with it, a few could post saying so. I'm sure there are forums and such related to accessibility, so ask around. Find out for sure, are other people reall having great difficulty with it? If so, will they post in the ticket?

    Then mail Peter and request that he look at it. You could ask how much would be a fair contribution for his time spent looking into it. (Answer - about $20 - $50).

    If Peter doesn't respond, email the project maintainer, mentioning that Peter seems to be unavailable and asking that the maintainer look at it.

    If those two options fail, that single-line change is so small that any Linux programmer could compile a copy for you with it reverted. It would only take a minutes. Two years from now, if an important update comes out, someone could easily do the same with the new version. Obviously that's less desireable than getting the upstream source fixed, but it fixes YOUR problem.

     

  2. Re:It's been bisected and confirmed by bill_mcgonigle · · Score: 5, Insightful

    I'll bet this is going to be patched in the git repositor within a half hour.

    Reverting would be easy - I'm don't know enough about X to understand if the IsMaster(mouse) test can easily be augmented to not break StickyKeys, but fixing a null pointer dereference is something that needs to be done.

    But for just the users' use case (and people will hate this) - this is where paying somebody to deal with the problem for you comes in.

    A decent hacker would have done the work you did in the first hour, created a distro patch in the second, and put up a repo with the new packages in the third. Throw in an hour for testing.

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)