Hi Tim, Sorry, I should have elaborated more on the resizing field thing. That was not so much for sight impaired users, but more for those who are able to type, but not use a mouse.
Eric -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Timothy Powell Sent: Thursday, October 12, 2006 12:33 PM To: arslist@ARSLIST.ORG Subject: Re: Key combination CTRL-SHIFT-END in numeric spinner field crashes usertool Table fields and results lists do seem to still be the problem areas. Also as I recall, if you are on a page holder with multiple pages, and the cursor is on one of the tabs, the keyboard combos take you to the first and last pages on the holder respectively. But if the cursor is on a field within a tab, the keyboard combos take you to the first/last fields on the form. - To select nonadjacent fields: click on the first field, press and hold the CTRL key, and select one or more additional fields. When doing this in report creation, I can think of no way to be able to accomplish this without use of a mouse. IMHO, non-Sighted users are not severely impacted as they can still select nonadjacent fields individually and accomplish the task. - To resize fields: ... Select any field. Place the cursor on one of the field's control handles. Hold down the mouse button, and move the mouse in the direction you want to resize. Can you elaborate as to why a non-sighted user would want to do this? Limited sight users I can maybe understand, but then they can use the Windows based screen magnification or 3rd party magnification tools like Zoom-Text to make the fields and text bigger. Tim -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Eric Cleereman (IT) Sent: Thursday, October 12, 2006 11:42 AM To: arslist@ARSLIST.ORG Subject: Re: Key combination CTRL-SHIFT-END in numeric spinner field crashes usertool <RANT> Remedy WUT's help file shows: Go to the first field in the tab order - SHIFT+CTRL+HOME Go to the last field in the tab order - SHIFT+CTRL+END Excel's Help file shows: CTRL+SHIFT+HOME Extend the selection to the beginning of the worksheet CTRL+SHIFT+END Extend the selection to the last used cell on the worksheet (lower-right corner) Word's help file shows: CTRL+SHIFT+HOME To the beginning of a document CTRL+SHIFT+END To the end of a document Even in version 7, patch 2, Remedy does not seem to adhere to the behavior described in their help file. Here are a few examples: - In a table where Single Selection Only is not checked, pressing SHIFT+CTRL+END selects everything from the current row through the last row. This seems to be more like Excel's described behavior. However if Single Selection Only is checked, the cursor will move to the last field in the tab order. - In a results list, pressing SHIFT+CTRL+HOME selects everything from the current row through the first row. This seems to be more like Excel's described behavior. - In a non-expanded character field, SHIFT+CTRL+END will move the cursor to the last field in the tab order, but SHIFT+CTRL+HOME selects everything from the current cursor position through the first character. This seems more like Word's described behavior. Remedy also has documented functions which seem to work only with a mouse: - To select nonadjacent fields: click on the first field, press and hold the CTRL key, and select one or more additional fields. - To resize fields: ... Select any field. Place the cursor on one of the field's control handles. Hold down the mouse button, and move the mouse in the direction you want to resize. If anyone knows how to select non-adjacent rows or resize fields without a mouse, please let me know. I've had this request from a few users. Section 508 shows the following tests for keyboard operability: 1. Inspect the application. Unplug/disable all input devices except the keyboard, then attempt to execute the identified set of product functions using only the keyboard. a. Can the function be executed via the keyboard? b. Is the result of performing the function via the keyboard as expected or advertised? 2 Inspect the program documentation. Note that the identified set of functions can be invoked from the keyboard. For applications that have a graphical user interface (GUI), identify any menu commands that cannot be executed from the keyboard. a. Are there documented functions that have no documented keyboard equivalent in the OS or Application? b. Are there commands that require pointing or visual analysis of the screen contents? Note: Satisfying this requirement does not involve interoperability with assistive technology. It would sure be mighty swell if all the features worked as described within Remedy, but they seem to have a lot of undocumented exceptions overall. I try to use the following as a best practice: - Use Mid-Tier instead of the WUT if at all possible. Mid-Tier gives you far great control of not only keyboard accessibility features, but also text to speech, font size, etc... - Document the features that work consistently, and those that don't. - Use the features which work consistently. Don't use that that do not. - Test everything with just a keyboard for input, and a small fuzzy monitor for viewing. - Write good user-level documentation. One last point that's helped me to remember. Work with your users. Find out what they need. Many issues can be addressed better with hardware than software. For instance, a user with poor sight probably can't read a 1024x768 form on their 15" monitor. The same user may be able to read that form just fine when provided with a 27" monitor, still running at 1024x768. Recoding the same form to work for that user at 480x640 on their 15" monitor would result in a lot more work, smaller overall pixels, and a lot of scrolling. Multiply that work by however many forms that user needs access to. </RANT> Eric Cleereman -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Timothy Powell Sent: Thursday, October 12, 2006 10:18 AM To: arslist@ARSLIST.ORG Subject: Re: Key combination CTRL-SHIFT-END in numeric spinner field crashes usertool ** I think you'll discover that the 7.0 Patch 2, UT release not only does some quite remarkable things related to keyboard navigation......new things that Remedy has never been able to do before, but also makes big leaps towards the UT being Section 508 compliant. It should make life much easier for our users with limited/no sight. Tim _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Thursday, October 12, 2006 10:12 AM To: arslist@ARSLIST.ORG Subject: Re: Key combination CTRL-SHIFT-END in numeric spinner field crashes usertool ** Glad to know there's a legitimate reason for it, Tim. In that case, it should be fixed. Rick On 10/12/06, Timothy Powell < [EMAIL PROTECTED]> wrote: ** > .....Sorry to be unsympathetic here, but is there a legitimate > business reason to perform that key combo as part of processing a ticket..... Rick, These keyboard combos are VERY useful for users with limited or no vision, that rely completely on keyboard to do their navigation. SHFT-CTRL-END combo takes you to the last field in any given form. SHFT-CTRL-HOME combo takes you to the first field in any given form. Try tabbing from the middle of the HPD:Helpdesk form to the first or last field....not pretty. In a numeric spinner, the SHFT-CTRL-HOME combo also crashes the UT. This should be addressed in the 7.0 Patch 2, User Tool release. Tim _____ From: Action Request System discussion list(ARSList) [mailto: ____________________________________________________________________________ ___ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org