Re: [orca-list] braille positioning (was Re: progress of progress bars is not reported., is it a known thing?)

[Marco Skambraks <marco suse de>]

hi,
On Mon, 7 May 2007, Willie Walker wrote:

> Aha!  Mike and I are talking today, and I think we figured out what is
> going on here.  If *all* the text can fit on the display, then Orca puts
> it all there.  If the text cannot fit on the display, Orca positions the
> most important information starting at the first cell. 
>
> It seems like the behavior should always be to position the most
> important information starting at the first cell, regardless if the
> entire line can fit on the display or not.  Does that sound about right?
it sounds more right than the other approach :-)

but I don't understand why the braille-string is genrated this way
usually, the frame title is displayed in front of the first element in a 
frame - like this:
"orca screenreader / magnifier preferences"

the focus is on preferences

if you display the cursor at the beginning of the braille display so that 
only "preferences" is displayed - it looks right, but it isn't right
"orca screenreader / magnifier" is the title of the frame (I guess) and it 
should only displayed if I asked for it
so there is no need to add this to a braille-string  in order to hide it
by shifting the braille display until the focus is at first position

additionally I would like to see the "quit button" right from the 
"preferences button" on my braille display
so it should look like this:
"preferences  quit"

if I press quit in this dialog the next displyed string is:
"orca cancel"

why is the word "orca" in this string?
it should look like this:
"cancel quit"

for speech it is OK to output only the active button otherwise it will 
confuse the user, but for braille it would be nice to have an overview of 
all elements in the current line - because then it makes sence to use the 
cursor-routing



I know it looks like a mix of flat-review for braille and 
cursor-tracking-mode for speech
there are different needs for speech and braille

in most cases generating braille-output-strings is completly different
to the speech-output-strings

so, don't try to find a generic way for both - speech and braille
try to see speech and braille separatly and then find a way to sync both 
parts

if the develpment focus is on speech-representation it's very hard to add 
a good braille-support

if the focus is on braille-representation it's very hard to add a good 
speech-support

so, that's my experience of several years of screenreader development and testing

I hope this information is helpful for the developers

marco




  > 
> Will
>
>
> _______________________________________________
> Orca-list mailing list
> Orca-list gnome org
> http://mail.gnome.org/mailman/listinfo/orca-list
> Visit http://live.gnome.org/Orca for more information on Orca

------------------------------------------------------------
Marco Skambraks, Product Manager
SUSE LINUX Products GmbH,  Maxfeldstr. 5,  D-90409 Nuernberg
T:   +49 (0) 911 74053-0
Fax: +49 (0) 911 74053-483             marco skambraks suse com
------------------------------------------------------------
** life is hard and then you die **