Section 508 Reference Guide Appendix C: Section 508 Evaluation of a USPTO Software System
In late 2001, the USPTO tasked a contractor to revise a major proprietary software system. Part of the task required the contractor to evaluate the Section 508 status of the revised system and to ensure that the final product was compliant.
For the price of a luxury sedan, the contractor did an extensive evaluation of the system and provided the attached report. Out of the eleven software standards, only eight were applicable to the system. The report does an excellent job of identifying and illustrating the compliance issues.
The contractor bid on a second proprietary system. However, when the contractor estimated that the Section 508 evaluation would cost the price of two luxury sedans, the USPTO sought other sources.
We discovered several reputable companies that will do a quasi- training/evaluation course for $2500. The course is officially a training session on JAWS screen reader software. What makes the class unique is that the course material can incorporate the software that needs evaluation instead of normal JAWS-related course material. In other words, not only do the students get a lesson in JAWS, they also are able to evaluate their product and determine what is deficient… and all for $2500.
Key lessons learned:
- Have a statement in the contract that requires the contractor to build or provide Section 508 compliant products.
- Until the agency accepts the product, the contractor is responsible for compliance. Once accepted, the agency is legally responsible for compliance.
- Section 508 compliance is mostly good design and development practices.
- Develop to the Section 508 standards, not to AT. Product developers must satisfy the Section 508 standards, but interoperability with specific accessibility tools is optional.
- Product developers must have the means to evaluate their product for compliance before the product is about to go into production.
What follows is the luxury-level report on a USPTO automated system.
EAST Software Evaluation
EAST is opened to the public search rooms as well as internal use. Purpose of the application is to allow users to search for patent and patent applications for text search with key words or manual of classification. This will allow searching for class and subclasses. Most customers are lawyers and legal assistants on behalf of patent applications. The employees are patent examiners, who are the subject matter experts that prepare the case to approve the patent.
The F2 key will place the focus in the Tree View. However, there are a couple of events that will automatically change the focus without the user request.
Tree View Navigation: To navigate a Windows Tree View you generally use the UP/DOWN ARROW keys to select each node within the pane. If the node has a plus next to it you press the RIGHT ARROW to display the contents of the node and the LEFT ARROW key to close the node. When I press the F2 key it places focus in the Tree View pane, however when I press the UP/DOWN ARROW keys it switches focus out of the tree view into the right pane if there is a BRS Search query listed under the Drafts node. This should not happen. If the focus changes automatically, the blind user will be totally unaware that the focus has changed and will be completely lost when this event occurs. The UP/DOWN ARROW keys are to be used to make selection choices within the Tree View, not to switch panes. If the pane needs to be changed the user must be able to change via keystroke.
Focus gets lost again in the Tree View. The focus switches from the Tree View into the right pane view when I press F7. When I press F2 key to return focus back to the Tree View and try to use my UP/DOWN ARROW keys, the EAST Desktop loses focus completely. And the node in the Tree View list is grayed out.
Pane 2 Tabs Buttons
There is no tab order or tab sheet order in the tabs located in Tabs portion of Pane 2. This is a significant issue. The user should be able to select any one of these tabs either through the natural tab order or the Windows select tab sheet commands. To be more consistent to the type of control these tabs represent, I recommend that they be placed in the tab order of that window.
- Structured Form Tab. The shortcut key is F8 to select the Structure Form Tab in Pane 2. I am unable to get JAWS to read any of the Tabs listed in Pane 2. The user memorizing the keyboard command for this function can only do selecting the tabs. Not an acceptable alternative. If Tab order were not an option for the Tab buttons in Pane 2, placing the shortcut key in the Tab lists under the View menu item would be acceptable alternative.
- Custom Form Tab. The shortcut key is CTRL + F8 to select the Customize Tab Button.
- BRS Form. The shortcut key is F7 to choose the BRS search form.
- IS&R Form View. The shortcut key is CTRL + F7 for the IS&R Form.
- Hits Tab. The shortcut key F3 switches Pane 2 to the Hits Window when the focus is in Pane 2.
- Details Tab. The shortcut key F4 switches Pane 2 to the Details Tab when the focus is in Pane 2.
- Images Tab. There is no access to this button either through tab order or a shortcut key.
- Text Tab. There is no access to this button either through tab order or a shortcut key.
Pane 2 Form View Upper Right
- F7 works to get focus
- Dialog Box Controls top part of search view. All the dialog box controls are accessible and are spoken using the tab order
- DBs button. Accelerator works.
- Plurals checkbox. Accelerator works
- Synonyms Checkbox. Accelerator works
- Highlight all terms initially. Has no accelerator key. Need to add an accelerator key for consistency.
- The Tab View upper right. Has no Tab order or Tab sheet controls.
- BR&S Form Tab (press F7). F7 Shortcut works when you move from Tree View pane to the BRS Form Pane. Cannot move from lower pane by pressing CTRL + TAB or CTRL + SHIFT + TAB. Cannot move out of Lower Pane to either Tree View or tab view when the Lower Pane has focus. Needs to be fixed.
- HITS Tab from the Tab View (press F3). Switches to Lower Pane and displays a grid. Pressing F3 when the IS&R form tab has focus moves the focus from the IS&R pane to the Lower Pane and displays the grid. Pressing F3 moves the Tab from the lower pane back to the IS&R Forms view with a duplication of what was displayed in the lower pane.
- Details Tab from the Tab View (press F4). Pressing F4 reverses the above processes. The Lower Pane - no shortcut keys work to access this pane from the EAST Desktop.
- HITS Tab (press F3 when focus is in the Lower Pane) When the Lower Pane has focus you can press the F3 key and it will display the HITS contents in the Lower Pane.
- Details Tab (press F4 when focus is in the Lower Pane) When the Lower Pane has focus you can press the F4 key and it will display the Details contents in the Lower Pane.
- New Workspace. No Accelerator key
- Open Workspace Dialog Box. No accelerator key
- Save Workspace. No Accelerator key
- Save Workspace As Dialog Box. No Accelerator key
- Close Workspace. No Accelerator key
- Local Printing Dialog Box. Accelerator key
- Group Printing Dialog Box. Accelerator key
- Recent Workspaces Dialog Box. No Accelerator key
- Exit. (X) accelerator key being read without a problem. There is a section of this tab sheet that is grayed.
- Customized Menu Dialog Box
- Toolbar Tab. The control tab moves the focus between the 2 tabs sheets. Can tab to each of the controls. JAWS reads all of the dialog box controls on this tab sheet and follows a logical tab order.
- Command Tab. The control tab moves the focus between the 2 tabs sheets. Can tab to each of the controls. JAWS reads all of the dialog box controls on this tab sheet and follows its logical tab order.
- Closing Customize Window. Pressing ALT + F4 does not close the Customize window. Cannot close the windows without pressing ENTER to execute the OK button or by pressing Cancel when selected. If you have a mouse you can click with Cancel, OK button, and the close button at the top of the Window. Customized Accelerator key (c) works.
- Status Bar Menu Item. Accelerator key (s) works
- Hide Caption (grayed). Accelerator key (h) not tested
- Showed Caption (grayed). Accelerator key (o) not tested
- Highlights (grayed). Accelerator key (g) not tested
- Tabs Submenu. Accelerator key (t) works
- Structured Form Submenu. Has no underlined accelerator key but the letter (s) works.
- Custom Form Submenu. Has no underlined accelerator key but the letter (c) works.
- BRS Form Submenu. Has no underlined accelerator key but the letter (b) works.
- IS&R Form Submenu. Has no underlined accelerator key but the letter (I) plus the ENTER key works.
- HITS Submenu. Has no underlined accelerator key but the letter (h) works.
- Details Submenu. Has no underlined accelerator key but the letter (d) works.
- Text Viewer Submenu. Has no underlined accelerator key but the letter (t) works.
- Workspace (grayed). Accelerator key (w) not tested
- Main Workspace (grayed). Accelerator key (g) not tested
- Search History menu item with ellipsis. This is a search history dialog box, however the menu item does not have the … to indicate to the blind user that when this menu item is selected a dialog box will appear. The ellipsis needs to be added to the menu item. See Screen Shot 1.
- Search History Dialog Box. All the user interface elements within the Dialog Box worked without a problem. All elements had access with the tab order.
- Cut (grayed) accelerator key (t), shortcut key CTRL + X to cut text. Not tested
- Copy (grayed) accelerator key (c), shortcut key CTRL + C to copy text. Not tested
- Paste (grayed) accelerator key (p), shortcut key CTRL + V to paste text into a document. Not tested.
- Sort (grayed) accelerator key (s), shortcut key CTRL + SHIFT + S to sort. Not tested.
- Find (grayed) accelerator key (f), shortcut key CTRL + F to find text.
- Thesaurus Dialog Box
- Has more then 9 different types of Dialog box controls.
- Every control is accessible with the tab order.
- Every control reads properly and identifies the correct control ID.
- Copy to Search Form Button (grayed) not tested
- Dictionary Dialog Box
- Accelerator key (d) with an ellipsis
- Has more then 15 different controls
- Tested for tab order and all can be reached by pressing the TAB key except for those items that are grayed out. There are 3 controls that are grayed
- Copy to Search Form Button (not tested)
- Previous Button (not tested)
- Options Dialog Box
- Accelerator key (o) with an ellipsis
- Search Tab Sheet. Tested dialog box controls for tab order and readability. JAWS was able to read the title of the control and the control type. No changes needed.
- Retrieval Tab Sheet. Tested dialog box controls for tab order and readability. The Tab order was random jumping all over the tab sheet and not following the natural order of the dialog box layout JAWS was able to read the title of the control and the control type. May want to review the tab order in put in a logical sequence of order.
- Display Tab. Tested dialog box controls for tab order and readability. The tab order follows a natural sequence and all of the titles and type of controls are being read without a problem. There is a section of this tab sheet that is grayed
- Files Tab. Tested dialog box controls for tab order and readability. The tab order follows a natural sequence and all of the titles and type of controls are being read without a problem.
- Tags Tab. Tested dialog box controls for tab order and readability. This tab sheet has some problems. The tab order is completely out of sequence. When I pressed the tab key the focus moves straight down the description column instead of moving from left to right. When the focus moves to the last cell of the description field the tab order would then move the focus to the check box at the top of the next column. Then by pressing tab the focus moves down through the column of checkboxes. The user would have no idea what the checkboxes were associated too. There is a checkbox associated with each description edit box. If the user wanted to display the color and the associated description edit field the checkbox would need to be checked. With the tab order working the way it does, there is no way that the user can determine what checkbox is supposed to be checked. The tab order should go from the description edit box to the right, i.e., to the associated checkbox. See Screen Shot 2.
- Timeouts Tab. Tested dialog box controls for tab order and readability. This dialog box and controls work without difficulty.
- Image Display Formats Dialog Box
- Accelerator Key (i) with an ellipsis
- Tested controls for tab order and readability. The tab order follows a natural sequence and all of the titles and type of controls are being read without a problem.
- New Window. Accelerator key (n) works
- Cascade. Accelerator key (c) works
- Tile. Accelerator key (t) works
- Arrange Icons. Accelerator key (a) works
- Browsers submenu. EAST, Browser software submenu item. Accelerator key (b) works
- Accelerator key (h)
- EAST Contents. Accelerator key (c)
- Keyboard Map Dialog Box
- Keyboard Map with ellipsis
- Cannot TAB or SHIFT + TAB back out of the list box.
- The focus bar only highlights the Browser item in the row instead of all the items listed in the row. This makes reading the other items listed in the row difficult to read.
Navigating to Pane 3
By pressing CTRL + TAB while Pane 2 is in focus you can move focus to the lower pane, Pane 3. By pressing the context menu key just to the right of the Right Windows key, a context menu will be displayed. This provides the user with a list of different views that can be displayed in this view.
The problem that I experienced was that when I wanted to move back to Panes 1 and 2, I was unable to move the focus to either the Tree View or to Pane 2 using keyboard commands. However, I was able to select the same two panes using the mouse. See Screen Shot 3.
When focus is in Pane 2 the system will alternate the F3 Hits key and the F4 Details have been told that this pane represents very little importance to a totally blind person. The advantage of the third Pane is that it allows a person to open a second window to look at concurrently, because to obtain the contents of Pane 3 they would need to switch to different views. They can switch to any Pane it chooses through this keyboard command. The questions is whether to fix the problems for the general population. There are keyboard commands within the application instructions that claim to allow the user to move between Panes through keyboard commands and they do not work.
The Stingray Grid
After completing a search using one of the four search tools the product information output of the search is displayed by a COTS application called Stingray version 7.0. To navigate the Grid you press the ARROW keys and a cell pointer moves from cell to cell and will display the contents of the cell in a focus rectangle.
Simply stated, the focus rectangle within this Grid is not Section 508 compliant. To be compliant this rectangle must either have system focus within the focus rectangle or must place the system cursor within the boundaries of the cell pointer. These are the only two ways that the screen readers can gain access to the information contained within the boundaries of the pointer. Without that ability the blind user is unable to predictably acquire the text within the pointer's boundaries. The information that is randomly spoken has no meaning.
Limited readability: I have been able to get JAWS to read some of the information within the Grid boundaries. This has been accomplished by turning on the JAWS and Virtual cursor. I was able to read lines of text but not in a predictable manner. I would press the UP/DOWN ARROW keys and the JAWS cursor would not move from line to line in the text. It would read a line or a portion of a line of text when pressing the UP/DOWN ARROW keys. When I executed any of the JAWS read commands (read line, read word, read character), JAWS was unable to read any of the text displayed along that horizontal plain. When I attempted to use JAWS read next and prior word, the Grid interfered with the actual JAWS functionality of the cursor movement. The read next and prior word for JAWS is supposed to move the cursor to the specified word along the horizontal plane. Within the Grid it only moved to next or previous pixel location and does not speak anything. When moving from line to line the JAWS cursor skips over lines of text completely. Typically, JAWS has no problem, and tracks the text being displayed on a line-by-line basis. When pressing the UP/DOWN ARROW keys, JAWS may read a line "blank" when the DOWN ARROW key is pressed again. Say a part of the line when pressed again. Say another blank line again, and when you press the ARROW key again it will then say the line of text. It responds like there are blank lines between the lines of text.
For additional testing I invoked the Braille viewer within JAWS. The Braille Viewer is a software window that displays in text what a hardware component called a Braille display would display in Braille. This allows me to see what the Braille display would see within an application or document. On occasion I have had the ability of having the Braille viewer see text that the speech part of JAWS did not see. If I am able to see the text displayed in the viewer, there are things that can be done to get it to read that same text. I was able to get JAWS to see more text with the Braille viewer than with speech. So I thought I was making some progress. Further testing has proven that the use of JAWS and this current version of Stingray will not work. I discovered where characters and numbers were being dropped out of the viewer, making the information being displayed useless.
I tried to select text within the cells within the Grid using the standard Windows select text keyboard commands. The standard select text keyboard commands did not work as designed. For example the standard command to select the next cell is CTRL + SHIFT + RIGHT ARROW. To perform the same function is SHIFT + RIGHT ARROW. This blocks and reads one cell pointer one position at a time. JAWS was able to successfully read these cells when I used this strategy. I am still unable to read the text character-by-character using this system.
The next issue is the random movement of the cursor when pressing the UP/DOWN ARROW keys. When the JAWS cursor is active, without predictability the cursor will reverse direction from the actual direction of the ARROW key being pressed. In other words, when JAWS is active and I am pressing the DOWN ARROW key, the JAWS cursor will reverse its order randomly and then reverse itself again and go in the correct direction. The problem occurs whenever you press either the UP or DOWN ARROW keys. It would appear that JAWS is looking for an indication of where the line is within the window.
When testing the navigational key commands HOME and END, I discovered a very interesting occurrence with the cell pointer. When you press either of these keys, the cell pointer disappears and the cursor gets placed in the cell either at the beginning or end depending on which key you pressed. This will allow you to look specifically at the contents of the cell, and allows you to read each character within the cell. When the cursor reaches either end of the cell by pressing the ARROW keys, it moves the focus to the next cell. JAWS is still unable to read a word at a time. It would seem that this would be a simple solution: to place a read-only cursor in all of the cells in the Grid all the time, with the focus rectangle surrounding the cell. It would eliminate the Section 508 issue, and would do nothing to detract from the performance of the application.
Evaluation of DBSTX Text Control Processor COTS
The Textview has some severe problems as well but it is slightly better than the Grid. By restricting the window that I wanted JAWS cursor to read, I was able to read the text as a single text block. However, I was unable to navigate the document to read by character, by word or by line predictably. I am unable to read any text by word and character at all. Reading line-by-line I may get one line of text with every third DOWN ARROW key. Because of what the examiners must do with the text, it is imperative that the user be able to gain access to all of the text in the window.
The examiners need to be able to select text, copy the information from the document, and paste to another location. Without the ability to read characters or words, selecting text precisely will be impossible to do. To activate the blocking function, the user needs to know where to place the cursor in order to start the blocking of the text. To most effectively accomplish this task, a system cursor within the text window would be the best way to control the blocking and copying function.
Strangely enough, the keyboard blocking function works with some kind of hidden cursor located within the window. There would appear to be an invisible cursor located in the text viewer window. I have been able to select text by character, word, and line using the standard Windows keyboard commands for selecting text, with certain limitations. I was unable to select text by paragraphs or pages, or the entire document.
The problem with this system is that I am unable to know where the focus is located within the window. There is no visible cursor, and there is nothing to indicate my location within the document. The only way that I know that I am blocking text is to start the blocking function. If I cannot predictably move to the specific location to start the text selection process, it is not usable. This function is designed to be performed using the mouse only, therefore it is not Section 508 compliant because there is no keyboard equivalent to select this text predictably.
Another issue is the random movement of the cursor when pressing the UP/DOWN ARROW keys. Like in Grid, when the JAWS cursor is active, without predictability the cursor will reverse direction from the actual direction of the arrow key being pressed. In other words, when JAWS is active and I am pressing the DOWN ARROW key, the JAWS cursor will reverse its order randomly, and then reverse itself again and go in the correct direction. The problem occurs whenever you press either the UP or DOWN ARROW keys. It would appear that JAWS is looking for an indication of where the line is within the window.
Within the Browser, using the PAGE UP and PAGE DOWN keys can scroll through the text. At this point JAWS does not read any of the text within the window when the text scrolls by. If this were a read-only text window, we could complete a simple script that would predictably read the text under these conditions.
Additional testing allowed me to determine how to move the invisible System cursor to the JAWS cursor by pressing Route PC to JAWS. This links the two cursors together. However, I am still unable to get the JAWS Cursor to read the text within the Textview window reliably.
To try to improve the performance of the Textview, I made a couple of changes. The first is that I changed the font size and font type back to the originally settings of Courier New 12 point. I have been attempting to read the text in the Textview window using the JAWS cursor. This has not been very successful. JAWS has two other cursors: the Braille cursor and the Invisible cursor. Since the cursor being used on the screen is invisible, I started reviewing the text in the window using the JAWS invisible cursor. This allowed me to gain access to all of the text elements within the application. I was able to read by character, word, line, and paragraph. I was able to gain access to all of the text within the window. I was even able to Route the JAWS Invisible cursor to the invisible PC Cursor, which then allowed me to select text. Unfortunately I was not able to get it to read back the selected text after the text had been blocked.
- Page tabs (BRS form, IS&R form, Image, Text) cannot receive keyboard focus.
- Image and Text pages have no keyboard commands.
- Text View cannot be read with the system cursor or the JAWS review cursor. Not being able to read this text is symptomatic of text not being sent through the operating system.
- The text and diagrams cannot be read in the Image View because they are in TIF format.
- Checkbox images are not consistent across the application.
- A thick cell border provides a visual indication of focus, but the focus is not programmatically exposed for AT.
- Color-coded column headers must be supplemented with text that is exposed to AT.
- Form elements (e.g., checkboxes) must have meaningful text labels, and must be keyboard accessible.
- EAST does not conform to system display settings. For example, with high-contrast system settings, Pane 1 colors do not conform, and Pane 3 displays black text on a black background.