Community
Participate
Working Groups
This PR is a collecting place for SWT accessibility concerns/info. The US has a law stating that starting June 21, 2001, all software purchased for government use must be accessible. http://www.section508.gov/ IBM has created an accessibility checklist (that we have to conform to) at either: http://www-3.ibm.com/able/accesssoftware.html http://w3.austin.ibm.com/~snsinfo/softwarecheck.html Overview: Because we are mostly native, SWT fared pretty well in passing most (but not all) of the items on the checklist. More testing is required to check all areas thoroughly, and to make sure that the areas that we fix are compliant. We got lucky with StyledText, because it uses TextOut/ExtTextOut to send text directly to the control, but more testing is definitely required, and we still may need to do work. GDA will send us the test tool, JAWS, when he gets it. Details of where we fail: 1) The number one accessibility concern is that every single action must have a keyboard equivalent. People who have trouble seeing, or manual dexterity problems, cannot use the mouse. You must be able to take away the mouse and still use the application effectively. This also means that every widget (or custom widget) must be traversable using tab traversal (tab, ctrl- tab, arrow keys, ...). This is required. A specific custom widget that we have to add traversal capability to is CTabFolder (probably ctrl-TAB). The ability for the application to specify a logical tab order is also very important, but not required. 2) Widget names. Each widget needs to have a logical name so that screen reader software doesn't sound bad when it says the widget's name. We need to add API to allow setting of widget names. 3) "Object information" must be available to accessibility tools. What this means is that our custom controls may need to implement IAccessible on Windows (see below). We will need to evaluate each custom control, but one that definitely needs work is that CTabFolder tabs need to expose their names. My own personal opinion is that if we have to implement IAccessible for any one custom control in order to meet the requirements, then we may as well implement it for all of the custom controls. Question: In order to implement the COM IAccessible interface, do we need to include the whole OLE portion? i.e. If we have to implement it for even one custom control, do we then need to say that OLE is required for accessibility? 4) We need to verify that we do not interfere with accessibility shortcuts (see below for details), i.e. check that StyledText does not use Shift keys, because 5 consecutive Shifts enters "StickyText" mode. CM (8/2/2001 1:28:29 PM) Note: StickyText mode works fine, even when a StyledText has focus. 5) We need to check if magnifier tools track focus properly in StyledText and all custom controls. 6) StyledText and ViewForm don't do high contrast mode well (see below). The user has to restart Eclipse to get the color changes, and even then, some of the colors in StyledText are not contrasted enough (for example, the black on black text is hard to read ). Likewise, wizard banners have white text on white banner background. Also, dialog fonts don't change, and they should, but this may be a Windows problem because apparently dialog fonts don't change for other Windows applications either. We should investigate and maybe work around or document. Not sure how much of this high contrast color/font stuff is UI work and how much is SWT work. 7) Double-click time cannot be hard-coded. It must use the system setting, or be user-settable in the application. Currently, double-click is not hard-coded on Win & X, but it looks like GTK and Photon need work. Windows: return OS.GetDoubleClickTime (); X: return OS.XtGetMultiClickTime (xDisplay); Photon: return 250; //NOT DONE GTK: return DOUBLE_CLICK_TIME; // where private final int DOUBLE_CLICK_TIME = 250; Details of what we may have to (or want to) do to ensure compliance: 1) On Windows, Microsoft has provided the MS Active Accessibility (MSAA) SDK. http://www.microsoft.com/enable/msaa/default.htm This is included in 98, 2K, and ME, and it can be added to 95 and NT (via service packs). Basically, it is a COM-based API in OLEACC.DLL that you access through the IAccessible interface. Each control answers some basic information, such as Name, Role, State, Value, Selection, Focus, Description, Parent, Child, ChildCount, Help, HelpTopic, DefaultAction, KeyboardShortcut, (plus some other very interesting possibilities for automated SWT testing, such as Select, DoDefaultAction, Navigate, HitTest, and Location). 2) On the Linux side, Gnome says that it will "soon" be providing accessibility that is "loosely based on" the Java Accesibility API (which was in turn based on MSAA). Gnome accessibility details are at: http://developer.gnome.org/projects/gap/ Testing tools and other "Assistive Technology" (AT) applications: 1) The accessibility tools that come with Windows are: - Magnifier: enlarges the portion of the screen that has focus. Magnification is adjustable. We can use this to test whether we are doing focus correctly in all cases. - Narrator: a simple "screen reader" that reads the contents of widgets, using an electronic voice. We were playing with this when we got Win2K, and we saw that it could *NOT* read StyledText (or IE), but it could read Notepad. It obviously only supports widgets that support IAccessible. - The following are all settable under the ControlPanel Accessibility Options (or by using wierd keyboard shortcuts): - High Contrast: Changes screen colors to high contrast mode and enlarges fonts, for color-blind users, or sunny locations. To enable/disable, press LEFT ALT + LEFT SHIFT + PRINT SCREEN. - FilterKeys: controls key and autorepeat key timing, and audio feedback for keystrokes. To enable/disable, hold down the RIGHT SHIFT key for 8 (or 12 or 16) seconds. - MouseKeys: user can use numeric keypad to control mouse cursor. To enable/disable, press LEFT ALT + LEFT SHIFT + NUM LOCK - StickyKeys: lets the user type key combinations such as CTRL+ALT+DEL in sequence rather than in parallel. To enable/disable, press the SHIFT key 5 times. - ToggleKeys: provides sound feedback when the user turns on or off CAPS LOCK, NUM LOCK, or SCROLL LOCK. To enable/disable, hold down the NUM LOCK key for 5 seconds. - SerialKeys: lets a user plug a special type of keyboard into the serial port - SoundSentry: displays a visual signal when a sound is generated. (enables hard-of-hearing users to see beep, etc) 2) In the MSAA there are several useful tools: - Inspector: shows the IAccessible field values for the control under the mouse - MSAA Verification Tool: shows the entire widget tree, and IAccessible fields, for any top level window(s) - AccessibleExplorer: similar to Inspector, except it shows hierarchical info for the current control - AccessibleEventWatcher: logs WinEvents 3) JAWS is a popular "screen reader" (it is the defacto standard). It is similar to the Narrator, except smarter. It **IS** able to read the contents of a StyledText. This is where we got lucky. We may be able to claim that StyledText is accessible because JAWS can read it. Note however that our tests were extremely superficial, and we do need to test further. One caveat is that if we ever modify StyledText to write to an offscreen bitmap and then BLT that to the screen, we will definitely break this lucky accessibility, and we will have to do a full MSAA implementation for StyledText (although we may find that we want to do this for all custom controls anyway). NOTES: CM (8/1/2001 12:07:51 PM) For a list of all shortcut keys in Win 98 or 2000, go to: http://www.microsoft.com/enable/products/keyboard/keyboardsearch.asp Some interesting ones: - ASTERISK (on the numeric keypad): Expand view of everything under the current selection when working in Windows Explorer-Tree view. - SHIFT+F10 or Application key (also the right mouse click): Display a shortcut menu that shows a list of commands relevant to the selected object. - Windows logo key+BREAK: Open the System Properties dialog box. - Windows logo key+E: Open the Windows Explorer.
Regarding tabbed folder accessibility, I was just playing around with IE's Internet Options dialog. Here is some interesting behaviour: - The tabs take focus in the tabbing sequence, then arrow keys can be used to cycle between them. Using the arrow keys does not cycle from last to first, or first to last tab. - CTRL+TAB and CTRL+PAGE_DOWN activate next tab, even if tabs don’t have focus. These cycle back to first tab if pressed when last tab active. - CTRL+SHIFT+TAB and CTRL+PAGE_UP activate previous tab, even if tabs don’t have focus. These cycle back to last tab if pressed when first tab active. - Clicking on non-active tab with mouse makes it active, but does not give it focus – it gives focus to the first widget on the page instead. Likewise when cycling using keys. However, if tabs have focus, they keep focus when cycling.
PRODUCT VERSION: 0.9
Closing this bug report because the items are either implemented or captured elsewhere.
