Re: [orca-list] SWT (Standard Widget Toolkit) for Java platform accessibility

Are there any stand-alone SWT example applications we can use to test the accessibility? Eclipse is too complicated to evaluate since it shows too many controls without names in accerciser.


Michael Whapples wrote:
On Mon, 2008-07-28 at 07:40 -0400, Willie Walker wrote:
Hi All:

Just curious if anyone has had a chance to work with this widget set or an application that uses this widget set.

I use eclipse regularly, and I think that is done in SWT.

If so, what has your accessibility experience been with respect to things such as: 1) honoring theming,

I am not sure, are themes just visual, if so then I won't notice being a
speech and Braille user.
2) keyboard navigation,

Key board navigation seems good. Seems to behave very much like a GTK
application. I don't know whether this is that the eclipse developers
have ensured this is so, as I know they have implemented many keyboard
shortcuts (eg. move to problems screen, package explorer, move to
console window, etc).
3) access via Orca,

Eclipse is useable, but there are occasions when it doesn't do what you
might expect (I have filed some bugs against orca for some of these).
Examples of problems are:
When code completion is used or eclipse does some code completion for
you and you are back in the edit mode (IE not in the list of
suggestions) the completion is not shown in braille until something like
a semicolon (;) is done or you move away and back to the line. When the
code completion isn't shown, the interesting thing is that the cursor
moves, but the edit marker (the $l) doesn't, so it appears the cursor
has moved outside the control in Braille. If you cursor left or right
through the code completion then speech tells you the character you are
moving over, and the Braille cursor moves, but the control appears in
Braille as before (IE showing the text upto where the code completion
was done).
Braille cursor routing doesn't work (certainly in the code editor, but I
think in other edit areas as well).
Sometimes the tree views don't always report the right thing (not sure
if orca is at fault or eclipse). This problem doesn't always show
itself, but when it does show itself it seems to be when the selected
item is at a higher level in the tree than an item physically further up
in the list (eg. if the selected item is at level 1, and if you were to
press up cursor you would get to a item at level 5).
I used to have a problem with Braille being updated in the eclipse
console window, but I haven't seen that for sometime and my version of
eclipse has been updated since the last time I saw it, so I don't know
whether it was a problem caused by eclipse which might have been fixed,
or if it was to do with how I was using eclipse, or if I have simply
been lucky (as it was a problem which showed itself occasionally when I
did find it).

I know that eclipse may not be the best example application for many
reasons (eg. its size and complexity, as well as the fact that I know
that eclipse developers have done work on accessibility, so may not be
representative of standard accessibility). Nevertheless I hope this is
useful as a start.

gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]