<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
