Re: [orca-list] suggestions for openoffice/orca improvements

["David E. Price" <deprice cs utah edu>]

Hi, Will,

Willie Walker wrote:
> The presentation of crossing page boundaries is an interesting thing 
> that I don't believe Orca handles.  If Orca were to handle this (I'm 
> not sure if we get the info we need from OOo or not), what do you 
> suggest the presentation be for speech and braille?
>
> As for speech output, I would suggest two things.  First, the current 
> page numbershould always be available through "where am I" if that is 
> the method for reading the status line. Second, I would suggest that, 
> when the user is crossing a page boundary, the number of the page 
> being entered is read before the content of that line.   For instance, 
> if the sentence "orca is a screen reader that works well with many 
> gnome applications." spanned the page break between pages 1 and 2, 
> with the page break occurring between "works" and "well", the user 
> reading downwards would hear: 


> Orca is a screen reader that works 

> page 2 well with many gnome applications. 


> If reading "upwards" through the document, the user would hear: 


> "well with many gnome applications. 

> page 1 Orca is a screen reader that works

There are two ways that the user might hear these page indications.  
When reading using "read all", the page number announcements are a bit 
more jarring and out of place than when arrowing through the document.  
However, I think that the user could easily get used to hearing these 
announcements and process them out of the text being read.  However, one 
way I can think of to indicate that the page numbers are not part of the 
text would be to have a "system voice" with different voice 
settings--this voice would be used whenever speaking an announcement 
that is not part of the current context.  But, I don't think this is 
needed in this context.  Do others agree or disagree?

> My Braille skills are pretty poor, so I don't use a Braille display.  
> As a result, my knowledge of what might work well in that output mode 
> is poor.  I think that suggestions for this should come from Braille 
> users.

Thanks for all the work,

dave