Deleted Comment
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.)
Or maybe some response that doesn't contain an ad link but nudges you subconsciously to take desired action