Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 320062 - Use preceding Label as accessible name for Table and Tree
Summary: Use preceding Label as accessible name for Table and Tree
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 3.7   Edit
Hardware: PC Windows All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Carolyn MacLeod CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
: 289199 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-07-16 00:32 EDT by Carolyn MacLeod CLA
Modified: 2019-11-27 07:27 EST (History)
4 users (show)

See Also:


Attachments
Patch for default name for table and tree (4.77 KB, patch)
2010-08-24 12:21 EDT, Carolyn MacLeod CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carolyn MacLeod CLA 2010-07-16 00:32:08 EDT
If a Label precedes a Table or Tree in the z-order (i.e. the Label must be a sibling of the Table or Tree, and it must have been created immediately prior to the Table or Tree) then the Label's text can be used for the default accessible name for the Table or Tree.
Comment 1 Carolyn MacLeod CLA 2010-07-16 00:33:36 EDT
We currently plan to make this work in 3.6.1 and 3.7.
Comment 2 Carolyn MacLeod CLA 2010-08-24 12:21:36 EDT
Created attachment 177340 [details]
Patch for default name for table and tree

Here is the patch, just so that it is not lost.
However, I will not be committing this for 3.6.1 because:
1) Table and Tree already name already defaults to the text of the preceding Label
   even without the patch (for some reason, Tree with columns does not default).
2) JAWS does not speak the name for a Table or Tree, even though it is there
   (it just speaks the name of the focused item, and headers if any).

I am leaving this bug open to continue investigating for 3.7. (i.e. look at other screen reader behavior; perhaps determine why Tree with columns does not have a name).
Comment 3 Carolyn MacLeod CLA 2010-08-24 12:39:24 EDT
3.7 investigation:

1) Tree with columns does get a default name *with* the patch.
2) NVDA speaks the name of all Trees and Tables that have a name.
   (i.e. it speaks the control name first, followed by the item name).
3) Window-Eyes speaks Tree names, but not Table names.
4) The Microsoft (MSDN) doc for TreeView and ListView says,
   "The Name property is obtained from the control's window text (or caption)."
   (i.e. it does NOT say anything that would indicate the behavior I am seeing.
   For example, here is what it says for an EDIT control:
   "The Name property is the text from a static text control that labels the edit control.")
   In other words, I am seeing unspecified behavior for Table and Tree. (on WinXP)
Comment 4 Carolyn MacLeod CLA 2011-05-16 11:14:12 EDT
Removing target milestone.
Comment 5 Carolyn MacLeod CLA 2012-03-21 14:48:27 EDT
*** Bug 289199 has been marked as a duplicate of this bug. ***
Comment 6 Dave Steinberg CLA 2012-07-17 18:52:08 EDT
Carolyn,

Given what you've discovered, could you offer any advice to developers using Tables today?

It sounds like if we want to have the Table report the preceding Label as its text, we would need to use an AccessibleListener to do that. However, it also sounds like that won't really help, since JAWS won't actually speak the name of a Table (or Tree).

So for now, I'm inclined to just use a read-only Text in place of a preceding Label. That seems a somewhat less than ideal solution, but I suppose it's the best we can do.

Would you agree?
Comment 7 Lars Vogel CLA 2019-11-27 07:27:32 EST
This bug hasn't had any activity in quite some time. Maybe the problem got
resolved, was a duplicate of something else, or became less pressing for some
reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it.
The information can be, for example, that the problem still occurs, that you
still want the feature, that more information is needed, or that the bug is
(for whatever reason) no longer relevant.

If the bug is still relevant, please remove the stalebug whiteboard tag.