I realize the rust evangelism strike force is a thing, but I can't help but think
5 | let scores = inputs().iter().map(|(a, b)| {
| ^^^^^^^^ creates a temporary which is freed while still in use
is easier to make accessibility tools for than
In file included from /usr/include/c++/4.6/algorithm:63:0,
from error_code.cpp:2:
/usr/include/c++/4.6/bits/stl_algo.h: In function ‘_RandomAccessIterator std::__find(_RandomAccessIterator, _RandomAccessIterator, const _Tp&,...
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.
Appreciate the vote of confidence, but I fear the default output isn't great for this usecase. In that example, you're cutting out the main message, file position and any message that comes after. It is also a single span in the main message, which is not uncommon but also not a given.
Ideally we'd provide a more narrative output with something like "file.rs, line 5, column 17, fn call to inputs creates a temporary which is freed while still in use". This would simultaneously be better for blind users, and give the people clamouring for more compact output an alternative.
>I realize the rust evangelism strike force is a thing
With rust there's no buffer overflows, how will folks buy supercars to crash in the desert after escaping "flyover country"
(In all seriousness, people were obsessed with it at Mozilla but also just kept hazing me I was "just" a UX researcher -- do you know of a good primer who knows the basics of languages like Python, bash, and QBASIC but struggles with compiled languages like C/C++?)
