[ossrp-control] Re: I Think It's A Great List

Hi,

Also, taking a properly modular, or more likely object oriented approach to
the project, means that a Braille handling object would be the most sensible
way to go.  That way, the screen reader itself would just deal with that
object, and any internal special implementation required for different
Braille devices would be encapsulated within the BrailleDevice object.
Taking this along with the earlier stated desire to have patches and updates
rolled out automatically for enhanced sections, means adding support for
further Braille displays would be relatively simple.

In the early stages of the project, the BrailleDevice object could be
present, but simply be a dummy until such time as specific driver support is
added down the line.  Thus, any calls by the screen reader to pass
information to the TTS could also automatically be routed through the
BrailleDevice object, and you're on your way.

I imagine a similar approach would be adopted for the synthesizer interface,
to minimise the core impact of adding support for different synthesizers.

All the best,

David


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: 29 April 2005 08:39
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: I Think It's A Great List


Hi Jamal,

I agree that a large feature set is something that is really undesirable at
this stage.  However, I feel that Braille shouldn't pose a significant
obstacle.

Yes, I am aware that there's no standard interface for Braille drivers.
However, I suspect that quite a lot of the code, other than that from the
Braille device's API, could be reused between drivers.  As not everyone will
have a Longhorn kernel mode driver for their Braille display straight away,
Braille support is likely to be something that will be spanned over time,
and the initial coding need not even start until the first Braille device is
supported under the Longhorn kernel.

I respect your desire to have version 1 on time, but I think we have the
resources to do quite a lot of what people want.  From a project management
perspective, Braille isn't as resource hungry as something like scripting
capabilities would be, both initially and in terms of maintenance.

Will
----- Original Message ----- 
From: "Jamal Mazrui" <Jamal.Mazrui@xxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Friday, April 29, 2005 8:07 PM
Subject: [ossrp-control] Re: I Think It's A Great List


Hi Will,
As long as you do not think braille support would considerably delay the
initial release of the screen reader, I have no problem with its inclusion.
You used the term "braille driver," but I assume you know we are not just
talking about a device driver that sends the same text to a braille display
as a speech synthesizer.  Proper braille support additionally involves a
significantly different approach to the user interface.  Also, as far as I
know, there is no accepted standard for hardware communication with a
braille display, so several device drivers would need to be written to
accomodate the various ones around in the U.S. and abroad.

Besides thoughts I have already expressed about financial calculations, Let
me say that I recall how difficult braille support was for GW Micro, which
did not add it to window-Eyes for several versions, despite a solid history
in assistive technology.  Hence, I have been concerned about the screen
reader not being available to blind people who need a free one because of an
overly ambitious feature set for its initial release.

You had asked for feedback on initial requirements, and I took this at face
value to mean an intention to reasonably manage the initial scope of a
project essentially developed by volunteers.  I notice that Apple has not
included braille support in the "Voice-Over" screen reader it released today
as part of its new operating system.  The company surely knows of an
interest in braille support and has paid development staff who have been
working on the software for a few years, following the initial out-sourced
work that was done by experienced individuals at WGBH.

Although it is not politically easy to do when various, potential
beneficiaries have different, legitimate interests, boundaries do need to be
drawn for software to actually be published and instill confidence in
supporters that it is not well-intended, but never realized vapor ware.  As
another example, there are potential beneficiaries for whom neither speech
nor braille is workable, e.g., those with a particular interest in screen
magnification.  Still others can use speech as output but lack the motor
skills for keyboard input, and thus have an interest in a voice recognition
capability for operating the screen reader. Should the screen reader be
released initially without international language versions, since English is
not native to many in developing countries?  There are many, noble goals,
but an open source screen reader cannot be all things in its debut release.

Regards,
Jamal

-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
Sent: Friday, April 29, 2005 2:14 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] Re: I Think It's A Great List


Hi Jamal,

Writing a Braille device driver isn't too much of a problem.  I know someone
who's been working on a home-brewed Braille translation module, so we may be
able to use that.  So, Braille shouldn't be a difficult or time consuming
feature to implement.

I think Braille is an important feature of a screen reader, as not everyone
is capable of using speech, and in some situations speech is an undesirable
output modality.  There's also the on-going debate over the improved
literacy of Braille users over those of speech users, mainly in the area of
spelling as speech users tend to spell phonetically.

So, to make it available to the widest group of users, and to provide the
best quality that is possible, Braille really needs to be there. Failiure to
provide Braille would exclude those who cannot use speech, and that's a
route I really don't want to go down.

Will
----- Original Message ----- 
From: "Jamal Mazrui" <Jamal.Mazrui@xxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Thursday, April 28, 2005 2:57 PM
Subject: [ossrp-control] Re: I Think It's A Great List


That is a good point about the braille support.  If someone can afford or
have given to them an expensive braille display, then it is unlikely that
they cannot also obtain a commercial screen reader.  I do think that braille
offers unique accessibility features, so I do not mean to discout braille
access generally.

If braille were to be added in a version later than the initial version of
the screen reader, then it still probably makes sense to ensure that the
design accounts for whatever is needed for braille support, even if the
details are not initially filled in.

Jamal


-----Original Message-----
From: ossrp-control-bounce@xxxxxxxxxxxxx
[mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Tony Broome
Sent: Wednesday, April 27, 2005 11:13 PM
To: ossrp-control@xxxxxxxxxxxxx
Subject: [ossrp-control] I Think It's A Great List


It seems that almost everyone has added to the list of Will's suggested
inclusions in the first version.  Some of them seem quite techy and advanced
for this particular phase, in my humble opinion. I think it's a great
starter list, far beyond what version 1 of any other access product has
attempted to offer. While we certainly want the reader to do all it can and
to cover as much ground as possible, according to the project name, it is or
will still be considered a Screen Reader.  Now, whether that means just
reading the screen as has been the case in the conventional sense, is open
for everyone's interpretation. A good common sense approach, in my judgment,
would be a Screen Reader with this definition: A reader which reads and
gives adequate speech output, necessary for one to be able to use the
computer effectively. Braille support is great if you can afford the high
cost braille displays.  That's just a fact of life, isn't it?  Hopefully,
refreshables will come down some day. To push for this over speech when
speech is so much more affordable and certainly in compliance with the
outset and design of the project, is to hide one's head in the sand.

Smile,

Tony

-- 
Email services by FreedomBox.  Surf the Net at the sound of your voice.
www.freedombox.info To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes


To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes



To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes


To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes



To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx To
unsubscribe, send a message to: ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the
quotes

To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: