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
--
desktop mailing list
desktop@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/desktop
