clu->obr: like i agreed with es this is a rather general problem by design, that
we have in many different places in the office (especially in wizards) where we
use arrow symbols etc. and a reader reads things like: 'greater than, greater
than' - this happens with zoom text, too. please make a final decision for such
cases and let us known about, because this seems to be an application
independent problem.

thx

set to 'new'

I have submitted several RFEs to introduce those buttons in VCL / UNO toolkit
and also issue 70296 to have a generic interface to manually override the
default accessibility information for UI implemented using the UNO toolkit.

It should already be possible to set the missing LABELLED_BY relations using the
UNO Accessiblity API now.

Basically I set the AccessibilityName at the VCLWindowPeer for all these
controls and this always worked fine.
So this issue is broken. I will consult MT how to go on with this issue

.

bc: Setting target to OOo2.3

bc: resetting target to OOo 2.x

bc->obr: I set the AccessibilityName but it seems that this is not passed
through to the screenreader.

obr->bc: please read the bug description again: this is about the accessible
description, not the accessible name (even though I did not know about the
existing property approach in UNO AWT initially).

* on the first panel, the description of the first 4 buttons mentioned is:
  "Displays all fields that will be included in the new table", which seems to 
   be the description of the panel.

  Button [ ^ ], [ V ] look good to me though.

* on the second panel, the description of the first 2 buttons mentioned is:
  "The table wizard helps you to create a database table". The same text is 
  used for [ Next ], [ Back ], [ Finish ], [ Cancel ].

  Button [ - ], [ + ] look good to me again and even the LABELLED_BY relation     
  is there now.

All this seen on a CWS based SRC680 m215.

The source of the problem seem to be wrong/missing help ids for those buttons in
wizards/com/sun/star/wizards/ui/fieldselection.java line 212
(thanks to OJ for identifying the problem).

I once again verified the help-ids of all controls in question and could not
detect anything wrong about it. So as far as I can see my implementation
contains valid  help-ids and valid AccessibilityNames. What else am I to do?

The Online Help displayes e.g. the following string for the [ >> ] button:

"Click to move all fields to the box the arrow is pointing to."

A search in helpcontent2 for this string reveals:

helpcontent2/source/text/shared/autopi/01090100.xhp
helpcontent2/source/text/shared/autopi/01100100.xhp

AB, MT, UFI: can anyone of you shed some light on why the Online Help is able to
find the correct text for those buttons and the toolkit implementation of
AccessibleDescription is not ?

Ufi's comment: I don't know about the AccessibleDescription texts. Berend might
know. 
The text you quoted is part of the extended help text for the controls. I
changed those texts due to issue 73704 in May 2007. The changes got integrated
in September 2007.

bc->cd: As discussed -> to you

cd: Changed target.

cd: As this is an important accessibility issue set target to next upcoming
release (OOo 3.0).

cd: Accepted.

cd: The current state of this issue is:
There are accessible descriptions for the table wizard controls, but some of
them have definitely wrong descriptions. It's also strange that most of them
share a single description from the "Selected Items" control. All controls have
a help ID so there must be a mapping problem between help ID and help text or
wrong help text. At least I cannot find a problem within the toolkit/vcl
implementation. Even the extended help for this dialog uses the wrong help texts
for the controls. LLA and I will clarify the root cause for the wrong help
text/accessible description.

AFAIK the extended help text has absolutely nothing to do with the
AccessibilityName and AccessibilityDesciption. So don't look at the extended
help text with regard to this accessibility issue.

You write "Even the extended help for this dialog uses the wrong help texts
for the controls. LLA and I will clarify the root cause for the wrong help
text/accessible description."
The help file is text/shared/explorer/database/tablewizard01.xhp, and the reason
for the wrong help texts is well known. It is NOT related to accessibility. It
is http://www.openoffice.org/issues/show_bug.cgi?id=48946 and obviously I
overlooked this file - will fix that in the next CWS.

cd->ufi: Uwe, the current implementation within the Window base class uses the
function GetHelpText() for the accessible description. That's a fact. Please
look at the implementation yourself.

String Window::GetAccessibleDescription() const
{
	String aAccessibleDescription;
	if ( mpWindowImpl->mpAccessibleInfos &&
mpWindowImpl->mpAccessibleInfos->pAccessibleDescription )
	{
		aAccessibleDescription = *mpWindowImpl->mpAccessibleInfos->pAccessibleDescription;
	}
	else
	{
		// Special code for help text windows. ZT asks the border window for the
		// description so we have to forward this request to our inner window.
		const Window* pWin = ((Window *)this)->ImplGetWindow();
		if ( pWin->GetType() == WINDOW_HELPTEXTWINDOW )
			aAccessibleDescription = pWin->GetHelpText();
		else
			aAccessibleDescription = GetHelpText();
	}

	return aAccessibleDescription;
}

cd->lla: Please take over. I think this issue is now only dependent on 48946
which must be fixed by ufi.

