Re: Lynx is a form of accessibility (was Re: Lynx is not Accessibility)
I use many different operating systems, as a person who is blind. I don't usually use textual web browsers, because they usually don't have the amazing amount of commands that a screen reader, like NVDA on Windows, or Orca on Linux, provides. In visual browsers like Firefox, using screen readers, I can jump directly to an HTML item type, like headings at various levels, forms, links, lists, editable text fields, radio buttons and checkboxes, landmarks, and so on. I can do a bit of that in Emacs' browser with Emacspeak, but really the only time I use that is when I'm reading something that I'm going to be using while inside Emacs, like documentation or something, since it doesn't have JavaScript support. While text *is* usually accessible, it's not always the easiest to use. Take email for example. Having quoted material at the top of the message means that I (using the Gmail web app), must arrow through possibly many levels of quoted material to get to the reply, and since I may have just heard the material that is now quoted just moments before, it's not all that useful right now as I reread it. However, I'm not going to ask that this way of producing email be changed; although if bottom-posting is the rule of this list, do let me know so I can leave it. Really, the point of all this is that structure is good for accessibility, but screen readers and browsers must know about it, and be able to use it to allow blind users to move past possibly irrelevant material, or move to relevant stuff. Devin Prater r.d.t.pra...@gmail.com On Mon, Mar 7, 2022 at 5:31 PM Thorsten Glaser wrote: > Sam Hartman dixit: > > >Thorsten> Alternative solutions may • have accessibility problems > >Thorsten> (not work with lynx, for example > > > >Working with Lynx is not a requirement for accessibility. > > No, but not working with lynx is an accessibility problem. > > >Obviously accessibility depends on what your requirements are. > > Exactly. > > >The needs of someone who is blind are different than than for someone > >who has mobility issues for example. > > Right. > > I occasionally help out a couple of blind users on the lynx mailing > list. Some of them are on DOS systems and shell out to Unix systems > to access lynx, even. > > But that’s not the only use case. Slow connections, text only, > or even font sizes (lynx runs in a terminal where *I* choose > that), are other use cases. > > Also, JavaScript thingies tend to be over-designed. There was > this firewall solution I encountered at work where you had to > drag-and-drop things to create and order firewall rules. > > The current solution is to just enter a couple of numbers, > sign and send, which is just perfect for many use cases. > > Can we at least agree that there are multiple use cases and there > is not a single solution covering all of them out of the box? > > IIRC you mention something about writing a frontend to help craft > the mails that are sent to the voting system. I agree that having > the need for that, in such a technology-oriented community that > Debian is, while surprising to me, shows that eMail only has its > problems. > > But I want to assert that removing the current, working, method > cannot be a/the solution for that problem either. > > >I stopped using Lynx many many years ago. Originally it was because > >some sites just weren't usable in Lynx and I wanted to use them. > > Yeah. I use lynx daily and do encounter this problem. I have an > ever-changing mix of browsers to fall back to, but the developers > of Firefox seem to want to make my life just so much harder (ever > since the update from 78 to 91 it’s so slow it’s barely usable on > a Core2Duo laptop), and I really hate the bad mouse-oriented > usability of it. Also, lynx at least has black background in my > terminal… > > >These days though, modern browsers actually have better > >technology for navigating a web page accessibly than Lynx does. > > Again, depends on your use case. In my case, the font and colour > selection being user-controlled, the blazing-fast rendering (also > on page down, search, etc.), links and form fields are numbered, > textfields need activation, and the space and b keys for scrolling > is massively superiour to any graphical browser (even though links2 > comes somewhat close… I like it as manga viewer, but it has issues > elsewhere). > > >is not directly an accessibility issue. In some cases it is because > > I’d argue having to rely on proprietary JavaScript drawing things > is both an accessibility and a worse issue (GNU LibreJS seems to > not have gone anywhere, plus, with it enabled you’d have just the > same site breakage as in
To all candidates: Debian and people with disabilities
Good day, I'd like to ask a few questions of all candidates for Debian leadership. As a person who is blind, these are of significant importance to me. I hope that, in asking these questions and maybe sparking a discussion on these topics, attention can be focused on Debian's role in the lives of people with disabilities, and the companies and organizations that use it. * Have you heard of the Debian Accessibility group? * If so, have you worked with them in the past, or are you currently working with them? * Currently, Debian backports is how people with disabilities can get the most up-to-date accessibility fixes and improvements while remaining on a stable base system. For example, the newest version of the Orca screen reader, with all of its fixes, and newest version of ATSPI, the thing that makes Orca able to talk to applications. Would you be willing to entertain the idea of moving those updates directly to Debian stable? * How would you present Debian to a group of people with disabilities? What reasons would you give them for why they should consider Debian? * In many desktop environments, a user cannot use their assistive technologies effectively unless they find and check a box enabling the use of assistive technologies. Do you think that this is good and fair to users? Thanks so much for the answers. Devin Prater r.d.t.pra...@gmail.com
Re: To all candidates: Debian and people with disabilities
Thanks. I tried to think of good, useful questions to spark discussion, but I don't know much about the structure of Debian or its project leaders. I do think, though, that if the project leader keeps accessibility in mind, this will filter down throughout Debian as a whole. As far as backports, my problem is enabling it. Normal desktop users probably won't even know what that is, and the syntax is rather ugly, to me at least. I'd personally like to see accessibility on the same level as security or very important bug fix updates, because sometimes they are, especially when something like the Terminal bug happened with Orca, where Orca couldn't read the Mate Terminal. Another thing is braille support. BRLTTY, the package for driving Braille displays, gets updated like once every three months or so with support for new Braille displays. This isn't to say that Debian's accessibility is awful; it's one of the best among all Linux distributions, because the user is guided from installation to first system boot. It's nice. I know the project leader can't be everything to all people, and there are legal, security, and other community issues, but it would be nice if whoever is elected to remember us, and setting aside a day to work on accessibility issues would be an amazing start. And since Debian is the root of a lot of other distributions, and even the default container in Google's Crostini Linux thing, we can show both other FOSS projects, and big corporations (corpses) that FOSS doesn't have to only be for people who are privileged enough to have all senses and use of their bodies and minds. Devin Prater r.d.t.pra...@gmail.com On Mon, Mar 21, 2022 at 5:46 PM Samuel Thibault wrote: > Hello, > > Devin, thanks for bringing accessibility questions in :) > > Jean-Philippe MENGUAL, le lun. 21 mars 2022 23:37:03 +0100, a ecrit: > > Again, not sur the DPL can have a crucial role about this, > > unfortunately. > > I agree, a DPL cannot make current maintainers magically find time to > work on issues :) > > > Perhaps, however, in order to give more visibility to the topic, he > > may ping them more frequently during his public statements (Debconf, > > bits, debian-news) so make them talk about their work progress. > > Agreed as well: advertising the will of Debian to progress on this > front, and that help is welcome, *can* make new maintainers come up. > > Samuel > >
Re: To all candidates: Debian and people with disabilities
So, the Terminal issue was fixed some time ago, so we don't have to worry about that. That was just an example of a bug which *has* happened before. I'm sorry I wasn't clear enough. Devin Prater r.d.t.pra...@gmail.com On Tue, Mar 22, 2022 at 5:52 AM Jean-Philippe MENGUAL wrote: > > Le 22/03/2022 à 04:10, Devin Prater a écrit : > > Thanks. I tried to think of good, useful questions to spark discussion, > > but I don't know much about the structure of Debian or its project > > leaders. I do think, though, that if the project leader keeps > > accessibility in mind, this will filter down throughout Debian as a > whole. > > You are right, and thanks to give visibility fot this matter here. > > > > > As far as backports, my problem is enabling it. Normal desktop users > > probably won't even know what that is, and the syntax is rather ugly, to > > me at least. I'd personally like to see accessibility on the same level > > as security or very important bug fix updates, because sometimes they > > are, especially when something like the Terminal bug happened with Orca, > > where Orca couldn't read the Mate Terminal. Another thing is braille > > support. BRLTTY, the package for driving Braille displays, gets updated > > like once every three months or so with support for new Braille displays. > > What you describe are issues mainly related to upstream development. The > fact Orca has problems in a terminal (I think I know this) should be > reported and discussedon the orcamailing list, as it is the place where > the development happens. Debian is only a distribution, ie. a place to > make easier getting packages usable. But a distro should not patch so > much a program, in particular it cannot bring new features or fix bugs. > Some maintainers do, but often because they maintain the package and the > program upstream. It is not the case for graphical accessibility tools, > where maintainers in Debian (thanks Samuel, Paul and few others) are > often different from the upstream developers. Tools such as > speech-dispatcher are maintained by accessibility team upstream and in > Debian, for instance. > > So the best thing you can do to report such problems is writing to the > orca mailing list so that they are in the todo list of the developer. > And indeed, Orca in a terminal is not optimum. > > For braille, the thing is to know if a new version of brltty supports a > display you have and which is not yet supported in stable. Ti is a kind > of program where upgrades are not required as few new features appear, > except sometimes (cut and paste recently introduced in graphical > interface). So if it adds a driver for your device, indeed, a backport > is a good idea. > > > > > > This isn't to say that Debian's accessibility is awful; it's one of the > > best among all Linux distributions, because the user is guided from > > installation to first system boot. It's nice. I know the project leader > > can't be everything to all people, and there are legal, security, and > > other community issues, but it would be nice if whoever is elected to > > remember us, and setting aside a day to work on accessibility issues > > would be an amazing start. And since Debian is the root of a lot of > > other distributions, and even the default container in Google's Crostini > > Linux thing, we can show both other FOSS projects, and big > > corporations (corpses) that FOSS doesn't have to only be for people who > > are privileged enough to have all senses and use of their bodies and > minds. > > +1 > > > Devin Prater > > r.d.t.pra...@gmail.com <mailto:r.d.t.pra...@gmail.com> > > > > > > > > > > On Mon, Mar 21, 2022 at 5:46 PM Samuel Thibault > <mailto:sthiba...@debian.org>> wrote: > > > > Hello, > > > > Devin, thanks for bringing accessibility questions in :) > > > > Jean-Philippe MENGUAL, le lun. 21 mars 2022 23:37:03 +0100, a ecrit: > > > Again, not sur the DPL can have a crucial role about this, > > > unfortunately. > > > > I agree, a DPL cannot make current maintainers magically find time to > > work on issues :) > > > > > Perhaps, however, in order to give more visibility to the topic, > he > > > may ping them more frequently during his public statements > (Debconf, > > > bits, debian-news) so make them talk about their work progress. > > > > Agreed as well: advertising the will of Debian to progress on this > > front, and that help is welcome, *can* make new maintainers come up. > > > > Samuel > > > >
Re: To all candidates: Debian and people with disabilities
Yeah, right now there is a device being tested, the NLS EReader. This is a braille display that the National Library Service for the Blind in the US is having companies develop so that they can then distribute them, for free, to their patrons. Two versions are being tested, one from the Humanware manufacturer, and another from Zoomax. The one from Zoomax works currently, in at least BRLTTY 6.4, and work is being done to complete support for the Humanware model. So I'm glad device support can be added in stable like that. I only have access to the Humanware model, and some devices, like Android phones, don't support it, while others, like iOS systems, have... unfinished support for it. Devin Prater r.d.t.pra...@gmail.com On Tue, Mar 22, 2022 at 6:34 AM Samuel Thibault wrote: > Jean-Philippe MENGUAL, le mar. 22 mars 2022 11:51:43 +0100, a ecrit: > > If it adds a driver for your device, indeed, a backport is a good > > idea. > > Note that sometimes supporting a new device does not actually require > a completely new driver, only a small addition to recognize the USB > device. That can be added in stable updates without problem. > > Samuel > >
Re: To all candidates: Debian and people with disabilities
That's good to hear. We use Element at work, so I can tell the boss that Jitsi is good to use now. Unfortunately, Element has started making their own video call stuff because it's just never enough to have a good FOSS solution, one must make their own to have it perfect!. Funnily enough, Zoom is pretty awful to use on Linux as a desktop app. The web app works a bit better, so I'm glad Jitsi outshines them in accessibility now. Devin Prater r.d.t.pra...@gmail.com On Tue, Mar 22, 2022 at 11:05 PM Sam Hartman wrote: > >>>>> "Jonathan" == Jonathan Carter writes: > Jonathan> I installed a Jitsi server for Debian (it's a system for > Jonathan> making group video calls), and was really proud that we > Jonathan> had this... until we had some blind people join some calls > Jonathan> and learned how utterly inaccessible it is. For example, > Jonathan> you can toggle your mic or camera (there's no way to set > Jonathan> it as either on or off explicitly) and then you have to be > Jonathan> able to see the mic or camera icon on your screen in order > Jonathan> to tell whether those are enabled or not. > > This has gotten much much better. > > * You can hold down space bar in orca focus mode, when you release, you > know you will be muted. > (push to talk key) > > * The accessibility of the icons is much better. > The buttons are "pressed" when muted and this displays through to orca. > > There are still a few things that are not perfect, but Jitsi > accessibility is on par with Zoom and Teams from my standpoint these > days. > >
Re: To all candidates: Debian and people with disabilities
Gas is rather expensive these days. :D How would you propose we improve the emotional response? I've written plenty of blog posts on write.as/devinprater (some on other operating systems but a good bit about Linux). I'm not very good at making videos, but I can write and edit. Devin Prater r.d.t.pra...@gmail.com On Fri, Apr 1, 2022 at 1:24 AM Hideki Yamane wrote: > Hi, > > On Mon, 21 Mar 2022 23:37:03 +0100 > Jean-Philippe MENGUAL wrote: > > I dont think DPL can influence this, indeed. > > DPL can influence it, IMHO. But, of course cannot force it. > Just point "the direction" and show the idea behind it and discuss - > that's what I want to do. > > > > Difficult question indeed. Most information are on > > wiki.debian.org/accessibility. > > "Pulling" the information is a bit hard these days since there are > a lot of info and not well constructed. And there is no "feelings" > with current situations. Improving accessibility is a good thing, > but push people to do so, we need some emotional "gas" to heat our > heart. So, it is important that "pushing" information about current > situation of accessibility in Debian and what you want to do with > it is necessary, IMO. > > > -- > Hideki Yamane >
Re: Changing how we handle non-free firmware
Seconded, thanks for mentioning the accessibility aspect! Devin Prater r.d.t.pra...@gmail.com On Thu, Aug 18, 2022 at 2:59 PM Steve McIntyre <93...@debian.org> wrote: > Hi a11! > > I'm proposing to change how we handle non-free firmware in > Debian. I've written about this a few times already this year [1, 2] > and I ran a session on the subject at DebConf [3]. > > TL;DR: The way we deal with (non-free) firmware in Debian isn't > great. For a long time we've got away without supporting and including > (non-free) firmware on Debian systems. We don't *want* to have to > provide (non-free) firmware to our users, and in an ideal world we > wouldn't need to. However, it's no longer a sensible path when trying > to support lots of common current hardware. Increasingly, modern > computers don't function fully without these firmware blobs. > > Since I started talking about this, Ansgar has already added dak > support for a new, separate non-free-firmware component - see > [4]. This makes part of my original proposal moot! More work is needed > yet to make use of this support, but it's started! :-) > > I believe that there is reasonably wide support for changing what we > do with non-free firmware. I see several possible paths forward, but > as I've stated previously I don't want to be making the decision > alone. I believe that the Debian project as a whole needs to make the > decision on which path is the correct one. > > I'm *not* going to propose full text for all the possible choices > here; as eloquently suggested by Russ [5], it's probably better to > leave it for other people to come up with the text of options that > they feel should also be on the ballot. > > So, I propose the following: > > = > > We will include non-free firmware packages from the > "non-free-firmware" section of the Debian archive on our official > media (installer images and live images). The included firmware > binaries will *normally* be enabled by default where the system > determines that they are required, but where possible we will include > ways for users to disable this at boot (boot menu option, kernel > command line etc.). > > When the installer/live system is running we will provide information > to the user about what firmware has been loaded (both free and > non-free), and we will also store that information on the target > system such that users will be able to find it later. The target > system will *also* be configured to use the non-free-firmware > component by default in the apt sources.list file. Our users should > receive security updates and important fixes to firmware binaries just > like any other installed software. > > We will publish these images as official Debian media, replacing the > current media sets that do not include non-free firmware packages. > > = > > A reason for defaulting to installing non-free firmware *by default* > is accessibility. A blind user running the installer in text-to-speech > mode may need audio firmware loaded to be able to drive the installer > at all. It's going to be very difficult for them to change this. Other > people should be able to drive the system (boot menus, etc.) to *not* > install the non-free firmware packages if desired. > > We will *only* include the non-free-firmware component on our media > and on installed systems by default. As a general policy, we still do > not want to see other non-free software in use. Users may still enable > the existing non-free component if they need it. > > We also need to do the work to make this happen: > > * in d-i, live-boot and elsewhere to make information about firmware >available. > > * add support for the non-free-firmware section in more places: >ftpsync, debian-cd and more. > > and I plan to start on some of those soon. > > [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do > [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html > [3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/ > [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable > [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html > > -- > Steve McIntyre, Cambridge, UK. > st...@einval.com > You raise the blade, you make the change... You re-arrange me 'til I'm > sane... >
