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
