This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
relese33 build #200112170331 jdk1.3.1_01 In NotifyException there is now used the terminal emulator panel to display the exception stacktrace. But it is not accessible. Doesn't implement Accessible : Class: org.netbeans.lib.terminalemulator.Screen { } Class: org.netbeans.lib.terminalemulator.Term$ScrollWrapper { }
[build 200201020331] Output window testing results: Doesn't implement Accessible : Class: org.netbeans.lib.terminalemulator.Screen { } Class: org.netbeans.lib.terminalemulator.Screen { } Class: org.netbeans.lib.terminalemulator.Screen { } Class: org.netbeans.lib.terminalemulator.Screen { } Class: org.netbeans.lib.terminalemulator.Term$ScrollWrapper { } Class: org.netbeans.lib.terminalemulator.Term$ScrollWrapper { } Class: org.netbeans.lib.terminalemulator.Term$ScrollWrapper { } Class: org.netbeans.lib.terminalemulator.Term$ScrollWrapper { }
Reassign to Ivan because of target terminalemulator package.
These classes, terminalemulator.Screen & terminalemulator.Term$ScrollWrapper, are internal classes used by the main widget terminalemulator.Term. There's no need for them to be accessible since Term is supposed to take care of all that. I'd propose that the accessibility tester is being overzealous, but I"m not sure who this needs to be reassigned to.
Ivan, UI guys tell me that tester must test for implement Accessible all components - especially components with isFocusable=true and isShowing=true -> user can focus these components and they must implement Accessible (Accessible Description/Name != null)!!! If you write something inside output window, focused component is org.netbeans.lib.terminalemulator.Screen and it doesn't implement Accessible - it is really high priority issue !!! You suppose Term is "manager" for Output Window, maybe you are right, but reader doesn't know about another as focused component and if focused component doesn't implement Accessibile, he cann't get Accesssible children(s)/parent - he doesn't know that Term is their parent. Only one way how resolve this issue -> Screen & ScrollWrapper must implement Accessible.
Commentary from Ivan : >>> UI guys tell me that tester must test for implement Accessible all ^^^^^^^ > Who are they? > There are ramifications to doing what you are asking for that > don't make sense to me. I'd like to discuss this a bit more so I > understand what it is I/we are designing, since there are few > tutorials and examples on this. > please fwd this to the "gui guys". > Term is a "composite" widget. It is supposed to be treated as a unit > that is made up of stock swing sub-components. > Term 's accessible interface for example will (it doesn't yet) > implement getAccessibleSelection(). This makes sense since it's the > Term object that is the owner of the selectioninfo. > Now if I were to have sub-components of a composite, like Screen in > this example, also implement accessible will it have to implement > getAccessibleSelection() as well? > The same question can be asked about all other accessible bits if > information, like state, value etc. > Perhaps the "proper" solution is to have Screen not be focusable and > instead delegate all focusing events to it's parent? > I"ll be askig the java swing guys some of this presnetly. Jano, your suggestion, idea , please ?!
rise priority to P2, due to Accessibility Bug Priority Guidelines.
Ivan, try to get an inspiration from jdk1.4 swing *editable* JComboBox implementation. It is also composite widget. I think that if your Term component provides proper implementation of accessible interface then Screen does not need to implement Accessible interface. We can check it with screen reader. Let as know when accessible implementation of Term is ready. Thank you.
Target milestone -> 3.4
added FFJ40_WAV_APPROVED keyword
Edging closer. There are two parts to this issue. One is "application accessibility" where various rules have to be followed and the assumption is made that the building blocks (JComponents) are properly accessible. This is what the UIAccessibilityTester does and is why I believe this bug was filed in the first place. I believe this is taken care of now. Term and Screen implement Accessible, return reasonable roles, names and descriptions. UIAT still has some issues with focus keys butthose seem to be related to Term appearing inside a SplitPane. But there is a more significant part which is that Term is a new component which is not yet properly accessible. Specifically Term needs to implement AccessibleText at the minimum. This is not the sort of stuff that UIAccessibilityTester tests. It's a very complex issue. For details see the JavaDoc comments associated with Term.getAccessibleContext() and the multiple notes in .../terminalemulator/ReleaseNotes.ivan.txt. As it stands now Term implements AccessibleText which has been unit tested but that's no guarantee of how it will work with real AT. I"m still looking to finding stuff to help me with that.
Target milestone was changed from '3.4' to TBD.
Set terget milestone to TBD
This bug is reported in version <= 3.4dev and still not fixed. Due to that it forbids the release candidate for 3.4 to be promoted. Are you aware of that and are you intensively working on the fix? If not, you should consider some corrective action.
Accessibility has many aspects to it and there are multiple issues filed on it. Some of them were fixed in my commits with tags ivan_15 and ivan_14. The specific concerns of this bug, that is, aspects of accessibility that are detectable by NB a11y verification are all fixed. Also AccessibleText is properly implemented. issues 19156 dealt with keyboard navigability and almost all issues are solved ecxcept for keyboard manipulation of the selection and a couple of less common accelerators for which special issue 24759 was opened. So, I guess this issue is fixed, while the overall Term/OW A11Y still needs incremental work with 24759 being the banner issue.
verified in [nb_dev](20020918)
moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table.