completely impressed with linux's accessibility

[Máirín Duffy]

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:

https://github.com/rhinstaller/anaconda

Let me know if you need help with that. The anaconda team has its own 
list too, it's:

https://listman.redhat.com/mailman/listinfo/anaconda-devel-list

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