Bug 149426 - [CellEditors] TextCellEditor has no name
Summary: [CellEditors] TextCellEditor has no name
Status: RESOLVED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eric Moffatt CLA
QA Contact:
URL:
Whiteboard:
Keywords: accessibility
Depends on:
Blocks:
 
Reported: 2006-07-03 02:38 EDT by Mihoko Aoki CLA
Modified: 2006-08-30 10:26 EDT (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mihoko Aoki CLA 2006-07-03 02:38:25 EDT
TextCellEditor, which is one of cell editor implementations provided by the org.eclipse.jface plugin, has a Text widget in a cell editor. However, it seems that the Text widget has no accessibility name.

it will make software using TextCellEditor fail accessibility and it may make Eclipse fail as well.
Comment 1 Karice McIntyre CLA 2006-07-05 13:11:15 EDT
Assistive technologies (like JAWS) will read the contents of the cell editor when it is created - this is the most crucial element that must function where accessibility is concerned.  I am not sure what generic name could be provided on the text cell editor that would be useful info to convey to the user.  Perhaps in the case that there is no text (empty string) this would be useful, but other than that the info the user needs (the contents of the text editor) is conveyed to the user via the screen reader.  Also note that clients can use the getControl() method to set an accessible name, if required.
Comment 2 Mihoko Aoki CLA 2006-08-02 22:12:21 EDT
Yes, I think that we can manually add AccessibleListener to provide an accessibility name, getting accessible object by getControl().getAccessible().
However, I'm afraid that everyone using TextCellEditor will become to have similar code to add AccessibleListener in each component.
And, TextCellEditor is one of not abstract classes but concrete classes. It may be difficult to impose such a kind of implementation to all people using TextCellEditor.
Comment 3 Eric Moffatt CLA 2006-08-03 15:25:32 EDT
What is the 'accessibility name' supposed to represent (i.e. how does it provide meaningful information to the person using it? The TextCellEditor is a generic control used whenever a table or property view needs to modify text values so it doesn't really have a single semantic binding (as, for example, a "Name" edit field in a dialog would).

Do you have any suggestions as to what we might use and/or whether it should change based on where it's being used?
Comment 4 Mihoko Aoki CLA 2006-08-04 01:26:16 EDT
yes, I agree with that the TextCellEditor doesn't have a single semantic binding. However, I think that the default generic name is necessary for Text widget used in TextCellEditor, and it's also better to provide the way to override the name when necessary. Ideally, the most appropriate name should have been provided by users of TextCellEditor. However, TextCellEditor has already had many users. It's too difficult to impose such additional implementation to all of existing users. As one of actual solution, I think that the default name is needed, such as "Value:", "Edit:" or something like that.
Comment 5 Steven Wasleski CLA 2006-08-22 17:40:30 EDT
Eric, with regard to comment 4, would adding a default 'accessibility name' be something that could be considered for 3.2.1?
Comment 6 Eric Moffatt CLA 2006-08-23 11:01:54 EDT
We have -no- way to ensure in what context a CellEditor is being used. While we have some mechanisms that use them (i.e. The Tasks View and the PropertySheetPage) we don't know if other clients are using them.

This means that we can't 'guess' as to what the accessiility 'name' should be (and shouldn't try). The appropriate mechanism is the one described in comment 2.
Comment 7 Steven Wasleski CLA 2006-08-23 11:56:53 EDT
That is what I thought.  Thanks for the update.
Comment 8 Mihoko Aoki CLA 2006-08-25 06:04:28 EDT
I'd like to confirm one thing. Don't you prepare any default implementation to add AccessibileListener to Text widget? I mean, a new constructor or public method (e.g. setTextName method) to assign a name to Text widget is very useful for users of TextCellEditor. If not, every users would have to create similar implementation of AccessibileListener in each components. I'm afraid that users would tend to miss assigning an appropriate name to Text widget of TextCellEditor for the present. To avoid that, adding a new constructor or public method could be a kind of help to remind users that they have to assign a name of Text widget by themselves.
Comment 9 Mihoko Aoki CLA 2006-08-30 07:43:28 EDT
I have additional question. It seems that TextCellEditor has been used in many parts of Eclipse as is. It would be accessibility violation against the following checkpoint.

http://w3-03.ibm.com/able/devtest/swlabels.html

>Labels
>Software checkpoint 2.3
>
>Associate labels with controls, objects, icons, and images. If an image is used to identify programmatic elements, the meaning of the image must be consistent throughout the application.

For exapmle, Eclipse has the Tasks view. After users add a task on the Tasks view, they can edit the added task directly by cell editors on the view. For the Description column, TextCellEditor has been assigned. TextCellEditor has been used as is. So, the text field in TextCellEditor has no name on the Inspect32 tool. Isn't it a kind of accessibility violation?

I found other examples of use of TextCellEditor which can be assumed as accessibility violation. I think that changes to fix all of them will be necessary, in order to make Eclipse satisfy software accessibility. What do you think about that?
Comment 10 Steven Wasleski CLA 2006-08-30 08:58:08 EDT
Aoki-san, thank you for looking at these other areas.  Please open separate bug reports against the appropriate components.
Comment 11 Steven Wasleski CLA 2006-08-30 10:26:20 EDT
With regard to my comment 10, please take comment 1 into account.  Any bugs you opened may not be accepted as accessibility bugs since screen readers like JAWS and Window Eyes will read the contents of the cell editor.  All accessibility guidelines I have seen state that the screen reader working is sufficient even if the object inspection tool fails.