I really want to add a keyword of "accessibility" to this bug, but I
don't see how to do that from the web page I'm given at
http://www.openoffice.org/issues/show_bug.cgi?id=62723

FileOpen dialog is Framework component.

TM->FS: Please have a look, thanks !

fs->pl: The Z-Order in the dialog is
- "File type" (fixed text)
- filter list (list box)
- "Read-only" (check box)

Nonetheless, the check box'es GetLabeledBy returns the fixed text. It should
return NULL, shouldn't it?

s/Z-Order/Taborder/, yes ? If so, that is not broken; a label is considered the
last FixedText, FixedLine or GroupBox in taborder before the control itself.
Whether that is a good algorithm may be debatable, but that works as designed.
This algorithm basically was decided by MT, so maybe we should discuss this with
him.

The only places which use this function are the A11Y implementations. For those
cases, the current semantics is nonsense, as it contradicts the sematics of the
A11Y LABELED_BY relationship.
So, we can either
- have the current GetLabeledBy method function in VCL, and translate its
  results in A11Y-conformant results in all A11Y implementations
OR
- fix the VCL-version of GetLabeledBy to be A11Y-conformant.

To me, the latter sounds like the better solution.

That is beside the point, what is your proposed new algorithm ? Do checkboxes
label themselves ? Do checkboxes not have labels ? What other controls should be
changed ? Remember I'm not the customer of GetLabeledBy; i can probably do a lot
as long as you come up with some requirements.

fs->mt,pl: The text in Window::GetLabeledBy currently reads:
  // search for a control that labels this window
  // a label is considered the last fixed text, fixed line or group box
  // that comes before this control; with the exception of push buttons
  // which are labeled only if the fixed text, fixed line or group box
  // is directly before the control

I could imagine the following solutions:
- what is done for buttons here should also be done for check boxes. This would
  fix this particular bug here, but does not scale to similar problems.
- A fixed text, fixed line, or group box is *only* considered a label of a
control if it
  immediately precedes the control. The idea is: if the order is "fixed text",
  "control A", "control B", then either the fixed text labels control A (but then
  most probably *not* control B, at the same time), or control A is a label control
  itself, then it labels control B.
- All places which use GetLabeledBy for A11Y relationships are modified so that
  they check that "GetLabeledBy( control )->GetLabelFor() == control" holds true.
- We explicitly implement A11Y's LABELED_BY / LABEL_FOR relationships for
  all controls in all our dialogs. Okay, just kidding.

What do you think?

fs->pl: as talked about, please discuss a better algorithm with MT. After my
vacation, I'm willing to join the discussion, if necessary :)

As per mt's decree check boxes and radio buttons do not have accessibility
labels anymore.

pl->es: please have a preliminary look at this issue; i didn't find any
problems, however i'm not an accessibility guru like you. I built linux and
windows install sets for CWS vcl57, so you can check whether this causes any
accessibility related problems.

fixed in CWS vcl57

Just for clarification: My "decree" was to check how standard gnome dialogs
behave here.

So I assume that PL figured out that they don't have lables (because they are
'self labled').

please verify in CWS vcl57

Verified in CWS vcl57

Ok in src680m168

*** Issue 63984 has been marked as a duplicate of this issue. ***

*** Issue 63985 has been marked as a duplicate of this issue. ***

*** Issue 63981 has been marked as a duplicate of this issue. ***

*** Issue 63980 has been marked as a duplicate of this issue. ***