[orca-list] Calling all braille users. I need your opinions.

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hey guys.

As some of you know, I've never been jazzed by Orca's presentation of
content in braille because in many instances braille seems to have taken
a backseat to speech output. And that excludes users who are Deaf-Blind.

My goal for tonight and tomorrow is to at least start making some
progress on this front. And I want to do it right, of course <smile> So
I'm going to toss out a few examples, some stuff I'm thinking about
doing, some questions for y'all, etc. If you can give me some direction
so that we can balance equal access to software and information with
your personal needs as an existing Orca user, it would be awesome.

Background: Orca recently got braille "flash" message capability. This
allows us to display a message temporarily and then restore your display
to whatever was showing before (i.e. object with focus, text you're
editing, etc.) The duration is determined by settings.brailleFlashTime
and defaults to 5000 milliseconds. Thus you can configure the duration
-- even making it 0 if you don't want flash messages at all -- and can
do so on a script-by-script basis. At the moment, this option cannot be
set via the Orca Preferences dialog.

Action item 1: I will add the ability to specify the duration to the
Preferences dialog.

Question 1a: I think seconds is preferable to milliseconds as far as a
dialog box is concerned. What about y'all? 

Question 1b: If the consensus is to prefer seconds in the Preferences
dialog, how much granularity do you want? (i.e. ones, tenths,
hundredths)

Keeping in mind that you can configure/disable this setting on a per
script basis, and that any message I "flash" to you will disappear so
you can resume working without having to press any keys....

Action item 2: I am planning to locate all places where we are speaking
a message but brailling absolutely nothing and changing that. <smile>

Examples:

* Structural navigation where there is not a match ("No more headings
found"). It's only spoken; I propose that same string be flashed as well
to confirm that it tried to find something but failed to locate it. (As
opposed to the command was broken and a bug needs to be filed.)

* Keys which change settings on the fly ("bypass mode enabled").

Question 2a: What about keys which change a speech-only setting on the
fly, e.g. to toggle the speaking of indentation and justification?
Should we flash it in the spirit of fully equally speech and braille, or
not display it in braille because if you toggled the speaking of
indentation and justification, you are probably also using speech and
were able to hear the message?

Note that I think toggling speech enabled/disabled should always be
flashed because it wouldn't be redundant if something had gone wrong
with your synthesizer.

* Progressy updates. There are two such categories: Spoken messages to
let you know an app is busy ("loading please wait", "finished loading")
and actual progress bars. Personally, I'd flash the former
automatically; I'd flash the latter at the same time we were speaking
the percentage.

* Text formatting (i.e. when you press Orca+F). Orca does allow you to
underline desired attributes in braille. But if you want to know if
something is bold versus underlined, you currently have to ask Orca with
Orca+F -- and currently you have to be able to hear because we only
speak that info. There are, in my mind, two issues here: We should have
an efficient way of marking up text and optionally showing the
formatting in braille without your having to read through everything
Orca+F outputs. But given that at the moment, that's not in place, I'm
very strongly leaning towards Orca+F displaying the same thing it
speaks.

(I bet that one might be controversial <smile>)

Action Item 3: I plan to go back and review all the areas where the code
suggests we are presenting in braille but implemented before Flash
messages.

Example: If you read the status bar or the title bar, the code would
suggest that we're presenting that in braille. When I try it, however,
it seems that we're continuing to show the locusOfFocus. Which makes
sense in a certain frame of mind, but.... I've got a lot of spot
checking to do.

Anyhoo.... My apologies for the lengthy message. My guess is that there
will be things we all agree upon and things which will require some
discussion. I'll start working on the former. <smile>

Thanks guys. As always, I really appreciate your input on these sorts of
matters!

Take care.
--joanie