Community
Participate
Working Groups
Build ID: I20080207-1530 Steps To Reproduce: 1. Set Windows OS to high contrast mode with extra large font (ie. in Control Panel > Accessibility Options, click Settings button and select "High Contrast Black (extra large)" ) 2. In Eclipse, select Windows > Preferences... to open up Preferences dialog 3. Select "Java" node to show the Java preference page (or any longer preference page) 4. Notice vertical and horizontal scrollbars (Display has resolution 1024x768) 5. Tab to traverse different controls in preference page. Result: When reaching controls that are not seen initially, the scrolled composite does not scroll to make that control visible. Expected: Scrolled composite in preference page should be scrolled to show the control the user is focusing on. More information: I noticed there is API introduced in Eclipse 3.4 for ScrolledComposite that makes the controls visible as a user traverses via keyboard: public void setShowFocusedControl(boolean show) Could the ScrolledComposite used in the PreferenceDialog take advantage of that new API?
Created attachment 110830 [details] screenshot of Java Preferences page under high contrast extra large settings
This issue is being flagged by our Accessibility team as Accessibility Compliance Failure : Checkpoint 4.5 - text in the dialog needs to be visible or scrollable (via kb) to view.
Changing severity to "critical" since this is a Section 508 blocking accessibility issue. Could someone please take a look at the suggested fix in the initial description?
Are you hoping to see this in 3.4.1? It's probably too late for that without any kind of escalation at your end.
Thanks Kim, will do.
This fix appears good. Boris, can I get a +1? This has just appeared on the IES list. Patch forthcoming.
Created attachment 111116 [details] Patch against JFace Uses the new SWT api for following focus widget
Fix in R3_4_maintenance
I had posted a comment in https://bugs.eclipse.org/bugs/show_bug.cgi?id=245366 saying it was a dup of this one. Do you agree?
Kim, This is a comments we got: So, this means Eclipse still have Accessibility issues on Scrolling bar, even with Jamie's patch (that is, Kim's patch which adds scrolled.setShowFocusedControl in PreferenceDialog.java). From accessibility viewpoint, all the capabilities that we can use mouse to complete should also be able to complete via keyboard. So, scrolling bar should be operated via key board definitely. So looks like, it is not enough to add setShowFocusedControl in PreferenceDialog. The issue is arrow keys (or PageUp/Down ?) cannot scroll prefeference page. Steve, is this something SWT ScrolledComposite can fix ?
(In reply to comment #10) > This is a comments we got: > > So, this means Eclipse still have Accessibility issues on Scrolling bar, even > with Jamie's patch (that is, Kim's patch which adds > scrolled.setShowFocusedControl in PreferenceDialog.java). From accessibility > viewpoint, all the capabilities that we can use mouse to complete should also > be able to complete via keyboard. So, scrolling bar should be operated via key > board definitely. As I understand it, you need to be able to reach equivalent functionality not necessarily the same functionality. The actual test was tabbing into a control that remained invisible, and that has now been fixed. Accessibility does not mean that whatever you can do with the mouse you can do with the keyboard, simply that you can access the same functionality in some way (for example, via a menu accelerator or label mnemonic, rather than through mouse event emulation). What functionality can you not access in the original test case? Maybe we need to look into that again. Conversely, is there an accessibility standard for external scrolled widgets (ALT+UP_ARROW should alway scroll the external widget)? It might be that we have to catch keystrokes (and block them from the contained SWT controls) but it we are to do that, then it must be a well recognized standard. PW
Ann, could you answer Paul's questions (comment #11) ?
Per the Software Accessibility Checklist/Checkpoint 1.1/Provide keyboard equivalents for all actions: Scrolling must be supported with the keyboard using the standard scrolling keys; page up, page down and tab, to move the viewing area and keyboard focus appropriately.
(In reply to comment #13) > Per the Software Accessibility Checklist/Checkpoint 1.1/Provide keyboard > equivalents for all actions: Scrolling must be supported with the keyboard > using the standard scrolling keys; page up, page down and tab, to move the > viewing area and keyboard focus appropriately. > And now we move the viewing area and keyboard focus appropriately on tab. PW
The use case we were concerned about were controls that do not gain focus (ie. Labels). Kim's patch helps a lot because now we may be able to work around this by strategically positioning controls, but it would be helpful if there was a generic way of handling scrolling. One case where this may be common is if there is a label at the top or bottom of a preference page -- if it is at the top, once the user tabs such that the page scrolls down, there is no way to tab back up to ensure that the label at the top is visible again.
(In reply to comment #15) > The use case we were concerned about were controls that do not gain focus (ie. > Labels). Kim's patch helps a lot because now we may be able to work around > this by strategically positioning controls, but it would be helpful if there > was a generic way of handling scrolling. Correct, labels won't gain focus although read-only text widgets will. I think the more general case for preference pages can be addressed in 3.5 with bug 245366. We need time to come up with and publish a strategy for client contributed preference pages that can contain any controls and code especially if the general solution is to eat certain keystrokes for the entire preference dialog. Steve, I don't support that scroll bars can take focus? PW
(In reply to comment #16) > > Steve, I don't support that scroll bars can take focus? > That would be "I don't *suppose* ..." PW
Scroll bars don't take focus and even if they did, it would be annoying and strange compared to other applications on the desktop.
btw, here is "IBM Software Accessibility Checklist" Ann mentined in comment #13: http://www-03.ibm.com/able/guidelines/software/accesssoftware.html
In M20090121-1700 PW
