FWIW I implemented SARIF output in GCC 13, which gives a machine-readable interchange format for the errors. It's viewable by e.g. VS Code (via a plugin). Hopefully that makes it easier to grok the messages.

You can see an example of the output here: https://godbolt.org/z/aan6Kfxds (that's the first example from the article, with -fdiagnostics-format=sarif-stderr added to the command-line options)

That doesn't cover the diagrams though (which I currently serialize in SARIF form by making a placeholder Markdown text containing "code" containing the diagram).

I experimented with SVG output for the diagrams, but didn't get this in good enough shape for GCC 14.

I've got a few ideas for more general UX improvements with how we do diagnostics, which I'll try in GCC 15 once we're finished focusing on GCC 14 bugfixing.

They read every symbol or character that is displayed. Normal errors are verbose but at least they have meaning. Pictures that use ascii or other characters end up having all the symbols read too because there are no semantics associated with the picture.

I like to ask this question on posts about new libraries or developer tools, because most developers don't consider the accessibility of the features they're building.

For those curious, here's an example of emacspeak reading a fairly basic c error from the terminal: https://youtu.be/t3BgDa1p7Qc?feature=shared&t=270.