Re: Accessible terminal output
On 1/30/24 06:22, Christian Schoepplein wrote: On Mon, Jan 29, 2024 at 08:40:07AM -0700, Sam Hartman wrote: Neils, I think what you are about to find is that individual preference generally dominates accessibility concerns here. Yes. All what I wrote is the prefered way I like to work because it is the most simplest way for me. This does not mean, and thats what I also wrote, that others do also like work this way. Its all a matter of personal taste. What sighted PPLs see first (in this case at the top of your answer) is what they will pick up on! ;^) -- John Doe
Re: Accessible terminal output
On Mon, Jan 29, 2024 at 08:40:07AM -0700, Sam Hartman wrote: >Neils, I think what you are about to find is that individual preference >generally dominates accessibility concerns here. Yes. All what I wrote is the prefered way I like to work because it is the most simplest way for me. This does not mean, and thats what I also wrote, that others do also like work this way. Its all a matter of personal taste. Regarding accessibility piping content into a pager or reading out the screen with a braille device or the navigation functions of the screen reader is also fine ofcourse, everything can be read and no content is missing. Ciao, Schoepp
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
Neils, I think what you are about to find is that individual preference generally dominates accessibility concerns here. > "Christian" == Christian Schoepplein writes: Christian> Hi Nils, Christian> On Sun, Jan 28, 2024 at 11:54:24AM +0100, Niels Thykier wrote: >> 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. Christian> Piping output into a pager is very uncomfortable for Christian> screen reader users IMHO. To navigate such content you Christian> either have to use the keys of a connected braille device Christian> or use the screen reader commands to go through the Christian> output. Both variants are much less good then piping the Christian> content into a programm where the user can navigate the Christian> output just with the normal arrow keys, like navigating Christian> through a file in an editor, or piping the content into a Christian> textbased browser like w3m where the content also can be Christian> navigated by using the arrow keys. I'd much rather have content in less than in w3m. 1) I do have my screen reader controls optimized for something I like to use, so being able to navigate with the screen reader keys is in my mind a plus not a minus. 2) I always have less available; I would not normally expect a text mode browser to be available on a remote server. 3) I find pagers to be a good interface in the common case I actually want to read the entire screen. I find the simple ":" prompt of less or the "--more--" of more less disruptive than a status line of an editor or browser. For me, reading tabular output, the best advice I can give is to focus on making the table row elements as simple as possible. For example separating each row element with a single pipe and spaces rather than something more complicated. I appreciate that the header line--or the separator between the header and the rest of the table--may be more complicated. That's not a big deal, but the more lines with lots of dashes I have to work through, the more annoying. I would definitely find pipe separated text easier to read than CSV. Although in exceptionally complicated tables, I would find being able to take CSV into a spreadsheet convenient. For reasonably simple tables, I would probably choose to read pipe separated text rather than to take HTML5 and read it in Firefox. I find the text output of sqlite entirely reasonable unless the number of columns in the table gets large enough and the data is sparse enough that I cannot remember what column is involved. I generally refine my query in that case rather than turning the table into html. --Sam
Re: Accessible terminal output
On 1/29/24 14:50, Niels Thykier wrote: Christian Schoepplein: Hi Nils, [...] Piping output into a pager is very uncomfortable for screen reader users IMHO. [...] Ciao, Schoepp Thanks for the hint, Schoepp. This sounds like the screen reader optimized output mode should imply disabling the automatic pager feature. For context, the default behavior of my tool is to pipe output to a pager if and only if 1) requested otherwise via an option such as the --no-pager option and 2) the output stream is a identified as a terminal. The latter means if you explicitly pipe to another program or file, the automatic pager feature is disabled as well. Accordingly, the your `| vim -` trick would have worked. That said, I still want better defaults where I can reasonably provide them. For the same reason, I have logic to rewrite man page references into links to https://manpages.debian.org/page.section, because my understanding was that manpages were rather difficult for users of screen readers as well. The above statement is way to general and only reflect one PPL. Manpages that are using the `man` utility are perfectly accessible along with their online counterpart! ;^) The best way to help someone is when issues are reported to you -- John Doe
Re: Accessible terminal output
Hi Niels Thykier schrieb am 29.01.2024, 14:50 +0100: >Christian Schoepplein: >> Hi Nils, >> >> [...] >> >> Piping output into a pager is very uncomfortable for screen reader users >> IMHO. [...] >> >> Ciao, >> >>Schoepp >> > >Thanks for the hint, Schoepp. Just as a second confirmation, I do the very same, usually Vim and w3m. :) >For the same reason, I have logic to rewrite man page references into links >to https://manpages.debian.org/page.section, because my understanding was >that manpages were rather difficult for users of screen readers as well. I actually do man $1|vim -, though that breaks some of the encoding. Apart, I like man pages. But maybe this is "hard to read" refers to the default pager of man which is a bit cumbersome, indeed. Cheers Sebastian signature.asc Description: PGP signature
Re: Accessible terminal output
Christian Schoepplein: Hi Nils, [...] Piping output into a pager is very uncomfortable for screen reader users IMHO. [...] Ciao, Schoepp Thanks for the hint, Schoepp. This sounds like the screen reader optimized output mode should imply disabling the automatic pager feature. For context, the default behavior of my tool is to pipe output to a pager if and only if 1) requested otherwise via an option such as the --no-pager option and 2) the output stream is a identified as a terminal. The latter means if you explicitly pipe to another program or file, the automatic pager feature is disabled as well. Accordingly, the your `| vim -` trick would have worked. That said, I still want better defaults where I can reasonably provide them. For the same reason, I have logic to rewrite man page references into links to https://manpages.debian.org/page.section, because my understanding was that manpages were rather difficult for users of screen readers as well. Best regards, Niels
Re: Accessible terminal output
Hi Nils, On Sun, Jan 28, 2024 at 11:54:24AM +0100, Niels Thykier wrote: >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. Piping output into a pager is very uncomfortable for screen reader users IMHO. To navigate such content you either have to use the keys of a connected braille device or use the screen reader commands to go through the output. Both variants are much less good then piping the content into a programm where the user can navigate the output just with the normal arrow keys, like navigating through a file in an editor, or piping the content into a textbased browser like w3m where the content also can be navigated by using the arrow keys. At least I do avoid using pagers because I can not use the arrow keys to read the whole content. So, instead doing a ls -1 /dev/ | less I prefere much more this, because in vim I easiely can navigate through the text just using the normal keyboard: ls -1 /dev | vim - Or also this: ls -1 /dev | w3m The same is with the output to the normal screen, not into a pager. Also this content has to be navigated using the screen reader functions which IMO is always much mor les comftable then using just the normal keyboard navigation. But thats all my personal taste. I am much faster using the normal keyboard functions then navigating around with the screen reader or a braille device. Im sure other blind people work completely different... Ciao, Schoepp
OT: Re: Accessible terminal output
On 1/28/24 22:09, Sébastien Hinderer wrote: 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. With regard to git status, you are talking about human readable output while I'm talking about machine readable output (porcelain)! ;^) Anyway, the OP will choose what is best in his case! -- John Doe
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
On 1/27/24 22:18, Niels Thykier wrote: Hi, (Please CC on replies as I am not subscribed) I am looking for advice on how to make the terminal more accessible. The context is that I have a terminal program sub-commands. For some of them, I currently render an ASCII table sometimes with unstructured notes following it as legends for users without visual impairments - usually piped to a pager like less. Though this formatting is almost certainly not accessible to screen readers. I imagine it would be something like "PLUS, 50 times DASH, PLUS" and so on for the divider lines. I tried searching for terminal output accessibility and I cannot find any useful advice among the search results. So I thought I would ask here if you have any recommendations or guides I can follow. So far, IRC suggested to provide an alternative formats like CSV or HTML5, which the user could redirect to a file and then process in a tool of choice that would be accessible to them. Do you have any other recommendations for terminal output to support visually impaired? Like should the tool disable ANSI color and boldface output to avoid creating confusing output? Thanks for your support. 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. -- John Doe
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
Samuel Thibault: Niels Thykier, le sam. 27 janv. 2024 23:10:08 +0100, a ecrit: Samuel Thibault: 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? It wholy depends on how you emit your output. In curses terms it's a question of using move() to set the coordinates of the carte. Samuel 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. Best regards, Niels
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: Accessible terminal output
Niels Thykier, le sam. 27 janv. 2024 23:10:08 +0100, a ecrit: > Samuel Thibault: > > 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? It wholy depends on how you emit your output. In curses terms it's a question of using move() to set the coordinates of the carte. Samuel
Re: Accessible terminal output
Samuel Thibault: Hello, Giving a very small answer here. Niels Thykier, le sam. 27 janv. 2024 22:18:23 +0100, a ecrit: Like should the tool disable ANSI color and boldface output to avoid creating confusing output? Screen readers just ignore colors & bold/italic :) Thanks. :) One thing that is important for the screen reader to know what to render is to put the caret on the item that matters. Samuel 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 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. 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. Best regards, Niels
Re: Accessible terminal output
Hello, Giving a very small answer here. Niels Thykier, le sam. 27 janv. 2024 22:18:23 +0100, a ecrit: > Like should the tool disable > ANSI color and boldface output to avoid creating confusing output? Screen readers just ignore colors & bold/italic :) One thing that is important for the screen reader to know what to render is to put the caret on the item that matters. Samuel
Accessible terminal output
Hi, (Please CC on replies as I am not subscribed) I am looking for advice on how to make the terminal more accessible. The context is that I have a terminal program sub-commands. For some of them, I currently render an ASCII table sometimes with unstructured notes following it as legends for users without visual impairments - usually piped to a pager like less. Though this formatting is almost certainly not accessible to screen readers. I imagine it would be something like "PLUS, 50 times DASH, PLUS" and so on for the divider lines. I tried searching for terminal output accessibility and I cannot find any useful advice among the search results. So I thought I would ask here if you have any recommendations or guides I can follow. So far, IRC suggested to provide an alternative formats like CSV or HTML5, which the user could redirect to a file and then process in a tool of choice that would be accessible to them. Do you have any other recommendations for terminal output to support visually impaired? Like should the tool disable ANSI color and boldface output to avoid creating confusing output? Thanks for your support. Best regards, Niels
