Community
Participate
Working Groups
Although we can getAccessible() on the CCombo widget itself, focus always belongs to the Text or List member variables. Thus, if there is no obvious accessible name, a screen reader check fails & there is no programmatic way to fix it. Perhaps provide getTextAccessible() and getListAccessible() methods? eclipse.buildId=I200406192000
In 3.1, CCombo has been changed to look for an associated Label to pass in as the value for getName. This is done even if the focus is in the text or the list. Does this solve your problem?
Possibly, but there are cases where the platform is not able to resolve the associated Label, or more accessible information is needed than just the label name. If the child List/Text objects were able to inherit the parent CCombo's getName value, that would be better.
*** Bug 73051 has been marked as a duplicate of this bug. ***
Please try the latest integration build for 3.1 and let us know if this solves your current problem. Thanks.
Created attachment 14472 [details] CCombo accessible issues
Using 3.1 eclipse.buildId=I200409070800 There remains 2 issues (see attachment for example) 1) If getAssociatedLabel() fails or if it finds an image label, there is still no accessible name. Of course, we could add text AND a label, but this is dangerous if Eclipse defaults change. 2) While navigating within the list box, we could not read the names of any of the list items, it would change to the associated label. Maybe set as the value? Or is this non-standard?
Are there any plans for fixing this problem?
Is there a possibility the remaining issues can be addressed in 3.2.1? This causes an accessibility violation for our consuming product.
CCombo is supposed to be equivalent to Combo, it should offer the same accessibility. Does it?
Is this question directed to the developer of CCombo class?
Yes, I should have said, "CAR, ..."
could someone please respond to this, even if just to say "we have no plans to fix." Thanks?
The developer who owns this bug is away right now. Off the top of my head, I'd say that CCombo should provide the same sort of accessibility as Combo. Looking at comment #5, "Associated label is an image" seems to be a problem that a Combo would face, right? The other one "no way to read list items" looks like a bug. Again, what happens when you substitute a Combo instead of a CCombo?
Well, the difference is that Combo allows us to override the getAccessibleName() value to anything, so having a leading Image is not show-stopping. CCombo does not allow this for its Text/List members.
This is marked as P2/critical, but hasn't seen any activity since August 2006. Please update with current status.
CAR, we should allow CCombo to override the name (ie. getAccessibleName()), just like Combo.
Steve, fyi this problem is identical to the one we were looking at with Spinner. The overriding is happening, but only at the parent level. i.e. the CCombo itself is reporting the overridden accessible name, but when its text child gets focus or a mouse hit, the text child isn't reporting the CCombo's overridden accessible name. Somehow, we have to add accessible listeners to children of a compound widget when an accessible listener is added to the parent. However, our api makes this difficult because listeners are added to the getAccessible() of the control, and not the control itself. So there's no handy place to do this. This will have to take some more thought. Child controls of a compound widget need to delegate overriding accessibility questions to their parent (the compound widget itself). Do we need a setData trick? <g> Like perhaps the compound widget parent sets an array of "children that should delegate accessible listeners to me". When an application calls addAccessibleListener, then accessible listeners are added to all of these children, too. <g> We need to talk about possibilities tomorrow.
This defect was marked as critical because it causes a violation of IBM rules on accessibility in UI.
Carolyn, can you veryify that CCombo is working, it's just that you can't override the default name and possibly some other attributes?
Correct - CCombo is working, except for overriding the accessible name. The recommended work-around is to precede the CCombo in the tab order by a text Label. Note that Window-Eyes does a better job of reading the CCombo value than JAWS.
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.
Hello, This bug is still relevant to us. The point about "the list just reporting the associated label name and not the actual list item" is a serious Accessibility issue. We expect CCombo to report the focused list item name and not the associated label every time we change the selection in the list. Also, we have one more issue. When the list opens screen reader reports it as a "dialog" before calling it as a list. This will be confusing to the user. When I checked the parent hierarchy in Microsoft Inspect tool the parent of the list is having an accessible role as "dialog" which is causing the screen readers to read it like that.
Hi, I'm facing the issue with ComboBoxCellEditor which utilizes the CCombo internally as the control. Due to this the control accessible name which is being set is not being read by the JAWS. We are facing accessibility issues with this. It would be great if someone could provide a resolution to this.
Hi, Still seems to be a problem in 2022-06 (not been able to try a newer version yet). I've been trying to set the accessible name for a ComboBoxCellEditor (which uses CCombo under the covers), and no matter what I try, the screen reader (narrator on Windows)just seems to say "document" when the cell editor is activated. Also, it does not respond to up/down arrows when the value is changed etc. We use this control a lot, so it's making things tricky for compliance. Any ideas if it's going to be looked at? Thanks, Iain
