[Grml] How are blind grml users handling currentwebtechnologies?

Michael Whapples mwhapples at aim.com
Thu Nov 3 23:51:15 CET 2011

May be what you describe explains the difference of view. I am coming at 
it from a home/enthusiast view, so laptops would be more common and you 
may not have someone sighted nearby at the time to help out.

I figure that may be in a business situation you may have another 
computer (even your own laptop) which you could use SSH to access a Live 
environment like GRML and so may be not so reliant on what is included 
for accessibility.

With LiveCDs one needs to draw a line somewhere due to the capacity 
restrictions and so sometimes things need to be left out. Also in a 
business/work situation, if something was so important to that 
individual then surely they would be prepared to remaster GRML with what 
they need and may be remove things of little use (eg. X).

Should a liveCD include the most important features for the most people?

I think all that is coming out, some find software speech more important 
and others find Braille more important, therefore both are quite 
important really both should be there. Out of interest, what are the 
capacity hits for each of these? Remember with brltty there may be a 
number of packages not really needed for it such as python bindings, 
drivers for X terminals, etc.

Michael Wahpples
On -10/01/37 20:59, John G. Heim wrote:
> Right. But this is a key point... More people get colds every year 
> than get cancer. But if you could cure cancer or the common cold, 
> which would you choose?  I'd choose to cure cancer.  Its not just a 
> matter of how many people need something. You also have to take into 
> account how important the needs are.
> I have yet to see a server class machine, either rack mounted or stand 
> alone, that doesn't have a serial port. Your laptop probably doesn't 
> have a serial port. But you're not going to lose your job if you can't 
> rescue your laptop.
> ----- Original Message ----- From: "Michael Whapples" <mwhapples at aim.com>
> To: "John G. Heim" <jheim at math.wisc.edu>
> Cc: <grml at mur.at>
> Sent: Thursday, November 03, 2011 10:17 AM
> Subject: Re: [Grml] How are blind grml users handling 
> currentwebtechnologies?
> I possibly would rank software speech above Braille, its probably 
> useful to more people. Don't know so much for desktop and server 
> systems, but certainly on laptops serial ports are disappearing (if 
> not fully disappeared) so there are cases where hardware speech output 
> is not an option even if you have the hardware synth.
> I think this is just a difference of view, you seem to be taking the 
> route of what groups are enabled rather than how many individuals 
> might use it.
> I possibly would agree with you more if speakup could work with USB to 
> serial convertors or with USB synths. Alternatively are there other 
> screen readers which may work with USB to serial convertors or USB 
> synths (eg. as YASR is user space would that work with USB convertors, 
> although YASR I think is no longer developed).
> Michael whapples
> On 3 Nov 2011, at 14:42, John G. Heim wrote:
>> I rank the accessibility nees like this:
>> 1. Speakup kernel modules
>> 2. Braille support (brltty)
>> 3. Software speech (espeak and espeakup)
>> 4. Beet when boot is finished
>> The reason i rank braille ahead of software speech is for deaf/blind 
>> systems administrators. If you're blind, you can get a hardware synth 
>> but if ther is no braille support, systems admins who are both deaf 
>> and blind are out of luck.
>> I hope people don't think I'm exaggerating when I talk about people 
>> losing their jobs due to accessibility problems. Being a blind 
>> systems administrator is a constant struggle with accessibility 
>> problems. How do I install Windows 7? Is the new VMWare interface 
>> accessible? How do I rescue a crashed machine? I'm not saying someone 
>> would get fired right on the spot if their grml CD doesn't speak. But 
>> what happens is that tasks like installing Win7 and  rescuing crashed 
>> systems get assigned to other people. When layoffs come around, the 
>> blind systems administrator is the one to go because he is the least 
>> important member of the team.
>> I know grml can't be all things to all people. But I would hope the 
>> grml developers would be at least hesitant to add another brick to 
>> the wall of accessibility problems disabled systems administrators 
>> struggle to climb over every day.
>> ----- Original Message ----- From: "Michael Whapples" 
>> <mwhapples at aim.com>
>> To: <grml at mur.at>
>> Sent: Wednesday, November 02, 2011 7:00 PM
>> Subject: Re: [Grml] How are blind grml users handling 
>> currentwebtechnologies?
>>> John, I would agree with the list of what would be needed (personal 
>>> view). The only additional one I can imagine some might ask for 
>>> might be emacspeak, however possibly should that be included on a 
>>> live CD, I would probably go with not really as speakup can work 
>>> (may be not as well) with emacs or vim, so its not like you are 
>>> lacking access to a decent editor. Anyway, should emacspeak be 
>>> desired then it could be downloaded, or may be its something for a 
>>> custom GRML CD.
>>> Also, I don't know that I could commit to testing every release (as 
>>> I mentioned speakup in ArchLinux is not working on my computers and 
>>> I think its a speakup issue not a issue with the packaging) but may 
>>> be let us know here on this list as well when you want testing of 
>>> accessibility and I will do what I can.
>>> Michael Whapples
>>> On -10/01/37 20:59, John G. Heim wrote:
>>>> From: "Christian Hofstaedtler" <ch at grml.org>
>>>> To: <grml at ml.grml.org>
>>>>> Can you (or someone else interested in this) draft a list of things
>>>>> we would need to do/ship to actually have working accesibility 
>>>>> support
>>>> <> (for you)?
>>>>> This includes everything that might be there right now. I myself
>>>>> have never seen such a setup, so please be explicit.
>>>> I'd better ask around before I give you a definative list. I think 
>>>> I know what to tell you but I'll check  it out to make sure. I own 
>>>> a hardware speech synthesizer so I think for me, just including the 
>>>> speakup kernel modules would be enough.  And that code is now in 
>>>> the mainstream kernel code. You don't have to do anything but check 
>>>> the boxes for it when you're configuring a kernel.
>>>> On a debian system, to get software speech, you need the speakup 
>>>> modules and you need to install two packages, espeak and espeakup. 
>>>> To get braille, you need the brltty package.
>>>>> accessibility, I assume it's not really useful to actually have 
>>>>> the software on the ISO at all; so not having QA here is not 
>>>>> really an
>>>>> option.
>>>> I will do that.  All I'll need is to be notified when I need to 
>>>> test. I'm guessing that it wouldn't be a problem if it took me a 
>>>> few days to get to it. I mean, sometimes I take vacation.  But most 
>>>> of the time, if I was notified that I had to test a new version, I 
>>>> would get to it within 24 hours. And I'll be a good tester. I can 
>>>> use my employers resources to test so you'll never hear from me 
>>>> something like I couldn't get to it because my network connection 
>>>> was down. And I have a hardware speech synthesizer and a braille 
>>>> display. So I could test the full range of accessibility features.
>>>>> If somebody steps up to do the work and/or the list, we might 
>>>>> reconsider.
>>>> Well, you've already got somebody. I'm not the most knowledgable 
>>>> grml user in the world. I've used only the live CD as a rescue 
>>>> disk. But I have plenty of hardware that I can install grml on. I 
>>>> don't know if I'll need a machine with grml installed to the disk 
>>>> but I can set that up tonight. And I'll start asking around to make 
>>>> sure I know what to tell you to include.
>>> _______________________________________________
>>> Grml mailing list - Grml at ml.grml.org
>>> http://ml.grml.org/mailman/listinfo/grml
>>> join #grml on irc.freenode.org
>>> grml-devel-blog:

More information about the Grml mailing list