So thank you for telling me that extended help text is used for accessibility
texts. No one ever told me before.
Issue 48946 is set to WONTFIX. I cannot do any string changes for 3.0 any more,
next changes will be for target 3.1.

Will fix assignment of Help IDs in CWS hcshared19, issue 48946

Found out the real problem:
There was used 'AccessibilityName' instead of the right 'AccessibleName'
property, now it works like a charme.

@ufi, nothing to be done for translation, because all texts are there.

There exist no CWS to insert, because I'm having to wait for rptwizard01 to be
integrated in the MWS so please be patient.

fixed

Verified.

AccessibleName corrected but Orca (2.20.1) still reads "greater then" because it
is the accessibleTetx.

The wizard sets the 'AccessibleName' property, which is of the 'greater than'
button: 'Add field'.

The other values are:
'Add all fields'
'Remove field'
'Remove all fields'
'Move field up'
'Move field down'

Orca v2.20.2 is quite old in terms of Orca development.

Any chance you could verify these bugs against the latest version of Orca?
You can either get this from trunk in the SVN repository, or via tarball.
The last tarball released version is Orca 2.23.4. 

See:
http://ftp.gnome.org/pub/GNOME/sources/orca/2.23/

See also:
http://live.gnome.org/Orca/DownloadInstall

for more details on how to download and install Orca.

Thanks.

ok, I have installed the new orca 2.23.4 on my linux but it stops working after
short period of time due to an unknown problem:

Orca watchdog detected something bad. Cleaning up.
/usr/bin/orca: line 92:  5109 GOrca watchdog detected something bad. Cleaning up.
/usr/bin/orca: line 92:  5109 Getötet                /usr/bin/python -c "import
orca.orca; orca.orca.main()" "$ARGS"
etötet                /usr/bin/python -c "import orca.orca; orca.orca.main()"
"$ARGS"

Maybe I need Gnome desktop, @the moment I use KDE.

- Also I don't know what really to do, to get orca working together with soffice. 
- I checked with gconf-editor that in Desktop - Gnome - Interface the a11y
checkbox is checked.
- But Orca don't show any A11Y information after soffice is started.

Yes, you will need to be running GNOME. 

Orca will try to speak/braille the application that currently has focus.
If that is soffice, you then use the keyboard to navigate to the various
components that are being shown. That is why keyboard navigation of all
areas is so important, and one would hope obvious, to the Orca users.

There are also various keyboard shortcuts, to move around the GNOME
desktop etc.

I have done installed Gnome and also start it. With started orca I see lot of
text in the 'window mode' braille line if office is start.

Is it normal that I see something like 'knpf' instead of 'knopf' or 'dlg'
instead of dialog?

Also '> knpf' is coming on the Wizard Button, therefore orca is not be able to
show the 'AccessibleName' property content as expected. It use something else :-(

Also it is useless that I have to use Gnome, due to the fact I hate Gnome (this
had historical reasons), I love KDE and all tools which don't be able to run in
KDE environment are useless tools.

>Is it normal that I see something like 'knpf' instead of 
>'knopf' or 'dlg' instead of dialog?

In looking at the German translation file, I see that "knpf" is the short
braille for the push button rolename and "Schaltfläche" is the long braille.  By
default, Orca should use the long braille for rolenames, and I just verified it
seems to be doing so.  Did you make any changes in your Orca preferences to use
short braille for rolenames?  It would be in the "Braille" tab of the Orca
preferences GUI.

>Also '> knpf' is coming on the Wizard Button, therefore orca is not be 
>able to show the 'AccessibleName' property content as expected. It use
>something else :-(

We have made the general rule of thumb that if there is accessible text being
presented by an object, Orca presents that text since it is a *screen* reader.
There has been some discussion about giving priority to the accessible name if
it exists (which is what you've done in this case -- thanks!), but we have run
into cases where the accessible name is programmatic garbage.  As such, we've
been better off giving priority to the accessible text instead.

I'll talk about alternative approaches with our UI person. Some options might
include:

1) Using images instead of text for the buttons in question.  With this, Orca
will fallback to the accessible name, which is the main reason accessible name
exists.

2) Making the new strings accessible descriptions or tooltips that the user can
get to via Ctrl+F1 when then button has focus and/or via Orca's "Where Am I"
functionality.

In discussing this with our UI designer (who is also a user), the preferred
method would be to not use text characters for representing arrows.  Instead,
images with accessible names/descriptions would be preferred.

Failing that, Orca is a screen reader and will read the text being presented to
the user.  We appreciate the addition of the accessible names, however, but
kindly request that the given strings be used for the accessible description of
the object instead of the accessible name.  With this, the Orca user will be
presented with the visual text that sighted users see and they can use the
"Where Am I" functionality of Orca to obtain the accessible description for more
information.

Thank you for your work!

as I understand the lasst comment

verified -> closed