Community
Participate
Working Groups
It is not possible to do anything in help without the mouse. Here are some of the problems 1) When you open the perspective nothing has focus 2) If you get focus on the list view nothing is selected so you cannot navigate 3) Several times on the tab traversal the cursor disappears 4) In High Contrast Black all of the window titles have a yellow background which is unreadable with white text. This appears to perhaps be some uncommon color setting - it appears to be the active window border color being used.
1) is an SWT bug for which we are waiting a fix 2) what list view are you describing? 3. I cannot reproduce this. What IE version do you use? 4. yes, the active window border is used as the background colour. There are number of CSS predefined values that map to system colours and we picked ActiveBorder as the one one to use for window backgrounds, etc. I'll check to see if there is anything else that would work.
2) The tree on the right hand side when you first open it (sorry - should have said tree) 3) I am using IE 6.0.2462.0000 4) Try SWT.LIST_BACKGROUND_COLOR - we use it throughout the UI. As it is alsway selected to go with the text for your current setting it is a safe choice.
The whole help is running inside a web browser, so I can't pick up the SWT.* colours. We also have a "monochromatic" design, so I only need a couple of colours for the entire help. I will look more in the CSS list to see what's best. FYI, here is the list of colours that I can use in a browser and on IE and Mozilla they default to system values: ActiveBorder :Active window border. ActiveCaption :Active window caption. AppWorkspace :Background color of multiple document interface. Background :Desktop background. ButtonFace :Face color for three-dimensional display elements. ButtonHighlight :Dark shadow for three-dimensional display elements (for edges facing away from the light source). ButtonShadow :Shadow color for three-dimensional display elements. ButtonText :Text on push buttons. CaptionText :Text in caption, size box, and scrollbar arrow box. GrayText :Grayed (disabled) text. This color is set to #000 if the current display driver does not support a solid gray color. Highlight :Item(s) selected in a control. HighlightText :Text of item(s) selected in a control. InactiveBorder :Inactive window border. InactiveCaption :Inactive window caption. InactiveCaptionText:Color of text in an inactive caption. InfoBackground :Background color for tooltip controls. InfoText :Text color for tooltip controls. Menu :Menu background. MenuText :Text in menus. Scrollbar :Scroll bar gray area. ThreeDDarkShadow:Dark shadow for three-dimensional display elements. ThreeDFace :Face color for three-dimensional display elements. ThreeDHighlight :Highlight color for three-dimensional display elements. ThreeDLightShadow :Light color for three-dimensional display elements (for edges facing the light source). ThreeDShadow :Dark shadow for three-dimensional display elements. Window :Window background. WindowFrame :Window frame. WindowText :Text in windows.
Window background I believe is the same as SWT.LIST_BACKGROUND_COLOR - this should work for you. Basically whatever the Window setting is in the Display properties is what we are using.
That's exactly what we're using, and you can play with the window settings to see that they get picked up. for text: {color:WindowText;} for background: {background:Window}
The colour I am getting from Help is the Active Window Border setting. The Window setting is different. I only have the Display Properties dialog as a reference so I am not sure how the colours map to the ones you describe. Try switching your display properties to High Contrast Black and you will see what I am talking about.
Oh,I got it now! I was talking about the actual html code, but in fact the problem is on the SWT frame that holds the browser control. We'll fix it. Thanks for bearing with us...
Sorry, but I have switched to the hight contrast black, and still do not see a problem. May be I am looking at wrong things, but everything seems right to me. Attached is a screen shot from my machine. Which driver are you using? Try clearing your browser cache before launching help to make sure no older files are used. Can you provide a screen shots from your machine of help window and workbench window to compare? Thanks.
Created attachment 648 [details] help window, hight contrast black
I am going to attach what I see. I am using Windows 2000. Tell me how to check for the drivers you are after and I'll let you know what I have. My display settings are IBM 6557 P92 on NVDIA RIVA TNT2 Model 64 32MB (IBM)
Created attachment 649 [details] Help Snapshot
Created attachment 651 [details] Workbench snapshot
Sorry, I ment "Eclipse build" when I wrote "driver".
Build 20020411 and Build 20020416 both exhibit this behaviour
We were setting high contrast through control panel accessibility options, when we set it in display properties we were able to reproduce the yellow background. I have switched to use "ButtonFace" instead of "ActiveBorder". Text is readable now in standard and high contrast settings.
The main points of this PR had to do with keyboard navigation and focus. These are much more important than the colours. Help needs to be accessible with keyboard only. Are these issues being addressed? Which SWT PR are you dependent on for (1)?
Help is now picking up system colors, fonts, and supports default browser keyboard navigation. Navigation for topic trees is done using the tab not up/down arrows, but it works. Ctrl-Tab navigates from a frame to another. The bug that properly enables help accessibility is 12398. http://dev.eclipse.org/bugs/show_bug.cgi?id=12398 BTW, I cannot reproduce problem 2) that Tod reported.
Here are the minimal requirements for help to be accessible: - must come up with focus on one of the controls (preferably the subject tree) - must be able to cycle focus between all controls that take input (e.g. using Tab or F6) - must have a clear indication of which control has focus - must be able to navigate within a control using keyboard only (e.g. next/prev topic, expand/collapse topic tree, back/forward in navigation) - this should not require using toolbar buttons - must be able to read the selected topic and contents using screen readers like JAWS (this usually follows from giving focus to all controls, but needs to be tested, particularly in this case due to the use of an embedded web browser, and may require extra work when controls are owner drawn) - colours must honour the system settings (test with both high contrast settings)
Here are some keyboard navigation tips for help running on Windows using IE 5.x: - To move to the next topic in the left frame, click TAB. - To move to the previous topic , click SHIFT TAB. - To scroll the left frame up/down press the up/down arrows. To scroll all the way up/down press HOME/END - To go back/forward press ALT LEFT/RIGHT ARROW - To go to the next frame (there are quite a number of frames in the help system) click CTRL TAB. - To move to previous frame, click SHIFT CTRL TAB. - To print the current page or active frame, click CTRL P.
Build 20020515 There is still one more issue - Hyperlinks in the text. In Workbench UserGuide -> Contents -> Components I cannot get to the hyperlink on the page with the keyboard. Confirmed that the tab behaviour gets you around to the places that were a problem before.
I don't have any problem getting to that link ("Software Updates section"). I select the topic, click enter, then Ctrl-Tab to focus on the content page, then Tab and I see the focus on the link. Click enter opens it. I run IE 5.5
I am working on some code for the navigation tree that uses arrows for navigation and overrides the default browser behavior (i.e. scrolling). If this works well,then I will updates the comments I made before regarding navigation.
I'm assuming you've seen the IBM checklist for web accessibility. But if not, here it is: http://www-3.ibm.com/able/accessweb.html My apologies if this is the first you've heard of it, but these are the requirements that Help and all our help content has to meet.
Thanks Nick. Yes, I have recently seen this list, and we only have one item that we don't comply with, and I don't think there is a quick solution for it: it is required that the app works with scripting turned off. We use scripting quite a bit, and unless we create a very basic ui (no navigation tabs, etc.) I don't think this is feasible. In fact, if javascript is turned off, we put up an error page that tells the user to enable it before using help. To implement a non-javascript help view, we can redesign the help to support basic linking only, but the UI will be very simple, and completely different that what you see in the regular help (more like the documentation we currently show on eclipse.org)
Just an addition to keyboard navigation in the tree: with the next build, the book contents (trees) can be navigated with the arrows as well. Up/down arrows move the focus to the prev/next node, "enter" selects the node (i.e. shows the html page associated with the topic), left/right arrow collapse/expand the nodes.
Glad to hear we're in good shape here. I also think we're OK with regards to scripting. Point 5 of the checklist states (from http://w3.austin.ibm.com/~snsinfo/webscripts.html): "Ensure the functionality of scripts is keyboard accessible. If the content affected by scripting is not accessible, provide an alternative. " It doesn't say you have to work with scripting disabled. If scripting is required, though, then the features it provides have to be accessible. From the guidelines: "Although some text-only browsers still don't support scripting, and individuals concerned with privacy and security may turn off scripting, this checkpoint requires that information (content) and the user interface (events) affected by scripts are directly accessible only when they are essential. Conversely, this checkpoint does not prohibit the use of directly accessible scripts nor does it require alternatives (such as NOSCRIPT) for directly accessible scripts."
Tod, do you still have problems with keyboard access to hyperlinks? This seems to be the last open issue in this bug.
In build 20020529 I can now tab to the hyperlinks
It looks like all the reported problems have been fixed. I will close the defect, but please re-open if you see regresssions or other related problems.
