Re: [orca-list] Accessibility of apps

[kendell clark <coffeekingms gmail com>]

hi
I don't know that I'd say that it's not a screen reader problem, but
rather that it depends on what the problem is. Usually it's not, this is
true, but sometimes orca can get tweaked and apps that weren't
accessible become accessible. Personally, and this is just me, this
"it's not my problem" seems overdone. People use it to avoid having to
put effort into the problem. Joanmeri and the gnome devs are the
exception. They're really good about fixing accessibility problems,
although sometimes they take a while. Before someone points out other
platforms, the problem exists there. Although on those, the problem
seems to be blamed on components they can't fix. "Oh, it's a windows
problem, so sorry, we can't fix" is a common one. I think the first step
would be to track down the source of the most accessibility problems. Is
it at-spi? Gtk+? Some of the layors in between? Then fix the most
glaring problems first.
Thanks
Kendell clark


MENGUAL Jean-Philippe wrote:
> Hi,
>
> It's a common assessement: if free software isn't accessible, it's not a
> screen reader problem, but the app which doesn't send good info to at-spi.
>
> ok. How to fix this? Explaining, bug reporting, etc. One idea is
> hackhaton. We did one this week-end in Paris. We studied Audacity and
> Linphone: 2 GTK apps, where essential issues are related to labels,
> focus movements with keyboard, etc.
>
> But I realise that I have not a lot of further ideas of simple apps to
> improve. I plan mumble, and other more complex things such as
> libreoffice or Firefox, so complex for a general-hackhaton.
>
> Do you have ideas of apps on which we could report accessibility bugs
> during an hackhaton, or help fixing, in GTK? Can you tell me apps you
> don't access to (or access just partially)? And what is it for? No
> alternative?
>
> It'll give me ideas for next hackhaton/bugreports. If they're in GNU
> project, still better.
>
> Thanks for feedbacks,
>
> Regards,