GNOME.org
 

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

Find my comments below.

Michael Whapples
On 01/-10/-28163 08:59 PM, Joanmarie Diggs wrote:

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.
The cause is probably the cost of Braille displays and so a much lower user base, however its good news it 
will get some attention.



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.
Good



Question 1a: I think seconds is preferable to milliseconds as far as a
dialog box is concerned. What about y'all?
I agree, although I am sure I could easily work in milliseconds due to some of my background.



Question 1b: If the consensus is to prefer seconds in the Preferences
dialog, how much granularity do you want? (i.e. ones, tenths,
hundredths)
I would possibly say tenths (seems a reasonable compromise between granularity and having too many steps to 
move through) although I also would say why not make it a text box and the user can enter any decimal value 
(OK, may be validation issues and if the steps are too great then I guess it can be altered in scripts).



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?
I think my answer depends on how orca behaves. If speech is disabled do these speech keys do anything? If 
they do nothing in this case then Braille need not show it but if they do then it would be useful for the 
user to be alerted. I am assuming here if you are unable to hear the speech (for what ever reason including 
not having the speakers on) you would silence/disable speech.



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.
Agree



* 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.
I would say the former group should be flashed but progress bars can be done by letting the user place flat 
review over the progress bar (assumes updates will be shown using flat review, I know there are some cases 
where flat review doesn't show changes happening). I think it could get quite annoying to have progress 
flashed up while you try and get on with something else.



* 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 agree for the short term and your long term view of what should be done (we need to work out what form the 
mark up will take).



(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.
I think flash messages could help here.



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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]