Re: Views on Keyboard Shortcuts to teach or, perhaps, emphasize when teaching

Lisle, Ted (CHFS DMS)

Good analogy.  I remember my first screen reader just loved the function keys.  There was a simple pass key arrangement to pass non-VOS keys to the word processer, which happened to be
DisplayWrite 3.  The transparency thing didn’t work so well, and they would slug it out at Interrupt Vector 9.  A buddy of mine, who was a data analyst, passed me a simple mod to DisplayWrite’s central batch file, and man, what a difference!  After that, you couldn’t crash those programs with a hammer.


From: Brian Vogel [mailto:britechguy@...]
Sent: Friday, January 08, 2016 11:44 PM
Subject: Re: Views on Keyboard Shortcuts to teach or, perhaps, emphasize when teaching


Thanks to all for this fascinating exchange of ideas.

Laura, your question is not in any way dumb and it is very difficult to answer easily.  It's relatively easy for me to know the difference because I can literally see the Windows keyboard shortcuts "reveal themselves" as the sequences are hit, at least a large number of them.  I certainly, for instance, didn't know the keyboard sequence that was used in Windows Live Mail to do a message search in its entirety, particularly the ALT+i for the find now key, but as I work through the process the first time with the client at each step Windows (or the Windows program) shows the next character or characters that are part of the sequence, allowing me to build the entire sequence for inclusion in the step-by-step directions.

I am glad, though, to hear others saying that it is important to make this distinction.  The main reason it's important to me is that there is a huge set of Windows keyboard shortcuts, the three best known being Ctrl+C (copy), Ctrl+X (cut), and Ctrl+V (paste), that are used in precisely the same manner in more programs than I can count.  There are many more that fall into the "extended common" set of Windows keyboard shortcuts and I want my clients to understand that, if they're in a pinch, and they know how to do "process X" in "program Y" that they should at least try seeing if "process X" will get the same result in different Windows "program Z."

The same concept applies to the JAWS layer as well, since you use the same JAWS keyboard shortcuts to accomplish the same tasks in a wide array of Windows programs.

If you know the difference between the two, though, and you have that knowledge "in your bones" you can actually sometimes function if speech goes south at a given point in time and still complete at least the current thing you're trying to do like save a file.

Another reason it's important to know the difference is because sometimes assistive technology like JAWS, ZoomText, or the like "captures" what would be a Windows keyboard shortcut for it's own use.  My client gave an example of this last night, that he'd figured out on his own.  He generally uses either ZoomText or JAWS (much more JAWS these days) separately along with whatever Windows program he needs beneath it.  The other day he had ZoomText, plus JAWS, plus some Windows program open.  One of the commands that we always used to perform a function in that Windows program when JAWS was running alone suddenly wasn't working in the Windows program, and ZoomText was doing something he'd never seen before.  He figured out for himself that ZoomText had commandeered that particular command for its own use and, thus, was not passed along to the Windows program running beneath it for processing.

I use the analogy of the various programs being like separate sifting screens stacked one atop the other.  The screen readers and other assistive technology are always the topmost screen.  They get every blessed keystroke you hit passed through them first, and these programs get to interpret those first, so if a keystroke sequence is considered a command by JAWS, for instance, JAWS does it's thing with that sequence and nothing from it sifts through to the program that is "the next sifting screen down."  Then, all of the keystroke sequences that JAWS didn't snag as its own get passed down to the next sifting screen, and for the purposes of this narrative lets say that's ZoomText.  Now ZoomText gets "first crack" at interpreting the sequences that have passed into its hands, and acts on any of those it recognizes as "my command."  Then whatever is left sifts through and falls into the screen that is the Windows program running below it for interpretation as commands it processes.  I think it's important for people to understand that there exists a hierarchy and that AT sits at the top of that heap and gets first crack at every keyboard input sequence to decide if it "belongs to me" before passing what remains on to the next guy.  Very often this may be irrelevant to doing what you want to do, but it can be key to understanding why "things that used to work" may work no longer if some other AT program gets added to the mix that ends up siphoning off commands that used to be passed through to other programs, so those other programs never see them.

Heavens, but the above seems awfully wordy, but I really can't think of a short way to describe the conceptual framework of program layers and that knowing about it can make sudden changes in behavior on your system a bit more understandable when new stuff enters the mix of programs running at the same time.


Join to automatically receive all group messages.