Re: [g-a-devel] Coming to grips with the state of a11y in GNOME

[Mario Lang <mlang delysid org>]

Matthias Clasen <matthias clasen gmail com> writes:

> The screen reader, orca, clearly is our 'flagship' AT. In my recent
> experience with orca, it worked surprisingly well and spoke to me for
> hours. The impression I got was much better than I had expected. In
> earlier attempts (sometime during 3.1.x), it randomly stopped speaking
> to me and I was unable to make it speak again.
>
> Problems I've seen today include
>
> - gnome-shell crashes when orca is restarted
>
> - interacting with treeviews while orca is running easily crashes
> (just select a file in the file chooser in any app...)
>
> - people have also seen gnome-terminal crash with orca
>
> - Insufficient labelling in new UIs, e.g gnome-shell is largely just
> 'panel' to orca...
>
> - Lack of a11y support in 3rd party widgets (stock widgetry in
> evolution is read just fine to me, but I don't hear any of the
> 'interesting' things: subjects, senders, email bodies...)
>
> - I couldn't get a word out of firefox - I thought maybe my gtk2 a11y
> stack was misconfigured, but openoffice did speak...
>
> What are the problems ?
> -----------------------------------
>
> Toolkit accessibility (ie the loading of atk-bridge into GTK+ and
> Clutter applications, as controlled by the toolkit-a11y gsetting) is
> too broken. We cannot turn something on by default that lets you crash
> any application in the file chooser.

I think the current crashes are a logical consequence of ripping out
CORBA and reimplementing the complete AT backend anew.
These bugs have been present in early CORBA-ATSPI days as well,
and have been fixed over time.

I think the new D-Bus AT-SPI layer needs a bit more time to stabilize.

Its current problems should definitely not be taken as an argument to
trash the wonderful GNOME accessibility support now.
It would be a shame in my opition.

> What are our options ?
> --------------------------------
>
> Possible remedies include:
>
> - Change approach
>
> Instead of 'special interface for the 1% of users that really need
> it', go for something that is useful for everybody, then add the few
> a11y extras that get you from 'can be used by 80%' to 90%, then 95%,
> ...
>
> - Reduce scope
>
> Look at what concrete ATs actually use, instead of clinging to some
> overly broad inherited 'standard' interface.
> My guess is that this will boil down to mainly text + focus.

I would find it extremely sad if these options were persued.

GNOME is really the only desktop on Linux so far that has done
accessibility right from the start.  Other desktops
have demonstrated that you can get some percentages of users covered
with "cheap tricks", but you end up excluding a few people in general.

I've always loved GNOME for not doing this and going "the hard way" to
actually achieve relatively good, and especially full-featured,
accessibility support for users like me (100% blind).

I dont think it is a good idea to cripple toolkit accessibility.
Yes, the interfaces are complex, but that is because they are solving a
relatively complex problem.  If you reduce the functionality, you
deliberately exclude a certain class of users.  I know the arguments
that this is a small percentage, but you should realize that for these
users, GNOME is currently the only option for an up-to-date program
stack.

-- 
CYa,
  ⡍⠁⠗⠊⠕