Re: [orca-list] Accessibility of apps

[Peter Vágner <pvdeejay gmail com>]

Hello,

If you have a capable developer or two I would rather start with simpler 
tasks if I were you.

For example take file-roller and engrampa as a base and make sure it is 
possible to inwoke files view context menu with the keyboard only i.e. 
by pressing the applications key. I am sure for clever GTK developer 
this would be simple hackathon style project and you will contribute 
significant fix to two apps at once with minimal possible overhead and 
you will increase a bit of a11y related awareness within GNOME and Mate 
teams.

Another a bit more difficult but still doable thing would be 
contributing to Brasero. It has an issue that its file dialog and other 
views whele files are displayed don't react to keyboard presses it only 
reacts to hardcoded mouse clicks. For example create a new data disc 
project in Brasero, from its edit menu open Add files dialog, and in 
that dialog try to enter any folder. You will find you can't unless you 
will resort to mouse emulation.

These are apps which are stable for years with minimal changes so it's 
very likelly you won't cause conflicts etc.

Then another very very cool project would be looking to pcmanfm code, if 
you like I can give you some commits where you should start at and based 
off of that creating an ATK support for playlist view for DeaDBeeF music 
player.

I think debugging Gecko and other Mozilla things or libreoffice is an 
overkill for home office style developers. They will soon realize that 
there is better fix or a lot of more work needed plus it requires a lot 
of studying. I really think we should start with much more simple things 
once we will become proficient enough to be recognized by the Mozilla or 
Libreoffice teams.

Greetings

Peter


On 20.02.2016 at 17:56 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,