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

[Michael Whapples <mwhapples aim com>]

Hello,
I've noticed one difference between speech and Braille although I think 
there may be other issues at play as well.

I was just seeing if the voice and video version of the skype4pidgin 
plugin allows video. When I went to set up the skype account I choose 
add new account, select skype from the list of protocols fill in that 
page and then move to the tablist. Braille shows the tab we are on at 
this point, speech only said tablist. If I move right Braille changes to 
"proxy page" but speech says nothing. Pressing right again Braille and 
speech don't change (I believe this is the other issue I am getting at, 
I think a tab was added when we selected skype as the protocol but flat 
review also indicates only two tabs). Anyway back to the point, press 
right arrow again and Braille changes back to "Basic page" speech still 
says nothing. Cursoring left also gives similar results.

As I said may be the additional tab being adding might be causing a 
difference but Braille and speech do differ here so I thought worth 
mentioning.

Michael Whapples
PS. For those interested in my results of the skype4pidgin and video 
results, the binary didn't work on my system it kept crashing pidgin. 
Some said pidgin can't do video, I found a plugin on my system which is 
for voice and video and allows you to configure video input/output so 
may be it is possible (although I am sure skype is another matter as 
input/output is handled by skype).
On 05/10/2010 09:30 PM, Joanmarie Diggs wrote:
> Hey Michael.
>
>    
> > 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.
> >      
> Yeah, braille displays are insanely expensive. And then we (or at least
> some of us) wonder why braille literacy is so low.<frowns>
>
> The other knee-jerky reaction I had to your comment is that in the world
> at large users who are blind or visually impaired are labeled a "low
> incidence population." And it is this sort of attitude that makes
> certain companies (plural) put things like accessibility on the back
> burner. Within the blindness community, Deaf-Blind users are in many
> cases the "low-incidence population." And as a result, their needs have
> gone on the back burner for way too long.
>
> What often turns out to be the case in the world at large is that with a
> little thought and careful planning, implementing accessibility in a
> product isn't actually all that hard. It's not that much work. And it
> makes things better for all users. Likewise, what I'm seeing as I tackle
> this problem, is that it isn't all that hard. It's not that much work.
> And I think it will make things better for all Orca users.
>
> A very long way of saying that I'm glad you think it's good news. I hope
> that opinion is shared by the whole community.
>
> Now, if you can help me jump down from this really high soapbox, I'll
> respond to the rest of your message.<grin>
>
>    
> > > 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).
> >      
> Actually, an editable spin button should give us what you describe: You
> can manually enter values instead of arrowing or using page up/page
> down. And spin button validation magic will do the rest.
>
>    
> > I think my answer depends on how orca behaves. If speech is disabled
> > do these speech keys do anything?
> >      
> I'd have to double check in the code. To be honest, given that we do the
> work to display braille even when braille support and braille monitor
> support are both disabled, it very well may be that we do.<smile>  I'll
> add that to my to-do list.
>
>    
> > > 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.
> >      
> Agreed. I since tried it. It was all braille percentages all the time.
> Major fail. So I will not be tackling the braille progress bar
> percentages; only the former group ("loading please wait", "finished
> loading") as you suggest. Once all the easy stuff is in place and
> tested, we can revisit the issue of progress bar updates in braille.
>
>    
> > 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).
> >      
> And by "we" I assume you mean y'all.<smile>  While I read braille, have
> a braille display, have taught braille, etc. all courtesy of my DayJob,
> I have no clue on what the specifications of braille display text
> formatting mark up should be. I need the Orca community to work this one
> out, come to a conclusion, draft up a very specific list specifying the
> implementation details, and filing a bug. If you tell me what I need to
> do, I'd be happy to do it.<smile>
>
>    
> > > 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.
> > >        
> Yup. I do too. The status bar, title bar, and default button changes
> have been checked into master.
>
> What I meant by spot checking is that right now, I can quickly go
> through the code, looking for instances where we speak something, look
> at the surrounding code to see if we're also brailling it, and fix as
> appropriate. In the case of the status bar, title bar, and default
> button, the code suggested we were brailling this information. Closer
> inspection and actually trying it suggested otherwise. While I will go
> through all of the code looking for these cases, it would be extremely
> helpful if, when you come across them, you shout them out like Jacob did
> on the OpenOffice help tree view items.
>
> Take care.
> --joanie
>
>