completely impressed with linux's accessibility
duffy at fedoraproject.org
Wed Mar 18 13:48:30 UTC 2015
On 03/18/2015 09:27 AM, kendell clark wrote:
> I wanted to write in to basically
> apologize for yesterday's completely unclear rant.
I saw your first two emails this morning and have been meaning to reply
- you made a lot of reasonable and fair points, and some of the issues
you brought up unfortunately don't have easy answers.
> I've just completed converting another
> windows user over to fedora, always cause for celebration
Awesome, thank you!
> I'm in the process of
> tracking down the one anaconda accessibility bug, and will file a bug
> when I have. How do I submit a patch? I don't have access to the git
> repository so can't push directly.
If you want to discuss accessibility issues in Anaconda, you can feel
free to email me directly - I'm the UX lead for that project. If you
have a patch to contribute (awesome!) then you can do a github pull
request on the upstream github repo here:
Let me know if you need help with that. The anaconda team has its own
list too, it's:
They only recently migrated to github so I'm not sure they have the
process 100% down, but they are a friendly bunch and I am sure would be
interested in your patch.
> 1, When there are accessibility issues, how do I
> get developers who don't know anything about orca and at-spi
> interested in fixing them? Issues I often run into are developers
> complaining about the lack of good up to date documentation or simply
> that accessibility is hard.
So I only know a little bit about the app development side of
accessibility (I know a lot more about web accessibility,) but I think
one thing that could be a big help would be to put together some kind of
comprehensive guide in the case that one does not exist.
For example, you and I could get together and with your knowledge and
experience of how the user experience is supposed to work, we could
document your expectations as a user for how the application should
behave and document that really well. Then we could take it further and
talk to folks like Joanie and figure out the official way to implement
the user experience you need. Then we could bundle it up as an
accessibility training guide for developers.
With that in place, the next time you file an accessibility bug and the
developer says they don't know anything about accessibility, you could
point them to the guide and ask them to take it as self-training.
> 2, how do I deal with persistent bugs?
> There is a persistent one at the moment with orca and terminal
> applications. It will sometimes fail to announce incoming text.
> Apparently the cause is something in vte, which all or most terminal
> emulators depend on.
There's no easy answer for this. The best way I have found personally is
to try to track down the component at fault and speak with the upstream
maintainer, but there really is only so much you can do when many folks
who work upstream are volunteers.
> 3, how do I deal with the inevitable "just switch
> to windows, it's perfect" or "just switch to mac" developer?
This is also unfortunately just one of those things. :( Maybe it's
mostly an education issue - if there's a reference that points out the
accessibility deficiencies in Windows, you can point the folks
misdirecting you towards that. I know it sucks to have to constantly be
standing up for yourself as an advocate in this way instead of just
being able to use the software, but it is a very powerful thing for you
to do and it *will* help others that rely on accessibility in FLOSS. So
thank you for all of the advocacy work you've done thus far.
> I only get that
> way when a developer seems disinterested in fixing a bug, tries to
> sell me on another platform or is hostile "why would I fix
> accessibility issues, I don't need that" is the usual response that
> can get me worked up.
Honestly, I'd get just as frustrated/worked up in your position (and
have in other situations :) Like people telling me we don't need
outreach programs for women in FLOSS :) ) so I think I understand a
I think the main weapon here is developer education.
> Simply do the following and it will
> work ninety percent of the time. If you're using a toolkit, such as
> gtk or qt, use stock widgets. Those all provide the proper accessible
> names and labels that orca needs. If you use custom widgets, provide
> AccessibleNames for your controlls, and set the correct role type.
> Remember to set focusable to true on controlls such as buttons, lists,
> etc so that orca won't skip them.
This sounds like a good start to some developer accessibility training
:) Is this something you'd be interested in working on?
Also, just a suggestion - there is a G+ community I am involved with
called Universal Tux, it's a cross-distro discussion group about
accessibility issues in free software; you may find it helpful to
connect with the other folks passionate about FLOSS accessibility on
there. I can send you an invite if you like.
More information about the desktop