completely impressed with linux's accessibility

kendell clark coffeekingms at
Wed Mar 18 14:20:30 UTC 2015

Hash: SHA512

This sounds absolutely awesome! I'll join the installer list as soon
as I get back with another cup of coffee.  I'll be glad to write up
some documentation about user expectations, this I can do easily. I'll
leave some of the actual backend work to people who understand it, I
have some idea of how it works, but not a very good one. I'll start on
that now. I'm just about to test my fix now, I just need to install
the actual installer, I think fedora removes it upon installation, but
leaves most of it's configs behind. If it works i'll submit a pull
request. As far as accessibility deficiencies  in windows, those
mostly come from inadequate or missing accessibility support in
toolkits. Qt, for example, is not very good on windows though it does
sort of work. The thing I find frustrating is the constant, and I do
mean constant amount of "linux will never get anywhere, windows works
for me" responses that I have to deal with when trying to get windows
people to try linux. It needs more users in order for accessibility to
improve. I have a serious dislike for windows users more than windows
itself, although I don't like it much either. Sighted or blind, some
of them can be some of the most user hostile, smug, and altogether
unpleasant people there are. Sure, if you want to send me that invite
on g+ I'll join. At the moment there's a hilarious bug in the g+ sign
up page. THe gender list box seems to be immutable. Orca won't cycle
through the gender choices, staying stuck on none, and google refuses
to let you continue until you've set one
Anyway, back to fixing that anaconda bug
Kendell clark

Máirín Duffy wrote:
> Hi Kendell,
> 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 little bit.
> 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.
> ~m
Version: GnuPG v1


More information about the desktop mailing list