[BRLTTY] [OT] How to integrate BSI into a Linux cell phone?

[Aura Kelloniemi]

Rich <rdm at cfcl.com> writes:
 > > On Aug 17, 2020, at 09:03, Mario Lang <mlang at blind.guru> wrote:
 > > A physical keyboard doesn't sound like a real problem.

 > I'm mostly basing this on comments by a blind friend who uses an old, small
 > iPhone for much of her Internet access.  She is unhappy that all of the new
 > iPhones are larger than she wants or needs; carrying around a keyboard (even
 > a small, folding one) would be a nuisance.

I kinda understand her. When I'm running to a bus stop while trying to check
out the time tables with one hand at the same time (the other hand holding
the white cane), I really prefer if I don't also need to hold a braille
display and a physical keyboard at the same time.

I think there are two very different use scenarios here:

1. A mobile computer with braille & speech support

Here we don't need BSI (or the touch screen at all) for input, because we have
a big braille display anyways, we can as well add a physical keyboard. Many
braille displays have a braille input system available too.

I suppose that with PostmarketOS this setup is already very easy to achieve. A
rebuilt kernel with VT support is probably the only thing needed.

(Rich, for your information, braille with BRLTTY is not really supported in
graphical terminal emulators. Emulators that support at-spi2 are
accessible to some extent, but this support is not up for day-to-day use. I
have never managed to get good (low-latency) support for braille in Orca. Orca
in general, is a grief.)

2. A mobile phone accessible anywhere without additional devices

For this scenario BSI really is a good way to go for input, I think. But
still it has a problem of not being accessible with one hand. Maybe a huge
full-screen virtual keyboard grid might be another option. BSI and VKBD don't
need to cancel each other out.

For output, speech is the only option here (see my running scenario above).

But this usage pattern is not supported by any existing applications in normal
Linux world. All applications that the user wants to access need to have
a special user interface.

Answering a phone call with a command sequence like this, would be very
inconvenient:

$ call-manager list
  N   Caller          Phone number   Status   Time
Incoming calls:
  #1  Mom             +358491234567  Ringing  2020-08-18T09:03:15 +0300
Outgoing calls:
  #0  The Hot Date    +358459876543  Active   2020-08-18T08:59:42 +0300
$ call-manager set-hold #0
Call #0 (to The Hot Date) set on hold
$ call-manager accept #1
call-manager: #1: No such call

(As you can see, my Mom has already disconnected before I could typ alll the
commands needed to answer her call.)

Applications, which cannot be operated using CLI commands at least include a
web browser, phone call manager, text editor, messaging application (this
being the easiest to convert to a CLI setup) ...

Basically, if you are not willing to implement a complex desktop accessibility
system from scratch, X windowing is of no use here. Orca is written in Python,
and it has latency issues even on a modest desktop PC, let alone a worn-out
ARM device.

 > Join the club :-).  The reason I mention a windowing system (really, desktop)
 > is that most Linux systems I've seen seem to bundle session management and
 > other features into something like MATE.  Ideally, however, I'd like the system
 > to work without that overhead.

As a blind user, I mostly don't have access to a desktop session. I need to
adapt my computer usage patterns to that. BRLTTY does not really work well in
a graphical environment. That's why almost everybody here (I think) uses a
plain Linux VT. If we had the resources to make BRLTTY work well in a
graphical terminal emulator, we would have done that long ago. For example, we
would have enjoyed full unicode support and extended character attributes for
ages.

The sad thing is that desktop accessibility is a broken addition to the Linux
desktop standards, and support for accessibility in Linux world is a low
priority for most developers.

This needs to be taken into account when choosing a viable target system for a
mobile phone.

Either a lot of supporting infrastructure has to be developed for use in X, or
power management/session handling needs to be ported to the text-only
environment of a virtual console.

I would guess that the first option (of using X) would be preferred from an
average user's viewpoint – for example nowadays people expect to be able to
browse the web with their phones (even many blind people do).

>From a developer's perspective, the option B of porting the necessary bits to
the console world sounds more applealing to me – it is just so much simpler.

-- 
Aura