Re: [BRLTTY] Graphical BRLTTY running but not used in terminals
Samuel Thibault (2024/03/26 13:45 +0100): > Sébastien Hinderer, le mar. 26 mars 2024 13:40:48 +0100, a ecrit: > > I think what mislead me is that, although the braille rendering isdone > > by BRLTTY, there continues to be a speech rendering which, I think, _is_ > > done by Orca. > > That's entirely possible, since Orca doesn't even know that brltty is > reading it. You probably want to set a per-app preference to disable > speech in terminal. I confirm this works! Thanks! Seb.
Re: [BRLTTY] Graphical BRLTTY running but not used in terminals
Hey Samuel, Samuel Thibault (2024/03/26 13:34 +0100): > AFAIK, the latest released versions of orca and brltty handle it > correctly: usually Orca uses the default priority (50), except in flat > review mode, in which case it uses a higher priority (70). On the brltty > side, the a2 screen reader reports SCQ_GOOD for the terminal case, which > translates to default+10, so 60, so it'd be higher than what orca > sets. Plenty of thanks for your feedback. I don't think I'm using flat review mode. I have ocra 46.0-1 installed, and brltty 6.6-5. It shouldn't matter but xbrlapi 6.6-5 is installed, too. I am noticing now that my assumption that the terminal was dealt by Orca was kind of wrong. Indeed, BRLTTY's copy/paste does work so it must definitely be BRLTTY which is rendering the terminal's content. I think what mislead me is that, although the braille rendering isdone by BRLTTY, there continues to be a speech rendering which, I think, _is_ done by Orca. Os it's as if the terminal is rendered by both brltty (for the braille part) and Orca (for the speech part). I am wondering whether this is a desirablebehaviour, actually. Seb.
Graphical BRLTTY running but not used in terminals
Dear all, I think my graphical Mate terminals are rendered by Orca, whereas I do see a graphical BRLTTY process, run with the command /bin/brltty -b ba -s no -x a2 -N I assume there is a priroity issue between two BrlAPI clients. HAs anybody already encountered this problem? Is there a known fix? Thanks! Seb.
Re: Accessible terminal output
Niels Thykier (2024/01/29 14:50 +0100): > Christian Schoepplein: > > Hi Nils, > > > > [...] > > > > Piping output into a pager is very uncomfortable for screen reader users > > IMHO. [...] I'd like to say I do not have the same feeling on that one. Seb.
Re: Accessible terminal output
john doe (2024/01/28 21:33 +0100): > Generaly speaking, what is machine readable is screenreader friendly > (JSON/YAML). > To me, it's more importent to have an extensive documentation explaning > what a text file output contains than spending time on getting the > "correct" output. I'd say it also depends on the kind of output. For example, I am very happy with the currentoutput of `git status` and I am not sure I wouldwant it to be in any structured format like JSON or YAML. Not to say these formats are a bad idea in general, but rather that they may not always be the best choice. Seb.
Re: Accessible terminal output
Just to add one thing: Sébastien Hinderer (2024/01/28 12:10 +0100): > At the very least, if you want to embelish your output, it would be nice > if there is a mode where this embelishment can be disabled, either > through a command-line option, an environemnt variable or a directive in > a configuration file. Basically have at least one output that would be > easy to parse by a script. Here my «parse by a script» also includes easy to filter with tools like grep or other classical information extracting tools. Seb.
Re: Accessible terminal output
Niels Thykier (2024/01/28 11:54 +0100): > Thanks, I get what you mean now. :) > > In my case, my tool is not interactive. It generates text output and either > emits all of it on standard out or pipes it to a pager. It is closer to a > tool like ls than mutt in spirit. As far as I know, my tool cannot control > the caret of the output in any meaningful way in this case. Indeed the caret thing feels irrelevant then. One suggestion, though, is to avoid as much as possible the embellishing characters and any unnecessary Unicode fanciness because that will likely make the output of the tool harder to read on a braille display; At the very least, if you want to embelish your output, it would be nice if there is a mode where this embelishment can be disabled, either through a command-line option, an environemnt variable or a directive in a configuration file. Basically have at least one output that would be easy to parse by a script. Seb.
Re: Accessible terminal output
Hi, To (try to) complete what Samuel has written... Niels Thykier (2024/01/27 23:10 +0100): > > One thing that is important for the screen reader to know what to render > > is to put the caret on the item that matters. > > I have trouble with this one. Can you provide an example that would work in > the terminal or a command that does this well? The shell, for one. Whenyou type, the caret is where you are editting. I admit it's trivial. For a less trivial one take the mutt email client which can exhibit boththe "wrong" andthe "right" behaviours depending on whether the "braille_friendly" variable is unset (wrong behaviour) or set (right behaviour). In the index (list ofemails), if braille_friendlyis not set, the currentlyselected mail will be shown eithr withattributes, or with a "->"marker on thecorrespondinglinewhereas the caret will remain at the bottom right of the screen. If braille_friendlyis set, on thecountrary, the caret will always be on the selectedemail, i.e. the one that would be displayed in thepager if you press enter, theone towhich you'd respond by pressing r, etc. > > The only two examples I can come up with are either using accented > characters like combining ^ and a into â, which visually looks like putting > a "caret on the item" or underling a word with ^ symbol, which is how modern > c-compiler high lights the part of the code that is causing issue. Ah, ifyou want to highlight this kindof thextthen I'd suggest to rather surround it by markers, rather than underline it because that willbe easier to detect for braille readers wich have a hard time to figure out vertical alignments. > However, > I suspect both of these are visualizations and therefore not useful in > practice. Furthermore, my web searches does not seem to find the phrase. I > end up in HTML guides or caret browsering. None of which seem to apply to > terminal command output. It's true that the underlining is not that easy but still not completely unusableeither. Hth and thanks a lot for caring, Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hi, Christian Schoepplein (2023/09/12 13:30 +0200): > I do have the problem not only with translate, this was just an example > command to show the issue. I have the same problems with apt and other > commands too, so the issue IMHO is not related to translate only. Yes that's what I was trying to say. I was suggesting that the issue may have to do with the difference in diwth between your terminal and Samuel's one. Seb.
Re: [orca] Re: (solved) orca's strange behavior in a crowded terminal
Hello, May it be the case that translate adjusts its output to the size of the terminal? That may enxplain the difference observed in behaviours between Samuel and Christian. Seb.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/07 20:10 +0200): > The fixed packages are in Debian stable and testing, could people make > sure to upgrade and test before I upload the fixes to bookworm? Can't say thanks enough for your hard and prompt work. Just upgraded, everything seems to work normally. Thanks again, Seb. > > Samuel >
Re: orca_45~alpha-1_source.changes ACCEPTED into experimental
Edward Little (2023/09/06 17:01 -0400): > Please remove this email address from your list. Thanks. You can do that by yourself. Send an email to: debian-accessibility-requ...@lists.debian.org Wit the owrd unsubscribe as the subjecto fo your email and that wshould be it. Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 22:42 +0200): > Sébastien Hinderer, le lun. 04 sept. 2023 22:27:57 +0200, a ecrit: > > Upgrade: xbrlapi:amd64 (6.5-7, 6.6-2), > > That makes a huge difference, that's why I was asking for versions. In > versions before 6.6-1, the xbrlapi package was trying to start brltty > with a ba driver and an a2 driver, only to fail loading the a2 driver. > So possibly the presence of brltty with only the ba driver loaded is > eating keypresses, and the addition of a2 brings things back in order, > for whatever reason. So what shall we do from here? Seb.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 22:12 +0200): > I don't mean it's not implemented. I mean in the tests one can make, > Orca doesn't happen to be doing anything with them. For *whatever* > reason that might lie between the actual braille device and Orca. Yes yes, I'm following you now. > > Unless there is a regression that happened in Orca and has somehow > > been masked? > > Or in whatever is between the device and Orca. > > > Even theprecedence mechanism is not that old, probably newer than a2 > > and thus even if a2 is there for a long time it's not such a long time > > it cantake precedence over Orca when there are widgets they both know > > how to render, right? > > Without actually taking the time to actually *inspect* what is > happening, I'll just stop making any more guesses, it's a loss of time > from all of us. Yes yes, sorry, wie will stop guessing. Apologies, I was just thinking out loud because it was the easiestthing to do. > > > But again, which version of brltty are you using? > > > > 6.6-2 > > So when brltty-x11 is not installed, you do not have a second brltty > running, right? Right. Only one brltty running. But, my observations differ from those reported by Roberto. On my system, things continue to work even once brltty-x11 has been purged and the system has been restarted. Hoping it helps, here is the relevant bit of /var/log/apt/history.log: Start-Date: 2023-09-04 13:31:57 Commandline: apt install orca Upgrade: orca:amd64 (43.1-1, 44.1-2) End-Date: 2023-09-04 13:32:00 Start-Date: 2023-09-04 14:23:50 Commandline: apt install brltty-x11 Install: brltty-x11:amd64 (6.6-2) Upgrade: python3-brlapi:amd64 (6.5-7, 6.6-2), xbrlapi:amd64 (6.5-7, 6.6-2), libbrlapi0.8:amd64 (6.5-7, 6.6-2), brltty:amd64 (6.5-7, 6.6-2) End-Date: 2023-09-04 14:24:08 Start-Date: 2023-09-04 22:18:36 Commandline: apt purge brltty-x11 Purge: brltty-x11:amd64 (6.6-2) End-Date: 2023-09-04 22:18:37 Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 21:28 +0200): > Sébastien Hinderer, le lun. 04 sept. 2023 21:16:47 +0200, a ecrit: > > Samuel Thibault (2023/09/04 21:01 +0200): > > > So the behavior you expect is not actually implemented by Orca, it's the > > > a2 screen driver that takes precedence in the text fields > > > > Well I am unsure about what you mean by text field here because, for the > > little of GUI I am using (Firefox essentially), I have observed this > > behaviour or not being able to use braille window navigation and routing > > keys in a very constant way. Is any place in a web page really a > > text-filed? > > Yes. Or more precisely: they all expose a text interface, even if they > don't have a text role. Since apparently orca doesn't capture routing > key events, these events fall back to being exposed to the a2 driver, > which gives it to brltty, which uses a2 to read the widget content, and > perform the cursor routing. Are you sure Orca does not deal with routing keys? See for instance the output of git grep -l processRoutingKey in the orca sources. Isn't this something that is working for years now? I mean, correct me if I am wrong but I thought it's not such a long time a2 is around and dealing with all the text fields, compared to Orca's ability to deal with routing keys. Unless there is a regression that happened in Orca and has somehow been masked? Even theprecedence mechanism is not that old, probably newer than a2 and thus even if a2 is there for a long time it's not such a long time it cantake precedence over Orca when there are widgets they both know how to render, right? > > Also, if the a2 screen driver "just" takes precedence, shouldn't things > > still work when it's not there? > > If Orca was capturing routing key events, yes. It appears that doesn't > happen. That's a real surprise to me. > In the test I made with Roberto's case, it really was brltty's way of > pressing arrows to simulate routing, that Orca doesn't implement > anyway. In which context (applicaiton, widget) did you test? Intuitively, I'd have assumed that indeed orca is not simulating arrow key presses as brltty does but that it rather implements the routing by simulaitng moves of the mouse ppointer, and mouse clicks. In particular, I was under the impression that, in fFirefox, when I am "clicking" on a link with the cursor routing keys, it's really like if I was doing a mouse click. > > > knows it brings better support in that case (the cursor routing you get > > > is achieved by the brltty core itself, not the a2 driver which is only > > > the "messenger"). > > > > But that is not what is supposed to happen when you click (use cursor > > routing keys) on links in Firefox, right? > > Ah, that part seems odd however, indeed. OK, I feel kind of relieved we can agree on this oddness, at least. ;-) > But again, which version of brltty are you using? 6.6-2 > > > So it's not really Orca that "depends" on brltty-x11, it's just that > > > brltty-x11 is an interesting complement to Orca, to improve screen > > > reading. > > > > I don't think it's fair to put things this way frankly. Currently, you > > simply can't read the screen in braille without brltty-x11... > > If that is so, it's a bug that needs a fix in Orca, and not just make > people install brltty-x11 as a workaround that we don't even understand > how it happens to work. Yes, I fully agree. Sébastien.
Re: [orca] Re: Braille navigation issues with Orca 44.1
Samuel Thibault (2023/09/04 21:01 +0200): > Ok, I see. > > So the behavior you expect is not actually implemented by Orca, it's the > a2 screen driver that takes precedence in the text fields Well I am unsure about what you mean by text field here because, for the little of GUI I am using (Firefox essentially), I have observed this behaviour or not being able to use braille window navigation and routing keys in a very constant way. Is any place in a web page really a text-filed? I did'nt see this widget as that generic and thought it was basically used for text _input_ fileds but I may be wrong on that. Also, if the a2 screen driver "just" takes precedence, shouldn't things still work when it's not there? I was about to use that things used to work but now I am unsure because perhaps brltty-x11 has always been installed on my system so perhaps this is here unnoticed since several years. > knows it brings better support in that case (the cursor routing you get > is achieved by the brltty core itself, not the a2 driver which is only > the "messenger"). But that is not what is supposed to happen when you click (use cursor routing keys) on links in Firefox, right? It is this behaviour, for instance, which does not work without brltty-x11 and does work with it. > So it's not really Orca that "depends" on brltty-x11, it's just that > brltty-x11 is an interesting complement to Orca, to improve screen > reading. I don't think it's fair to put things this way frankly. Currently, you simply can't read the screen in braille without brltty-x11... And you can't activate links with the cursor routing keys, so you are forced to use tab to give them the focus so that you can thenpress Enter. This workflow is really less efficient than being able to activate links throughthe routing keys. Sébastien.
Re: tty13-24
Hello, D.J.J. Ring, Jr. (2022/12/25 13:17 -0500): > I use ttytter for Twitter but unfortunately there's no Facebook text mode > application. But I can live without you Facebook. Somehow, m.facebook.com works with lynx, a bit. Not perfect but for some stuff, it does work. Sébastien.
Re: tty13-24
Many thanks for your report, Sebastiean. I found it interesting to read about your setup. Sébastien.
Re: tty13-24
Dear all, Many thanks for this thread! I was not aware that it was possible to have so many virtual consoles but I find it great. On my system, though, I originally had only 6 of them, the seventh being used for the X server and no consoles being available beyond (from 8, not to mention 13 to 24). Am I correct to assume that this is somehow due to systemd? Do those of you who have so many consoles available also use it, or not? Thanks, Sébastien.
Re: brltty failing to load in initramfs started before systemd-udev-settle.service
Hello, Below the response to a message from Samuel which didn't reach the list because it had been posted to an older address. Samuel Thibault (2022/11/13 21:52 +0100): > Hello, > > Digging back this old mail. > > Sebastian Humenda, le mar. 13 déc. 2016 09:03:14 +0100, a ecrit: > > The proposed change possibly breaks the initramfs-option of BRLTTY, but that > > never worked for me so far. > > In the Debian packaging there was a bug, we fixed it with Sébastien this > week-end, uploaded as version 6.5-5. Special thanks to Samuel for his help in this. Two remarks: 1. Practically, the ability to embed BRLTTY in initramfs means that one becomes able to have an encrypted hard drive and to have braille support for entering the passphrase to access it. 2. As suggested by Samuel privately, it may be suitable to have the support for embedding BRLTTY in initramfs upstreamed so that this feature becomes available in all distributions, especially in the context of being able to encrypt ones hard drive. Sébastien.
Re: brltty failing to load in initramfs started before systemd-udev-settle.service
Samuel Thibault (2022/11/13 21:52 +0100): > Hello, > > Digging back this old mail. > > Sebastian Humenda, le mar. 13 déc. 2016 09:03:14 +0100, a ecrit: > > The proposed change possibly breaks the initramfs-option of BRLTTY, but that > > never worked for me so far. > > In the Debian packaging there was a bug, we fixed it with Sébastien this > week-end, uploaded as version 6.5-5. Special thanks to Samuel for his help in this. Two remarks: 1. Practically, the ability to embed BRLTTY in initramfs means that one becomes able to have an encrypted hard drive and to have braille support for entering the passphrase to access it. 2. As suggested by Samuel privately, it may be suitable to have the support for embedding BRLTTY in initramfs upstreamed so that this feature becomes available in all distributions, especially in the context of being able to encrypt ones hard drive. Sébastien.
Re: [orca-list] Jos Lemmens passed away on November 9, 2021
Thanks a lot Didier for having shared the very sed news. I feel that our community of persons involved in accessibility for free software is so small that every member of this community is of crucial important, and that every loss is thus sad, painful and difficult to accept, a bit like in a harmonious family. To me, that seems even more true for the most involved of us, to which Jos obviously belongs. Sébastien.
Re: Iggdrasill, a new amazing screen reader
Hi again David, My understanding is that there are two distinct problems: sound during installation and sound after installation. I think the first problem should be reported as a bug agains the debian installer, if that has not been done yet. Regarding the second problem, what needs to be done to fix it certainly depends on which sound system you are using, e.g. pulseaudio, jack, pipewire, to mention just a few among many options. Best wishes, Sébastien.
Re: Iggdrasill, a new amazing screen reader
Hello David, all, D.J.J. Ring, Jr. (2021/12/29 21:07 -0500): > I love Debian but right now I cannot get the latest Debian to install > correctly, alas. Why? Did you report the problem? Sébastien.
Re: OOo crashing on startup?
Hi, No problem noticed here, with he version of OOO in experimental. Sébastien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Make syslinux beep?
Hi, IIRC correctly it has been discussed before and was rejected as to annoying for the normal case. I must say I agree with that. And I do also. However, I'd like to ask the folloing question: assuming that this may be of some help for others, would such an annoyance really be unacceptable ? Do you really mean that one should not let annoying things happen, if they may help others ? Here we are not even talking about something that would be annoying each time a system boots, we just talk about _installation_. Especially as there's not that much magic involved in booting from CD: just waiting for some time and hitting enter should also work. There is no real difference between there was no beep and I hit enter but nothing happened. It is not a question of pressing enter... Disabled persons may need to type some arguments to be passed to brltty at the syslinux prompt, e.g. to specify which serial braille device to use since this cannot be properly autodetected. So, if there is no way to be sure that the prompt has been reached, one will blindly type the arguments and then press enter, and then, if nothing happens, here will be no way to determine whether ithe problem occurred before or after the syslinux prompt. In both cases a disabled person is going to need help from others to figure out the cause. I am tempted to say that, although you may be right, that's not a reason not to do everything reanoably possible to minimize the needed help. Also, one can notice that it is often the case that the eyes reading the screen for us in emergency situations are those of a non-expert, sometimes non-english speaking person in France. That's why I already noticed that, the more information I can have by myself, the better the situation is. Sébastien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Make syslinux beep?
Hi, It is a bit hard for blind people to know exactly when they can type boot options for the installer. It would be helpful that syslinux beeps when it is ready to get input. What do people think about it? It'd be convenient, yes. In case people do not want an unconditional beep, would it be possible to configure syslinux so that keeping a well known combination of key pressed while booting would make it beep when it's ready to accept options. Sébastien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tasksel-data: Add an Accessibility task
Hi, It has been suggested that tasksel could have an accessibility tasks, which would automatically install e.g. the gnome-orca package and other accessibility-related packages. Excellent idea. That task could be automatically selected when installation detects a braille device for instance, How can the installation system be aware of the presence of a braille display, concretely ? The question is then: what should be put in such a task? Brltty Gnome-orca of course comes to mind, what else should be installed? Speech synthesis, dasher, gok, ...? Would it be possible to have a configuration dialog box bound to this task with checkboxes letting users choose the method they want to use for accessibility, e.g. braile, speech, magnification. Then the precise list of packages to install may depend on the selections done in this dialog box, i.e. accessibility through speech could for instance install emaspeak and cicero, whoc wouldn't be installed if only ccessibility through braille has been selected. Sébastien. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
