How are blind grml users handling current web technologies?
, everyone on the list. I am writing this to see how blind grml users are handling current web technologies such as flash and javascript.
I am wishing to change back to GRML which I haven't been able to use in years. The main reason is that the gui world is going to change and there have been problems with accessibility. This doesn't, of course happen with good old command line, of course, and I just wonder if some of the blind people using grml now can tell me about their work-aroundds for such problems as flash and javascript.
Is it possible to have mplayer be the viewer for all these streaming file formats and get it to work with w3m or edbrowse or whatever: Please let me know if there is something you are doing to handle current web technologies in command line mode and i will be glad to hear from you.
Sincerely:
Doug Smith
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
Doug Smith braillefingers@gmx.com wrote:
I am wishing to change back to GRML which I haven't been able to use in years. The main reason is that the gui world is going to change and there have been problems with accessibility. This doesn't, of course happen with good old command line, of course, and I just wonder if some of the blind people using grml now can tell me about their work-aroundds for such problems as flash and javascript.
I don't use GRML as my primary system - I use Debian instead, and just install Gnome, Orca and Iceweasel (Debian's version of Firefox).
You should be able to install these on a GRML system as well.
Soon, it may also be possible to use Chromium and to install ChromeVox with the Lois TTS extension (assuming that you want to use speech output).
The above solve the problem of making Javascript-intensive Web sites more accessible. Of course, it isn't quite so simple, since the Web sites themselves often have to implement accessibility on their side in order to interoperate with such client-side tools.
I also avoid Web sites that rely on Flash. This is relatively easy to do. I can't recall any Flash-based site that I have wanted to use ever, let alone one that I've had a really compelling reason to use.
Mplayer and its codec support should solve your streaming audio needs. HTML 5, with its video support, is displacing Flash for video applications, as demonstrated by what Google now offer on youtube.com.
Apart from running a Web browser, I currently have little reason to run an X environment, so I work primarily from the shell and from my favourite text applications, which are well supported by GRML.
I've been using Linux as my only operating system since the late 90s and I haven't yet been tempted to switch to anything else.
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
* Doug Smith [Wed Nov 02, 2011 at 03:35:49AM +0100]:
, everyone on the list. I am writing this to see how blind grml users are handling current web technologies such as flash and javascript.
[...]
A good moment to jump in for me, on behalf of the Grml team: I want to mention that the upcoming releases of Grml will no longer provide the accessibility features we used to ship so far.
Please let me explain:
The reason for dropping accessibility support within Grml is that we can't keep it up any longer. None of us Grml developers use any of those features on our own nor do we have people using it in our surroundings.
When problems with kernel modules, user space software and/or their integration within Grml show up we have to work in this area. But we're lacking manpower in the Grml team and the present manpower is needed in other areas to keep the project up and running.
Troughout the last ~8 years - since the beginnings of Grml - the feedback and help in this area was pretty limited overall, both by developers as well as users. The feedback when asking for testing of accessibility features in release candidates was close to zero.
In the meanwhile Debian itself became better and better with regards to accessibility, thanks to great efforts by people like Samuel Thibault and Mario Lang. AFAIK the debian-installer provides espeak support nowadays, orca seems to be well established, etc.
Since we don't want to get known for half baken solutions we'll be dropping the accessibility features from Grml starting with the upcoming stable release.
If you are interested in accessibility support within Debian and its derivatives we encourage you to check out the Debian-Accessibility project (see http://www.debian.org/devel/debian-accessibility/ for further details) and join their efforts.
regards, -mika- - on behalf of the Grml project
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
From: "Michael Prokop" mika@grml.org
Since we don't want to get known for half baken solutions we'll be dropping the accessibility features from Grml starting with the upcoming stable release.
I'm unclear as to what that means. I use grml all the time as a rescue disk but I always start the speech synth myself. Sometimes I use my hardware speech synthesizer and sometimes I use software speech. The speakup kernel modules and espeak have to be on the CD for that to work. You're not thinking of leaving that stuff off the CD, are you?
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
* John G. Heim jheim@math.wisc.edu [111102 16:53]:
From: "Michael Prokop" mika@grml.org
Since we don't want to get known for half baken solutions we'll be dropping the accessibility features from Grml starting with the upcoming stable release.
I'm unclear as to what that means. I use grml all the time as a rescue disk but I always start the speech synth myself. Sometimes I use my hardware speech synthesizer and sometimes I use software speech. The speakup kernel modules and espeak have to be on the CD for that to work. You're not thinking of leaving that stuff off the CD, are you?
speakup kernel modules and espeakup have already been removed in the daily builds; they will not make it into the next release.
-ch
-- Grml Live Linux
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
From: "Christian Hofstaedtler" ch@grml.org To: grml@ml.grml.org
speakup kernel modules and espeakup have already been removed in the daily builds; they will not make it into the next release.
Okay, now I'm unclear as to why this is. The original post said the grml developers don't want to do anything half baked. But including speakup & espeak isn't doing it half baked. That's just mainstream. You don't need to do anything fancy anymore to provide accessibility.
I mean, I can see dropping that script you used to supply that started software speech. I could never remember what to type so I always just started speech myself at the command line. Maybe the grml developers are under the impression that blind people don't use grml. I don't think that's true. In fact, there seems to be several of us blind people on this list. For every one of us, there are probably dozens or hundreds of others.
I think the grml developers should think hard about this decision. Dropping speakup isn't like dropping other features. If grml can't recognize someoby's old ethernet card, they're not going to lose their job. But if I can't use grml to rescue a server, I might lose my job.
_______________________________________________ Grml mailing list - Grml@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
* John G. Heim jheim@math.wisc.edu [111102 17:24]:
From: "Christian Hofstaedtler" ch@grml.org To: grml@ml.grml.org
speakup kernel modules and espeakup have already been removed in the daily builds; they will not make it into the next release.
Okay, now I'm unclear as to why this is. The original post said the grml developers don't want to do anything half baked. But including speakup & espeak isn't doing it half baked. That's just mainstream. You don't need to do anything fancy anymore to provide accessibility.
The speakup kernel modules are indeed not mainstream; we have to build them separately from the main kernel. We're currently looking to remove all external modules, if possible.
I mean, I can see dropping that script you used to supply that started software speech. I could never remember what to type so I always just started speech myself at the command line.
It also needs space on the ISOs. Every release the ISOs grow larger and we have to drop stuff. Besides that we also have to do testing and/or deal with bug reports, etc. If there's a problem in unstable with this software, we'd also have to deal with that (uninstallable or something).
Maybe the grml developers are under the impression that blind people don't use grml. I don't think that's true. In fact, there seems to be several of us blind people on this list. For every one of us, there are probably dozens or hundreds of others.
We don't think nobody uses this. On the other hand we clearly see that none of the developers has personal use for accessibility, and we do not receive contributions (development and QA) from this user group.
-ch
* Christian Hofstaedtler ch@grml.org [111102 18:23]:
- John G. Heim jheim@math.wisc.edu [111102 17:24]:
From: "Christian Hofstaedtler" ch@grml.org To: grml@ml.grml.org
speakup kernel modules and espeakup have already been removed in the daily builds; they will not make it into the next release.
Okay, now I'm unclear as to why this is. The original post said the grml developers don't want to do anything half baked. But including speakup & espeak isn't doing it half baked. That's just mainstream. You don't need to do anything fancy anymore to provide accessibility.
The speakup kernel modules are indeed not mainstream; we have to build them separately from the main kernel. We're currently looking to remove all external modules, if possible.
So I stand corrected on these, since our 2011.05 release the modules are actually included in vanilla. (Thanks to U.D. for pointing this out.)
-ch
From: "Christian Hofstaedtler" ch@grml.org To: grml@ml.grml.org
We don't think nobody uses this. On the other hand we clearly see that none of the developers has personal use for accessibility, and we do not receive contributions (development and QA) from this user group.
I agree with what M.W. said that its been working so well there has been no reason to comment on it. I've been on this list for years and other than to ask some questions about re-mastering, I haven't commented at all.
But I'm guessing that the fact that the speakup code is now in the vanilla kernel source changes things, right? You don't have to pull it from git any more. All you have to do is check the boxes for the speakup modules when compiling your kernel. It'll take up some space but given the importance of these modules to some people, I'd think you'd want to do that.
Christian, are you in a position to make a policy decision on this issue? I think you should consider including brltty, espeak, and espeakup on the disk for reasons I talked about at length in another message. But my opinion is that including the speakup modules should be a sure thing. I'd be very disappointed if you decide against that at least.
* John G. Heim jheim@math.wisc.edu [111102 17:24]:
From: "Christian Hofstaedtler" ch@grml.org To: grml@ml.grml.org
speakup kernel modules and espeakup have already been removed in the daily builds; they will not make it into the next release.
Okay, now I'm unclear as to why this is. The original post said the grml developers don't want to do anything half baked. But including speakup & espeak isn't doing it half baked. That's just mainstream. You don't need to do anything fancy anymore to provide accessibility.
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.
We'd also need someone testing this stuff regularly, especially before a release goes out. If we were to (accidentally) break 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.
If somebody steps up to do the work and/or the list, we might reconsider.
-ch
From: "Christian Hofstaedtler" ch@grml.org To: grml@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.
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@grml.org To: grml@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.
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@aim.com To: grml@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@grml.org To: grml@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@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
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:
- Speakup kernel modules
- Braille support (brltty)
- Software speech (espeak and espeakup)
- 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@aim.com To: grml@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@grml.org To: grml@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@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
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@aim.com To: "John G. Heim" jheim@math.wisc.edu Cc: grml@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:
- Speakup kernel modules
- Braille support (brltty)
- Software speech (espeak and espeakup)
- 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@aim.com To: grml@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@grml.org To: grml@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@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
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@aim.com To: "John G. Heim" jheim@math.wisc.edu Cc: grml@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:
- Speakup kernel modules
- Braille support (brltty)
- Software speech (espeak and espeakup)
- 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@aim.com To: grml@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@grml.org To: grml@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@ml.grml.org http://ml.grml.org/mailman/listinfo/grml join #grml on irc.freenode.org grml-devel-blog:
* John G. Heim jheim@math.wisc.edu [111102 22:50]:
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.
There's now a testbuild of GRML_MEDIUM (64-bits) with espeakup, espeak and brltty at this URL: http://jenkins.grml.org/job/grml-medium-amd64/lastSuccessfulBuild/artifact/2...
Please test it; let us know if it works, if it doesn't, if it's missing something, etc.
Note that this build has some ALSA/Sound support, which is something that might get removed, too. Don't know if this would have any impact on you.
-ch
Hello, This is sad news. Generally I have found things with accessibility in GRML just working and have had little to really report. Normally any issues have been upsteam issues (eg. this speakup one I think is an upstream one). Also may be GRML has a strange place with me, I don't use it that frequently as I mainly use it for system rescue, may be my current installation of ArchLinux is just too stable...
Now addressing some specific points raised in this thread.
* Including non-standard things. What is the situation of speakup as I understand it speakup is now part of the standard kernel sources. Will speakup still be included even if other things go? * Work needed to include it. OK, I think I agree that the scripts, while nice may be not really needed and I could live without them. May be if removing them may be just some sort of beep or sound when the system finishes booting may help us. Also certainly in the case of BRLTTY, I don't think I've ever had an issue where it doesn't work fine, it always seems to work on about whatever distribution I try. Aren't the brltty package in GRML just the standard debian ones, so the only work is to include that package. * The space issue. This is possibly the hardest, its hard always to decide what should go. May those of us who use accessibility could decide what really is not needed and so help free some space. As an example, when using speakup I probably would only use espeakup, therefore speech-dispatcher need not be on the CD. Probably if pushed to it, brltty may be could go, however I really would need to be pushed to it as I find it useful should the sound card fail to be unmuted. I would though in such a pushed situation say brltty over speakup as probably more people would use speakup (particularly with espeak) than would own a Braille display and so use brltty. Also I certainly would not mind seeing the helper scripts for accessibility go, although I doubt that would free much space.
An alternative to the last one for freeing space, would it be possible for there to be a GRML_accessible? May be this option does not sound great as it might be adding to the work, however here are some of my thoughts. As certainly in the past GRML has included X, well unless orca is included and a desktop based on GTK (eg. XFCE or LXDE) then X is useless to blind users. May be there could be a configuration for building a LiveCD without X but with accessibility. To save on the work, this CD would receive little attention from developers (building it would simply be the main task) and only testing would be from users (IE. users must report issues for them to be looked at).
Anyone have thoughts on this?
Michael Whapples On -10/01/37 20:59, Michael Prokop wrote:
- Doug Smith [Wed Nov 02, 2011 at 03:35:49AM +0100]:
, everyone on the list. I am writing this to see how blind grml users are handling current web technologies such as flash and javascript.
[...]
A good moment to jump in for me, on behalf of the Grml team: I want to mention that the upcoming releases of Grml will no longer provide the accessibility features we used to ship so far.
Please let me explain:
The reason for dropping accessibility support within Grml is that we can't keep it up any longer. None of us Grml developers use any of those features on our own nor do we have people using it in our surroundings.
When problems with kernel modules, user space software and/or their integration within Grml show up we have to work in this area. But we're lacking manpower in the Grml team and the present manpower is needed in other areas to keep the project up and running.
Troughout the last ~8 years - since the beginnings of Grml - the feedback and help in this area was pretty limited overall, both by developers as well as users. The feedback when asking for testing of accessibility features in release candidates was close to zero.
In the meanwhile Debian itself became better and better with regards to accessibility, thanks to great efforts by people like Samuel Thibault and Mario Lang. AFAIK the debian-installer provides espeak support nowadays, orca seems to be well established, etc.
Since we don't want to get known for half baken solutions we'll be dropping the accessibility features from Grml starting with the upcoming stable release.
If you are interested in accessibility support within Debian and its derivatives we encourage you to check out the Debian-Accessibility project (see http://www.debian.org/devel/debian-accessibility/ for further details) and join their efforts.
regards, -mika- - on behalf of the Grml project
On Wed, Nov 2, 2011 at 22:31, Michael Whapples mwhapples@aim.com wrote:
May be if removing them may be just some sort of beep or sound when the system finishes booting may help us.
I have normal eyesight, but I would love to have a short beep sequence once booting has finished. By default, that is.
Richard
The one question is, would it be most useful either using the standard PC speaker or the sound card? I imagine the PC speaker might be better for some but would it make it more complicated on some systems where the PC speaker is channelled through the sound card and so needs the PC speaker line unmuting as well (eg. I think many laptops may do this).
Michael whapples On 2 Nov 2011, at 21:59, Richard Hartmann wrote:
On Wed, Nov 2, 2011 at 22:31, Michael Whapples mwhapples@aim.com wrote:
May be if removing them may be just some sort of beep or sound when the system finishes booting may help us.
I have normal eyesight, but I would love to have a short beep sequence once booting has finished. By default, that is.
Richard
Hello, Firstly my main use of Linux on an installed system is using ArchLinux, I tend to use GRML only as a LiveCD (eg as a rescue CD).
For an installed system I normally browse the internet in firefox in gnome. This probably is the best way for getting a browser which will work with most websites. Also while flash content is inaccessible to orca (flash content is inaccessible on everything bu windows), flashplayer in firefox will play videos/audio where it is set to automatically start playing. I know there have been issues with gnome 3 accessibility, however running from it possibly won't help matters, the bugs need to be tracked down somehow.
OK, I accept there are times when you possibly want to just get things done, so that is normally where I turn to the Mac (I am having issues with speakup working on my computers so the command line isn't a great option for me in Linux).
For general browsing in the command line I would use lynx, however if javascript support is needed then links2 or elinks is another option (I am not sure whether edbrowse supports javascript, I think it might). As for flash support, I don't think there is any simple, ready set up solution, however may be some of the follow may help with some flash needs. The are clients to many popular services where you do not need to use a web browser. An example would be, there are some scripts for accessing BBC iplayer content from the command line where it can download the program onto your system in a more standard format you can play with something like mplayer (or if using gnome totem), for example audio from radio programs I think can be saved as m4a files. There is also a client for youtube. There may be other clients for other services, but these are the ones I have paid any attention to.
I hope some of this helps you.
Michael Whapples On -10/01/37 20:59, Doug Smith wrote:
, everyone on the list. I am writing this to see how blind grml users are handling current web technologies such as flash and javascript.
I am wishing to change back to GRML which I haven't been able to use in years. The main reason is that the gui world is going to change and there have been problems with accessibility. This doesn't, of course happen with good old command line, of course, and I just wonder if some of the blind people using grml now can tell me about their work-aroundds for such problems as flash and javascript.
Is it possible to have mplayer be the viewer for all these streaming file formats and get it to work with w3m or edbrowse or whatever: Please let me know if there is something you are doing to handle current web technologies in command line mode and i will be glad to hear from you.
Sincerely:
Doug Smith
Teilnehmer (7)
-
Christian Hofstaedtler -
Doug Smith -
Jason White -
John G. Heim -
Michael Prokop -
Michael Whapples -
Richard Hartmann