You may be cherry-picking pieces from your compiler output, but all up I think you’re probably choosing the wrong parts, and even caring about the wrong thing.
rustc’s (default) “human” error format is going to be very messy for screen readers to follow, because it has a lot of visual alignment and decoration. You’re going to have to leap through hoops to make it decent for accessibility tools, whereas that C++ compiler’s output might not be quite so bad in some ways. (To clarify: I expect that both tools/formats are bad for blind users, in different ways. For sighted users, I don’t think there’s much of a contest—but the distinction is in the diagnoses more than their presentation, so this difference is about everyone, not blind people.)
But I think blind people probably genuinely shouldn’t be caring much about the error messages as they appear in a terminal these days, because this span formatting is always going to be lousy without very fancy tooling to sanely contextualise it, and guess what? There kinda is such tooling already: IDEs (and with the advent of LSP, it’s even broadly cross-language). Use something like rust-analyzer with your Vim + coc.nvim (what I use) or VS Code (the most popular choice) or whatever, and you can jump between error locations easily and have it all presented with your code, rather than separately. That way, the only accessibility support required is in the IDE, and that you have a language server (which people will want anyway ’cos they’re handy).
For a while now I've been meaning to do something about this. Users of TTS interfaces and braille displays can currently rely on whatever LSP compatible IDE they might use, but I would like to provide cli output that is suitable for them either out of the box or as a wrapper leveraging the JSON output. The one today isn't fit for purpose due to the heavy reliance on ASCII art.
The big problem I see is that the ASCII art output relies heavily on contextual cues, pointing into user code that might be too long and with messages that easily go beyond the capabilities of a Braille display. There are mock ups I've done, removing and rearranging things to build output that works as if someone was talking to you, but don't have the expertise to say that it works for the target audience.
If there are people with relevant expertise reading this, I would love to pick your brain. There are simple questions like "is it useful to truncate paths to be just the file name and let users rely on their tools fuzzy search to find them?" or "is it better to just mention the place in the file we are talking about and not display a snippet? Same for suggestions?"
My guess is that the rust human error format is derived from some raw format that could easily be propagated to any other UX/UI and right now we are only familiar with the CLI format. I doubt they are keeping the state with a string of "^^^^" rather than just some 'error_starts_at_char: 8' and then some pretty print function prints the ^.
With --error-format=json you can get both the underlying encoded tree as well as the cli output within a field. The later is useful for tools that don't want to do anything special beyond presenting the output inline. All the pieces are there, there just hasn't been anyone with all of interest, expertise and time to work on it.
rustc’s (default) “human” error format is going to be very messy for screen readers to follow, because it has a lot of visual alignment and decoration. You’re going to have to leap through hoops to make it decent for accessibility tools, whereas that C++ compiler’s output might not be quite so bad in some ways. (To clarify: I expect that both tools/formats are bad for blind users, in different ways. For sighted users, I don’t think there’s much of a contest—but the distinction is in the diagnoses more than their presentation, so this difference is about everyone, not blind people.)
But I think blind people probably genuinely shouldn’t be caring much about the error messages as they appear in a terminal these days, because this span formatting is always going to be lousy without very fancy tooling to sanely contextualise it, and guess what? There kinda is such tooling already: IDEs (and with the advent of LSP, it’s even broadly cross-language). Use something like rust-analyzer with your Vim + coc.nvim (what I use) or VS Code (the most popular choice) or whatever, and you can jump between error locations easily and have it all presented with your code, rather than separately. That way, the only accessibility support required is in the IDE, and that you have a language server (which people will want anyway ’cos they’re handy).
(Since I mentioned Rust’s error formats, relevant reading: `rustc --error-format=…` <https://doc.rust-lang.org/rustc/command-line-arguments.html#...>, and `cargo build --message-format=…` <https://doc.rust-lang.org/cargo/commands/cargo-build.html#op...>. My guess is that blind people would probably be better served by the “short” error format, or by tooling that consumes the “json” error format… like rust-analyzer.)