[BRLTTY] The braillists forum and an article about reading in braille

Sébastien Hinderer Sebastien.Hinderer at ens-lyon.org
Sun Aug 29 15:53:50 EDT 2021


Dear all,

Recently I discovered the braillists forum. For those who don't already
know, it's a google group to which you can subscribe by sending an
e-mail to

braillists+subscribe at googlegroups.com

On this forum, somebody posted this link:

https://www.afb.org/aw/22/7/17623

I found it quite interesting and submitted the comment that you will
find below my signature.

Any comment is warmly welcome.

Best wishes,

Sébastien.

Hello,

Many thanks for the nice article.

Born blind, I am a daily user of braille displays. Well, since I am a conmputer scientist and also use braille at home, let's say that most of my life is spent in front of a braille display.

I would like to share several random remarks that came to me while reading the article:

1. the article does not mention those braille displays that can detect finger positions and adjust the auto-scroll accordingly rather than trying to guess when to do it based on the number of displayed character, which feels a bit more sensible.

2. One other point that I would find interesting to discuss is the ease of use: how comfortable it is to read, how quickly you become tired, things like that. For years, I wanted nothing else but 40-cells displays. I think it is because I am using 80x25 screen terminals in text mode, so with a 40-characters display you cover half of a line. However, lines of this kind of lenght, I noticed, require a lot of hand movements, while shorter lines, 28 characters long, say, as with printed braille, require less motions and are thus potentially less tiring. So I started considering having two kind of braille equipments, one with a 40 cells display to work with computers, and a shorter one dedicated to reading eBooks. Sadly, at the moment I read almost no eBook because I find it so tiring and long that it drains all my energy.

3. This brings me to my last remark which is actually a question. IN terms of efficiency, it feels like the ability to combine braille and speech synthesis could bring the best of both worlds, however depending on how it's done. I am dondering whether some research has already be undertaken in htat direction? As far as I know, no screen reader (in the wide sense of the word, i.e. a software giving access to the screen content, no matter how) has been designed with this question in mind. For all screen readers I know, their approach is asymetric. What I mean is that it feels to me either they have been designed primarily speech rendering, and then braille has been added later but is somehow considered a secondary, auxiliary rendering method. I think the big majority of the screen readers fall into this category and tha's why they have this name. Or it happened the other way around: a screen rendering system designed primarily for braille and where it's speech which had been added afterwards. The only example I am aware of here is brltty, which happens to be the one I am using constantly, with the addition of Orca when I need a GUI.

Many thanks for this article. I didn't realise there was research happening in this field but that quite pleases me.

Oh, and by the way: one other question I have is about typing properly. I didn't proof read all this text and you may notice it's full of typos. Is anybody aware of any method that would help a user of braillle to improve his typing, making it faster, less tiring and with less mistakes? The dedicated software seem quite visual. Of course, we have spell-checkers, but they will report the error only when you press the space bar, which might be too late. I mean, a sighted person will be able to fix a typo as soon as he/she makes it because the person has an immediate visual feedback, which may matter iin improving. So perhaps to compete, we blinds would need a more immediate feedback, too.

Dear Jagdish,

Many thanks for the very cool idea and all the work you have laready put
in it.

I am not a hardware expert so the only question I might have a response
to is the second.

I see too approaches.

1. Either you design a protocol suited for your device. That gives you
more flexibility but at the cost of writing a dedicated BRLTTY driver
that understands the protocol (not necessarily hard).

2. You have your hardware simulate an already supported one and thus
benefit from its already implemented driver. Theonly thing you'll have
to do is to find a protocol that is expressive enough for yoru needs.

Best wishes of success,

Sébastien.
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at brltty.app
For general information, go to: http://brltty.app/mailman/listinfo/brltty


More information about the BRLTTY mailing list