RE: How to demonstrate how well disabled people understand

[Scott Luebking <phoenixl@sonic.net>]

Hi, Gregg

OK  I didn't realize that the keyboard was an absolute requirement for
EZ-ACCESS when entering text.  I was more under the impression it was
only preferable.

I was wondering what usability testing was done for the functionality
reviewing text and reorienting.  Did users figure out how to do this?
Did they have any problems for resuming text entry?  Also, did users
get confused about how to cancel?  Was any testing done on the parallel
nature of of signalling completion and signalling cancelation?

Scott

> Hi Scott
> 
> Here are the answers.   First you should know that any Trace
> implementation on a device that requires text entry would have a
> keyboard.    So the answers to your questions are below in ALL CAP.
> 
> Scott wrote:
> OK.  With regards to the Trace system, how would a blind user enter text
> with all the specified functionality:
> 
>     a.  enter text   -- TYPE ON THE KEYBOARD.
> 
>     b.  review text  --  PAUSE AND LISTEN WHEN TYPING -- OR USE
> ARROWKEYS TO MOVE UP TO DISPLAY WINDOW TO HAVE TEXT READ OR SPELLED BACK
> TO THEM
> 
>     c.  edit text  -- USE BACKSPACE KEY
> 
>     d.  clear text   --  USE BACKSPACE KEY
> 
>     e.  get help while performing functions   -- PRESS GREEN DIAMOND EZ
> BUTTON FOR CONTEXT HELP
> 
>     f.  reorient back to task when disrupted  --  USE ARROW BUTTONS TO
> READ UP AND DOWN SCREEN.  AT TOP IS NAME OF SCREEN.   EZ HELP KEY GIVE
> CONTEXT SENSITIVE HELP
> 
>     g.  complete entering text   --  STOP TYPING.
> 
>     h.  cancel the task requesting text   -- USE ARROW BUTTONS TO MOVE
> TO THE 'CANCEL' BUTTON AND ACTIVATE IT.
> 
> How efficient would blind users be with the Trace system to enter text?
> 
> HOW EFFICIENT IS IT TO TYPE ON A KEYBOARD.
> 
> Scott
> 
> PS  Please remember I did ask about needed "functionality" which this
> is.