Hacker News Reader

Comment by miki123211 | Hacker News Reader

This kind of fancy terminal manipulation is usually an accessibility nightmare.

Real GUI frameworks usually provide semantic information to the OS, which allows screen readers to determine that a given control is a progress bar that is 50% filled, and then render that information by playing an appropriately-pitched tone. In a TUI, all they get is a line of fancy symbols changing quickly, with no context as to what those symbols mean. Same for i.e. ncurses based menus. When programs use colors to signify which menu option is selected, screen readers usually get lost.

Screen readers specifically designed for text-based systems (such as DOS) usually had ways to work around this issue, but modern, GUI-focused ones don't really offer those options any more.

View on HN

All terminal applications should have a 'basic' (or to use Git terminology, 'porcelain') output mode by default, and an alternative renderer for more visually inclined people as an option.

Most recently, Yarn 3 went way overboard with their installer, to the point where it's... visually overwhelming? Tree views, colors, dotted underlines, multiple scrolling segments, etc. It's a bit better if running in CI mode (no coloring), but still not ideal.

On 'porcelain', the way Git uses that term is a pet peeve of mine. On the one hand, the intended meaning of it is that "porcelain" commands are meant for humans, not for other programs - scripts should use the "plumbing" commands (apparently, it's a toilet analogy). On the other hand, the flag that makes "porcelain" commands write machine-readable output is called... "--porcelain". Implying it does the opposite of what it does.

Gah, I'm beginning to think the git CLI is trying to be confusing on purpose.

https://stevelosh.com/blog/2013/04/git-koans/

Is the zen of git to stop using git? Somewhat inspired by OpenBSD I spun up my most recent side project with cvs. I'm amazed how much less stressful code management has become. Makes me want to go further back in time and learn how to properly use rcs.

I think the author of that blog post prefers Mercurial.

Now try a merge.

I've done a few, it's been fine. If you try and use cvs like git sure you're going to get burned. There's a reason Linux was using Bitkeeper and not cvs after all. But if your project organization works well with cvs, you can seriously avoid the massive wad of incidental complexity that is git.

I mean, when I was using cvs because cvs was the only thing I could use I don't think I was trying to use it like git and I was still pretty happy when better things came along. Subversion and perforce in particular improved merging massively long before git came onto the scene.

CVS was fine for small projects with a couple devs at most. Anything more than that and you needed someone on your project with far more domain knowledge in cvs than git requires now to avoid losing all your data in a botched operation on the thousands of independent rcs files a repo consisted of, so I really can't agree about avoiding massive wads of incidental complexity.

Git is, if anything, far simpler than cvs in just about every way imo. I could see myself using subversion for a lark, but I'm very happy if I never have to touch cvs again.

> The novice thought for a few moments, then asked: "Surely some of these could be made more consistent, so as to be easier to remember in the heat of coding?"

> Master Git snapped his fingers. A hobgoblin entered the room and ate the novice alive. In the afterlife, the novice was enlightened

Wasn't machine readable output is obtained via --terse historically? Some toolkits we use provide --terse flag to dump output in a pipe friendly manner.

It makes more sense if you look at the whole option.

  ... --porcelain[=<version>]

The idea is to present the porcelain at a specific version. So really you should read it as "give me the porcelain (for v1)", e.g.:

  git status --porcelain=v1

If it was an environment variable instead it would be

  GIT_PORCELAIN_VERSION

But that's not what it does. Try it.

    $ git status
    On branch master

    No commits yet

    Untracked files:
      (use "git add <file>..." to include in what will be committed)
     foo

    nothing added to commit but untracked files present (use "git add" to track)
    $ git status --porcelain=v1
    ?? foo
    $ git status --porcelain=v2
    ? foo
    $ git status --porcelain=v3
    fatal: unsupported porcelain version 'v3'

No --porcelain option gives you the output in the format of the git status porcelain, either at the current version or at Git 1.x or whatever, i.e., "give me the porcelain" is the wrong reading of the option.

The correct reading is "I am implementing a porcelain myself, give me a format I can parse in order to do that."

It’s funny how wrong this is.[1] No, `--porcelain` is machine output format, and the machine output format is (sensibly) versioned (you of course need to version such output—the output of `git status` writ large is not versioned afaik).

This [2] answer by VonC even quotes a mail where someone said that it was “[their] fault, to some degree.”

[1] Because it proves the opposite point.

[2] https://stackoverflow.com/questions/6976473/what-does-the-te...

> ... scripts should use the "plumbing" commands (apparently, it's a toilet analogy) ...

Ah this term finally makes sense to me, since it's meant to deal with human output.

Better yet, OS-wide flag to force most compatible output format. No need to rob everybody of fancy graphics.

> All terminal applications should have a 'basic' (or to use Git terminology, 'porcelain') output mode by default, and an alternative renderer for more visually inclined people as an option.

Also makes it easier to integrate them to scripts/pipelines.

The terminal is a visual tool. That makes it inaccessible, almost by definition. Terminals are text-based, but they can still be used to convey non-textual information (ie. progress bars, graphs, etc).

There's no sense in expecting a visual application (such as the terminal) to be somehow accessible out-of-the-box.

Trying to automatically translate a visual interface to an accessible interface is bound to be error prone and not work in all cases. What's accessible for a blind person, may not be accessible to a deaf person.

Applications should share the core business logic, but have entirely seperate "frontends" for every situation. A graphical frontend, and an accessible frontend. We need an open cross-platform standard for this, and enforcement.

"Applications should share the core business logic, but have entirely seperate "frontends" for every situation."

I think its clear from your post that you have never dealt with the visually impaired or even explored accessebility options of iOS/MacOS/Windows. We have working accessebility for all applications throughfully designed with native OS controls.

Having separate front ends will never happen, most businesse sproduce a single bloated JS app that crashes equally on all platforms.

> "We have working accessebility for all applications throughfully designed with native OS controls."

The comment I'm responding to says that progress bars in the terminals, and that TUIs in general are an accessibility nightmare.

Are you disagreeing? Are you claiming that it's a solved problem? Would you mind elaborating on what you think can be done to solve this?

You're misinterpreting the GP's post, TUIs are not "thoughtfully designed with native OS controls".

No, that's exactly my point.

The bulk majority of applications people use today are not "thoughtfully designed with native OS controls". Sprinkling some ARIA labels around is better than nothing, but the experience itself is extremely limited and is not on-par with what those people deserve.

I'm talking about Javascript/CSS-heavy websites in a web-browser, computer games, or software such as Blender/SketchUp/Google Earth to name a few. ARIA labels aren't good enough here - we would need to develop an entirely different interface to accomodate for each individual accessibility scenario. You can imagine a blind person and a deaf person using entirely different versions of Blender, each built with a different interface accomodating a specific disability.

> I think its clear from your post that you have never dealt with the visually impaired or even explored accessebility options of iOS/MacOS/Windows. We have working accessebility for all applications throughfully designed with native OS controls.

...which is a simple consequence of Windows people not being used to polyvalent software. You're putting horse before the cart.

This argument has been brought up in the accessibility community multiple times, and it's not as straightforward as you might believe.

The problem with accessibility-focused frontends is that they lack in features. There's a much smaller number of users able to detect bugs and a much smaller number of developers willing to fix them and add new features whenever they appear in the mainstream app. This works pretty well for i.e. accessibility-first Twitter clients, but it probably wouldn't for your local utility company that serves ten or so blind customers, none of whom are programmers.

> "The problem with accessibility-focused frontends is that they lack in features."

Isn't that a consequence of building different tools that fit people with different situations? We do exactly this with physical tools and constructions: we build a wheelchair-friendly ramp alongside a traditional stairway. It's going to be a trade-off either way, right?

If we "choose" (I fully understand this is not an actual choice done by anybody) to stick to tools which try to auto-magically translate visual-first frontends into accessible frontends - we must accept that there will be things that mess with that translation process and cause it to fail. It's unrealistic to expect a translation that works 100% of the time, reliably. Sometimes it's a minor technicality that can be worked around - but other times it's because data presented visually in a certain way, can't always be translated to something else (ie. a heatmap, a 3D multiplayer game, etc). How do we make the Mona Lisa accessible to a blind person? On that same strength - should TUIs not be allowed to have progress bars or other visual elements?

The solution here is to augment our tools with the information a screen reader needs.

To follow your example, we don't build separate bank branches for wheelchair users, we just extend existing branches with ramps, elevators and anything else they might need.

We already do this with other kinds of user interfaces. For example, web pages can be annotated with ARIA attributes, which don't influence how a page looks, but tell the screen reader that something is a checkbox which is currently unchecked. This is only required if you don't use the native HTML checkbox control, of course. Other platforms have their own ways of doing this, see iAccessible and UIA on Windows, ATSPI on Linux and AXElement on the Mac, for example.

Terminals were never meant for use cases like this, look at how hacky tty control codes are. If not for the fact that they're basically a bunch of ugly cludges that somehow work, there would probably be an aPI for that too. For now, though, we have to live with what we have.

> "The solution here is to augment our tools with the information a screen reader needs."

So we are in agreement that there should be different interfaces that suit each experience, we just disagree on the exact implementation details. I submit it's best to build entirely seperate experiences, but you submit it's enough to take the graphical-first experience and annotate it enough so that a screen-reader can generate an equivalent experience on the fly (using different kinds of annotation technologies). My response to this is:

1. Annotations and metadata (ARIA-labels, et-al) make it easier for the screen-reader to display relevant information in an accessible manner - but they create an unnecessary coupling between the visual-first frontend and the accessible frontend, when in reality they are built for different kinds of users.

2. Annotations are a decent starting point, but they are NOT a substitute for building an "accessibility-first" experience because they are too limited. You can't annotate a graph, or a progress bar, for example. But you could've built an entirely seperate experience which conveys the same data a graph would, in an accessible manner (given the right tools and frameworks).

On the other hand if we know something will break one use case totally, to provide marginal utility in another, then it's probably not a good trade off.

> but it probably wouldn't for your local utility company that serves ten or so blind customers, none of whom are programmers.

This is exactly why section 508 and ADA liability rules exist. If they don’t know how to make their programs accessible, a very expensive lawsuit will show them how. Also, why would a small utility be writing their own software? Shouldn’t they be using COTS?

Many command line tools have been adding 'tty mode' for years so that if you run the command through a pipe you get simpler output that is easier to parse and record. If you're at an interactive shell you get all of the 'special effects'.

You will still find many that don't do this properly, especially if you run the commands through a CI tool which is typically a dead giveaway. Browser based log viewers aren't going to handle VT100 escapes and so you see garbage in the output. In this regard using unicode emojis to pretty things up works more reliably.

I would presume that a screen reader should do the same thing. Turn off tty mode so that the stream is easier to parse.

This feels very short sighted, oddly. Your visual terminal interface is visual, sure. But there is nothing that says that has to be how you interface with a terminal. It is just a character/symbol stream connection. With interrogation commands that can go back and forth, there is nothing that says it can't be as accessible as you want it to be.

> "there is nothing that says it can't be as accessible as you want it to be."

And there is nothing that says that it should be accessible. Which is exactly why a terminal, going by the very definition you yourself provide, is very difficult to work with from an accessibility perspective. There are simply too many degrees of freedom, allowing you to represent data in too many different ways, making it very difficult for something like a screen reader to "parse" the buffer (which can contain anything, not just text) and convert it to something meaningful.

Using a terminal, one can implement a progress bar in hundreds of different ways - and it would be impossible for a screen reader to handle all such use-cases.

Out of curiosity, when you have a large amount of text flying by like with package installs, what is the expected accessibility behavior? I imagine a screenreader trying to keep up with the install logs in any way would be... chaotic.

It tries to read everything, but you can flush it with control. If you notice it stopped speaking, you usually use some review commands to look at the last few lines. If you're looking for something specific, you'd usually use something like grep, even in situations where a sighted person could just glance at the screen.

might sound a bit insensitive. But is there a video I can see of this? I cant even imagine how this would look in the hands of an expert.

No, not to my knowledge. I could probably find a podcast or two, there are quite a few of those aimed at a blind audience, but that's about it.

Not exactly what you asked for but the "Designing for the Visually Impaired" episode of the Roguelike Radio podcast has a blind player play a roguelike. The intro has a bit of screenreading but the gameplay is starting at around 1:15.

While listening, you should put on headphones and concentrate very hard. It's quite fast and other sensory input might be disturbing so also close your eyes.

http://www.roguelikeradio.com/2012/10/episode-48-designing-f...

Saqib Shaikh, a blind developer at Microsoft, gave this short talk on using Visual Studio: https://www.youtube.com/watch?v=94swlF55tVc

I realize this isn't a console, but I think it is a good demonstration of an expert doing typical developer activities.

A good point and one I hadn’t considered before (shame on me). Does anyone have a good reference on making accessible terminal programs?

As a web developer I’m intimately aware that there are many gotchas and nuances to be aware of - I have to figure the same is true of the terminal.

If it works correctly on an old-school TTY with a printer and a roll of paper, you're pretty much done. That's how you should view a terminal screen reader, except it talks instead of printing.

Using it with a non-monospaced font would probably be a good test too. Monospace makes some implicit assumptions (i.e. being able to see how things are aligned) which screen readers don't follow. Also avoid preceding important messages with long strings of text, in particular containing numbers, i.e. overly detailed timestamps in logs. A screen reader reads text line by line, so those usually make using the app less efficient.

If you want an actual user interface, not merely a command prompt, avoid the terminal like the plague. Exposing a simple web frontend might be a good idea here.

In apt at least the fancy UI can be disabled completely, see 'Dpkg::Progress-Fancy "0";'

apt is explicitly flagged as "shall not be scripted", and older tools (apt-*) shall be used instead. I'm guessing that they're also more accessible all-over.

Considering Debian installer has braille support, I don't think Debian could overlook something like this.

For apt the easy way around this is to just use apt-get since that has a traditional output.

But you make an interesting point. I've lamented the current practice of hard coding escape sequences in the past for novelty reasons: https://news.ycombinator.com/item?id=26013556 But a screen reader could theoretically implement a terminfo entry that could be checked by an application to see if cursor control is supported. If not then it could fall back to a plain output method which I believe should make following along audibly easier.

Accessibility isn't the only problem, terminal logs are also screwed up. Try scrolling up when apt is showing its fancy progress bar, you'll realize logs beyond a screenful is simply "eaten". Overall not a fan of the unnecessary TUIzation.

No problem with tmux...

Reply on news.ycombinator.com