Speakup Requirements

* Speakup Requirements
@  Janina Sajka
   ` covici
   ` Chris Brannon
  0 siblings, 2 replies; 10+ messages in thread
From: Janina Sajka @  UTC (permalink / raw)
  To: Speakup is a screen review system for Linux.

The conversation about the future of Speakup is important as witnessed
by the flurry of mail here this past few hours. However, we've also
strayed into the usual range of related issues. I'd like to put in a
place holder for a fundamental question:

What are our console screen reader requirements?

We should, imo, have community consensus on our requirements, probably
backed by use cases, than we can clearly communicate.

Had we had such back in the mid 2000's, pulse might have been designed
better. I say this about pulse, because I don't believe it meets one key
requirement we have, low-latency response, char by typed char, word by
word, etc.

To my mind we'd be better served by jack where latency and high priority
execution are core values.

So, what are our requirements?

1.)	Latency. Very low, and highly responsive feedback in the
consumption of keyborad input, whether into the system or as screen
review.

2.)	Access to on screen messages as early and late as possible, as
close to boot, and as late in shutdown as possible.

Then, if we have to move to console. What we we like that we have not
had since Kirk first published his kernel patch back 20 years ago?
Here's my top ask:

A.	Context aware profiles. DOS had this in spades. You could know
what application had focus and adjust the screen reader behavior
accordingly. ASAP and Vocal-Eyes were brilliant at responding to
WordPerfect, Commo, etc., etc. If we're going to console space, let's
make sure we can be app focus aware.

What else?

Janina

John G. Heim writes:
> I've never seen a server without a serial port.
> 
> 
> 
> On 10/08/14 14:43, Kyle wrote:
> >It does appear to me that something like this will force more of Speakup
> >into userspace. However, unlike others, I'm not entirely opposed to the
> >idea of Speakup leaving the kernel, and I think it can only be a good
> >thing, especially on newer machines, where dedicated serial ports are
> >all but obsolete, and software in userspace can take better advantage of
> >things like Pulseaudio and libusb, meaning more extensive software and
> >hardware speech support. For example, there would no longer be a need
> >for kernel modules to control speech synthesizers, and there would no
> >longer be a need to have external userspace connectors such as Espeakup,
> >as the entire Speakup screen reader could be moved into userspace, and
> >anything that interfaces with a speech synthesizer could be either
> >internal or could be a library that interfaces with a speech API like
> >speech-dispatcher or others. Even better, if Speakup is moved entirely
> >into userspace, it could give rise to far better access to consoles on
> >*BSD and other Unix operating systems, as the code could be far more
> >portable between operating systems when it doesn't have to be tied into
> >a specific kernel. Just my $0.02 BSD. That's Bahamian dollars lol.
> >~Kyle
> >http://kyle.tk/
> >
> _______________________________________________
> Speakup mailing list
> Speakup@linux-speakup.org
> http://linux-speakup.org/cgi-bin/mailman/listinfo/speakup

-- 

Janina Sajka,	Phone:	+1.443.300.2200
			sip:janina@asterisk.rednote.net
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair,	Protocols & Formats	http://www.w3.org/wai/pf
	Indie UI			http://www.w3.org/WAI/IndieUI/

^ permalink raw reply	[flat|nested] 10+ messages in thread