Issue 63979 - The User Data options pane is confusing when read with a screen reader.
Summary: The User Data options pane is confusing when read with a screen reader.
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 2.0.2
Hardware: Sun All
: P3 Trivial (vote)
Target Milestone: OOo 3.0
Assignee: eric.savary
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks: 78653 90510
  Show dependency tree
 
Reported: 2006-04-04 16:05 UTC by richburridge
Modified: 2010-11-10 16:32 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description richburridge 2006-04-04 16:05:49 UTC
This is with Solaris x86 (Nevada b34), with JDS/GNOME vermillion_08
build and with StarOffice 8, build m161 (with the new UNO/atkbridge).
Tested with the Orca screen reader.


Bringup Tools->Options

The StarOffice->User Data pane has many occurances where multiple
text fields have the same single label, therefore making it confusing
what is required where.

In particular:

The "First/Last name/Initials label is used for the following three
text fields. There should be a separate specific spoken description
for each of the three test fields when read by a screen reader.

Similar problems with:

City/State/Zip and the following three text fields.
Title/Position and the following two text fields.
Tel (Home/Work) and the following two text fields.
Fax / E-mail and the following two text fields.

(This bug needs a keyword of "accessibility" added to it).
Comment 1 thorsten.martens 2006-04-05 07:53:35 UTC
TM-ES: please have a look, thanks
Comment 2 eric.savary 2006-06-22 13:58:54 UTC
ES->OBR: I do agree with Richard on the lack of comfort of those 3 (x2)
EditBoxes labeled with only 1 Label. But I doubt that we can technically split
those labels in 3 labels (L10n!). WONTFIX?
Comment 3 richburridge 2006-06-22 19:49:37 UTC
Comment from Will Walker:

I wonder if we could make Orca work if OOo does the following for
these types of situations:

   1) Do *not* set the label for/by property
   2) Set the accessible name appropriately 

For example, given this:

   First/Last name/Initials ________ ________ ___

Don't associated "First/Last name/Initials" with anything.  Instead,
make the accessible name of the first field, "First Name", the
accessible name of the middle field, "Last Name", and the accessible
name of the last field, "Initials".   Orca should be able to handle this
appropriately.
Comment 4 nospam4obr 2006-06-23 09:52:59 UTC
Peter, are you the maintainer of Tools-Options ? If so, do you think Will's
suggestion is feasible ?
Comment 5 pb 2006-07-21 06:10:34 UTC
pb: change target to 2.x.
Comment 6 Mathias_Bauer 2007-12-04 16:17:46 UTC
according to release status meeting -> target 3.x
Comment 7 pb 2008-06-10 04:59:55 UTC
pb: I try to fix it for 3.0.
Comment 8 pb 2008-06-24 07:36:46 UTC
pb: fixed in cws pba11y01.
Files changed:
/vcl/inc/vcl/window.h 1.6.66.1
/vcl/inc/vcl/edit.hxx 1.7.66.1
/vcl/source/control/edit.cxx 1.96.66.1
/vcl/inc/vcl/fixed.hxx 1.4.66.1
/vcl/source/control/fixed.cxx 1.23.66.1
/vcl/source/window/dlgctrl.cxx 1.27.62.1
/vcl/source/window/window.cxx 1.278.64.1
/svx/source/dialog/cuioptgenrl.hxx 1.5.112.1
/svx/source/dialog/optgenrl.cxx 1.13.112.1
Comment 9 pb 2008-07-16 13:13:22 UTC
pb -> es: please verify. Thx.
Comment 10 eric.savary 2008-07-16 15:31:10 UTC
Hi Will, Peter, Oliver!

Well I'm not really satisfied with the fix...

1) not using the labels causes the Braille monitor to only show "$ |".
Before the fix it was for instance "Company || $ |"

2) it looks like the names are automatically retrieved using "/", thus:
First name ---- now ----> "First" (should be "first name")
Tel (Home/Work) ---- now ----> "Tel Home" and "Work" (should be "tel home" and
tel work)

Considering this fix is part of a showstopper CWS, do we want to accept this
like this and fix the rest later or fix now?
Comment 11 williewalker 2008-07-16 15:42:18 UTC
Thanks for working on this!  Ideally, a single label would not be used to label
three separate text areas -- if that can be changed to have one label per area,
things would be much better.  :-)

Failing that, the problem happening with #1 is that in braille, Orca is
currently not falling back to the object's name if a label cannot be found.  We
currently do this for speech and can modify braille to do the same.

I'm confused about comment #2 -- is the reference to what OOo is doing
internally to get the names or an assumption about what Orca might be doing?

Finally, maybe we're making way to big a deal out of this and the behavior was
acceptable (not optimal, but acceptable) all along.  I'll consult with the Orca
UI person on this and get back to you.

Comment 12 eric.savary 2008-07-16 16:30:50 UTC
Thank you for your explanation!

I'll set as VERIFIED.

If we need to change/improve something, we can do it later.

Verified in CWS pba11y01
Comment 13 thorsten.ziehm 2009-07-20 14:51:58 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. The fixed issue should be integrated in OOo since more than half a year. If
you think this issue isn't fixed in a current version (OOo 3.1), please reopen
it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues
Comment 14 hartsambatchvolv 2010-11-10 16:32:11 UTC
Created attachment 73211