Hi! Its an intresting thought though. So i am intrested in this. /A > 18 aug. 2020 kl. 07:48 skrev Aura Kelloniemi <[email protected]>: > > Rich <[email protected]> writes: >>> On Aug 17, 2020, at 09:03, Mario Lang <[email protected]> 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 > _______________________________________________ > This message was sent via the BRLTTY mailing list. > To post a message, send an e-mail to: [email protected] > For general information, go to: http://brltty.app/mailman/listinfo/brltty
_______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
