| Summary: | Accessibility : Cannot set tooltip Text for image in Table Column | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | David Taieb <david_taieb> | ||||
| Component: | SWT | Assignee: | Carolyn MacLeod <carolynmacleod4> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | dbennett, EclipseSPRTrackers, fplante, frank_smith, jan.von.loewenstein, keri_tuttle, Kevin_Haaland, sayoub, snorthov, steven.wasleski, Tod_Creasey, vramaswa | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.3 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
David Taieb
Is the table in the Windows File Explorer 508 compliant? No, the windows file explorer doesn't show alt text. From what I am seeing in Windows File Explorer you are looking at a tree view, not a table view (unless I am looking at the wrong thing). If we can't add alt-text to the image is there any way to distinguish when the image is different, like Information: then the text or Error: then the text. Also is there any other image that is used in this section or is it only the X. This might make a difference on whether or not we need alt-text for the image or not. What is "alt text"? What is an "Alt+text tooltip"? FYI, the Windows File Explorer has both a Tree view (on the left) and a Table view (on the right). I do not know what you mean when you say "Also is there any other image that is used in this section or is it only the X." - what section? - what X? What table are you really looking at? Let's talk about a concrete example. Here is a snippet that shows how to create a Table with 3 TableColumn's. Each TableColumn has both a tooltip and an image. The tooltip works fine when there is an image. Please modify this snippet to show the problem you are having, because I'm afraid I can't tell from the previous discussion what the problem is.
import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.layout.*;
public class TableColumnIconAndTooltipTest {
static Display display;
static Shell shell;
static Table table;
public static void main(String[] args) {
display = new Display();
shell = new Shell(display);
shell.setLayout(new GridLayout());
table = new Table(shell, SWT.MULTI | SWT.FULL_SELECTION);
table.setLayoutData(new GridData(GridData.FILL_BOTH));
table.setHeaderVisible(true);
for (int col = 0; col < 3; col++) {
TableColumn column = new TableColumn(table, SWT.NONE);
column.setText("Column " + col);
column.setWidth(100);
column.setToolTipText("Tooltip for Column " + col);
column.setImage(display.getSystemImage(1 << col));
}
for (int row = 0; row < 5; row++) {
TableItem item = new TableItem(table, SWT.NONE);
for (int col = 0; col < 3; col++) {
item.setText(col, "item" + col + row);
}
}
shell.pack();
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) display.sleep();
}
}
}
I was reading over the comments and I was a bit confused as to what was going on. I am the QE person that originally found the problem in our code, so I thought maybe I would explain what I was looking for and then maybe you could let me know if there is a fix or workaround possible. For our Accessibility checklist we need to have Alternate text (also known as a tool-tip) for any image that does not have associated text and conveys important information. What I found in our code is that in the Errors tab /Problems tab there are some images in the left hand column that distinguish a description between an error or warning. Since this image states information that is not available in the description the image should have alternate text to show what type of error. The alternate text is then used by a screen reader to state whether the description is for an error or warning etc. Is there some way to assign alternate text to the image in the column? Created attachment 37646 [details]
Problems View
I agree that this is a bug in eclipse. I do not know of a way to give a tooltip to a table item (setTooltipText is only defined for the table or the columns). However, there is a way to prepend some useful text to the "name" that can then be spoken by the screen reader. Here is a modified version of the snippet from comment 5 to show how this can be done. import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.accessibility.*; public class TableColumnIconAndTooltipTest { static Display display; static Shell shell; static Table table; public static void main(String[] args) { display = new Display(); shell = new Shell(display); shell.setLayout(new GridLayout()); table = new Table(shell, SWT.MULTI | SWT.FULL_SELECTION); table.setLayoutData(new GridData(GridData.FILL_BOTH)); table.setHeaderVisible(true); for (int col = 0; col < 3; col++) { TableColumn column = new TableColumn(table, SWT.NONE); column.setText("Column " + col); } for (int row = 0; row < 5; row++) { TableItem item = new TableItem(table, SWT.NONE); for (int col = 0; col < 3; col++) { item.setText(col, "item" + col + row); item.setImage(display.getSystemImage(row < 3 ? SWT.ICON_ERROR : SWT.ICON_WARNING)); } } for (int col = 0; col < 3; col++) { TableColumn column = table.getColumn(col); column.pack(); } table.getAccessible().addAccessibleListener(new AccessibleAdapter() { public void getName(AccessibleEvent e) { if (e.childID > ACC.CHILDID_SELF) { String severity = e.childID < 3 ? "Error: " : "Warning: "; e.result = severity + e.result; } } }); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } } Just for info, did you happen to notice that problems in the Problems View can now be grouped by severity? (as of M5). This is because the Problems view now contains a Tree with columns, not a Table. Here's the "New and Noteworthy" for M5. Find the text "Problems View" in here: http://fullmoon.ottawa.ibm.com/eclipse/downloads/drops/S-3.2M5-200602171115/eclipse-news-M5.html Are you running the latest eclipse? This doesn't help much, but if the problems are grouped by severity, and if the user knows which branch of the Tree he is currently navigating in, he will know whether the parent branch is the "Errors" or "Warnings" branch. I was just thinking about how the snippet in comment 8 could be rewritten using a Tree for the new Problems View. It's more difficult than for Table, because with Table, childID maps to the TableItem's index. In a Tree, the childID is a "cookie", not an index. So we actually need to add a new API to find the TreeItem that corresponds to a given childID in a Tree widget. We are past the "API freeze" milestone (M5) for eclipse 3.2. We would need to get PMC approval for this change to go in. How important is this problem? Steve, we may need to consider adding this API, depending on the priority of this bug. The API would be something like Display.findWidget(Widget w, int id). Yes, this needs to be fixed for our product to pass our Accessibility checkpoint for alternate text for images. Please let me know if you need further information to get this fix approved. Kevin, (eclipse PMC) It turns out that we need to add a new API method to Display class in order to fix this bug. The bug is that there is no way a blind user with a screen reader can tell whether an item in the Problems View is an error or a warning, because there is no text associated with the error/warning icons. The API is Display.findWidget(Widget w, int id). We would need it to look up the TreeItem given only a "cookie" from MSAA (i.e. the OS). Platform-UI will then be able to determine the problem's severity from the TreeItem, and they can use MSAA to add a string (like "Error" or "Warning") to the item's MSAA name so that the screen reader can speak it. This is new API that is pretty isolated, and we think it is low risk. We know we can make it work on all of the platforms because we already have a similar method that can do the same lookup using a handle - this would just make that into API with a Widget passed in instead of a handle. Since the API freeze was M5, we are asking for PMC permission to put this in. OK? +1 I'm really sorry but we are not going to fix this for 3.2. The new API is goofy. A (possibly) better solution would be to add an item field to the AccessibleEvent class and fill this in for controls that have items (tables, trees, tab folder etc.). Since we haven't decided how we want to fix this bug and we are at the end of the 3.2 release cycle, it doesn't make sense to try to implement something now and live with the results forever. WONTFIX for 3.2. Since this will not be fixed for Eclipse 3.2, I was wondering how you will pass the Accessibility Check point for "When an image represents a program element, make the information conveyed by the image available in text" I was just wondering so that we could do the same workaround. Thank you Keri When you cannot make an image accessible (like in a label) the usual method is to make sure that the information is available otherwise either 1) some different accessibility affordance (such as implementing an IAccessible on the widget or a properties dialog) 2) making sure that the information is conveyed elsewhere. For instance the error image in the error dialog is not enough - the title should make it clear it is an error. Generally using an IAccessible is the best solution as you can convey exactly what you want. Fixed in HEAD > 20060620 For 3.3 we have decided to add the api mentioned in comment 12. This is useful for finding a TreeItem in a Tree, given a childID. When you are working with a Table, the childID in the AccessibleEvent still represents an indexed TableItem. So you still use table.getItem(childID) to lookup the TableItem corresponding to the event's childID. But when you are working with a Tree, you need to use the new Display.findWidget(tree, childID) API to look up the TreeItem. Here is a snippet: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.accessibility.*; public class TreeColumnIconAndTooltipTest { static Display display; static Shell shell; static Tree tree; public static void main(String[] args) { display = new Display(); shell = new Shell(display); shell.setLayout(new GridLayout()); tree = new Tree(shell, SWT.MULTI | SWT.FULL_SELECTION); tree.setLayoutData(new GridData(GridData.FILL_BOTH)); tree.setHeaderVisible(true); for (int col = 0; col < 3; col++) { TreeColumn column = new TreeColumn(tree, SWT.NONE); column.setText("Column " + col); } TreeItem category = new TreeItem(tree, SWT.NONE); category.setText("Errors"); for (int row = 0; row < 3; row++) { TreeItem item = new TreeItem(category, SWT.NONE); for (int col = 0; col < 3; col++) { item.setText(col, "item" + col + row); item.setImage(display.getSystemImage(SWT.ICON_ERROR)); item.setData("Error"); } } category.setExpanded(true); category = new TreeItem(tree, SWT.NONE); category.setText("Warnings"); for (int row = 0; row < 2; row++) { TreeItem item = new TreeItem(category, SWT.NONE); for (int col = 0; col < 3; col++) { item.setText(col, "item" + col + row); item.setImage(display.getSystemImage(SWT.ICON_WARNING)); item.setData("Warning"); } } category.setExpanded(true); for (int col = 0; col < 3; col++) { TreeColumn column = tree.getColumn(col); column.pack(); } tree.getAccessible().addAccessibleListener(new AccessibleAdapter() { public void getName(AccessibleEvent e) { if (e.childID > ACC.CHILDID_SELF) { TreeItem item = (TreeItem)display.findWidget(tree, e.childID); if (item != null) { String severity = (String) item.getData(); if (severity != null) { e.result = item.getData() + ": " + e.result; } } } } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } } Thanks for providing the fix for this defect. But you said that it will be available for eclipse 3.3 We have two BP1 defects that are blocked on the fix of this defect for the JET Authoring editor in the RSA Product. But our product will be shipped with eclipse 3.21. Can you please apply the fix of this defect for 3.21 to allow me to fix my blocked defects? Thanks Sameh Steve - your thoughts? Accessibility is important to many members of the community particularly because it can be a goverment section 508 compliance issue. I have heard interest in this bug from a few people. Do we have a process (probably via the PMC) to add api in a maintenance release as long as it can be done in a completely source and binary compatible manner? If so, we should look into taking this one through it. If not, we should probably come up with one. I agree. KH, do you know were I can find the rules (or can you give me PMC approval to break them)? Hi Kevin, Preventing maintenance release fixes that require backward compatible API changes (both source and binary) would be quite a contrast with the agility displayed so far by the Eclipse platform team. Please confirm whether this defect can be fixed in 3.2.1 Thanks (Note that by setting the target to 3.3M1 I didn't mean to imply that a decision has been made regarding the possibility of this bug appearing in 3.2.1, I was just doing a pass of recently fixed bugs without targets. This bug's target can change later if appropriate). We can't fix this for 3.2.1 because it involves new API. Even if we added the API, can the code above us be changed to call it? The following should work for you in 3.2 (and 3.2.1). Take the snippet in comment 17 and instead of calling: TreeItem item = (TreeItem)display.findWidget(tree, e.childID); call: TreeItem item = (TreeItem)display.findWidget(tree.handle, e.childID); The problem with this (and the reason we did not recommend it in the first place) is: - the 'handle' field is not really public. It is just public to allow cross-package access within the SWT implementation. - this will work on Windows, but it will *not* work on all platforms. - to ensure that your code compiles on all platforms, note that you can ask a Control (like Tree) for its handle, but not a Widget (like TreeItem). You can use this when you ship with 3.2 or 3.2.1, but we recommend that you upgrade to the new api when you ship with 3.3. *** Bug 162737 has been marked as a duplicate of this bug. *** |