[GH-ISSUE #270] Play nicer with Screen Readers #117

Closed
opened 2026-06-08 11:25:45 +03:00 by zhus · 6 comments
Owner

Originally created by @trypsynth on GitHub (Oct 20, 2022).
Original GitHub issue: https://github.com/bootandy/dust/issues/270

Hi,
I'm a screen reader user, and when running this tool, a lot of unicode symbols trip up my screen reader. Take this line:
291G ├─┴ Dropbox │ ████████████████████████████████████ │ 67%
Results in me hearing:
291G plus? Dropbox symbol
symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol │ 67%
Is there a reason these particular characters are used? If there is, could a flag for screen readers be added?
Thanks!

Originally created by @trypsynth on GitHub (Oct 20, 2022). Original GitHub issue: https://github.com/bootandy/dust/issues/270 Hi, I'm a screen reader user, and when running this tool, a lot of unicode symbols trip up my screen reader. Take this line: 291G ├─┴ Dropbox │ ████████████████████████████████████ │ 67% Results in me hearing: 291G plus? Dropbox symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol │ 67% Is there a reason these particular characters are used? If there is, could a flag for screen readers be added? Thanks!
zhus closed this issue 2026-06-08 11:25:45 +03:00
Author
Owner

@bootandy commented on GitHub (Oct 22, 2022):

You could try 'dust -b' which will not print the unicode symbols after 'Dropbox' in your example, however it will remove the 67% too.

The unicode symbols are there to provide a visual description of the directory. If you are a screen reader user they won't be much use.

I'll leave this open as I can add a flag to make it better for screen readers users. For instance there's no reason it can't say:
291G 67% Dropbox

<!-- gh-comment-id:1287672868 --> @bootandy commented on GitHub (Oct 22, 2022): You could try 'dust -b' which will not print the unicode symbols after 'Dropbox' in your example, however it will remove the 67% too. The unicode symbols are there to provide a visual description of the directory. If you are a screen reader user they won't be much use. I'll leave this open as I can add a flag to make it better for screen readers users. For instance there's no reason it can't say: 291G 67% Dropbox
Author
Owner

@bootandy commented on GitHub (Jan 27, 2023):

@TheQuinbox Is this a sensible sample output for a screen-reader mode?

Does it make sense?
Do you think it is upside down ?

$ dust -R tests/test_dir
12K 100% 0 test_dir
8.0K 67% 1 many
4.0K 33% 2 hello_file
0B 0% 2 a_file

<!-- gh-comment-id:1405794502 --> @bootandy commented on GitHub (Jan 27, 2023): @TheQuinbox Is this a sensible sample output for a screen-reader mode? Does it make sense? Do you think it is upside down ? $ dust -R tests/test_dir 12K 100% 0 test_dir 8.0K 67% 1 many 4.0K 33% 2 hello_file 0B 0% 2 a_file
Author
Owner

@trypsynth commented on GitHub (Jan 27, 2023):

Hey there, and thanks for your work on this!
I'd say it's upside down, yes. I use a terminal screen reader called TDSR, and when I run this command, I want to be able to M-u and m-o (m = meta key) through the output. The way you have it currently certainly works, but it's more efficient to have it the other way around. We can't skim lines, so it would turn "find test/ and see how big it is", into "Okay, this takes up 12 KB, okay that's 100 percent, ah that's test." I like the order actually, aside from the name (that should go first I think).
Thanks!

<!-- gh-comment-id:1405810637 --> @trypsynth commented on GitHub (Jan 27, 2023): Hey there, and thanks for your work on this! I'd say it's upside down, yes. I use a terminal screen reader called TDSR, and when I run this command, I want to be able to M-u and m-o (m = meta key) through the output. The way you have it currently certainly works, but it's more efficient to have it the other way around. We can't skim lines, so it would turn "find test/ and see how big it is", into "Okay, this takes up 12 KB, okay that's 100 percent, ah that's test." I like the order actually, aside from the name (that should go first I think). Thanks!
Author
Owner

@bootandy commented on GitHub (Jan 27, 2023):

Hey @TheQuinbox

Can you tell me which of these 2 options is better for you? The first shows the full path, the second doesn't. Also the second column what is meant to be 'path depth' - is that useful or would you rather it was not there? I imagine it's useful if you like option2 but not for option1.

$ target/debug/dust -Rp tests/test_dir
tests/test_dir/many/a_file 2 0B 0%
tests/test_dir/many/hello_file 2 4.0K 33%
tests/test_dir/many 1 8.0K 67%
tests/test_dir 0 12K 100%

$ target/debug/dust -R tests/test_dir
a_file 2 0B 0%
hello_file 2 4.0K 33%
many 1 8.0K 67%
test_dir 0 12K 100%

<!-- gh-comment-id:1407045806 --> @bootandy commented on GitHub (Jan 27, 2023): Hey @TheQuinbox Can you tell me which of these 2 options is better for you? The first shows the full path, the second doesn't. Also the second column what is meant to be 'path depth' - is that useful or would you rather it was not there? I imagine it's useful if you like option2 but not for option1. 1) $ target/debug/dust -Rp tests/test_dir tests/test_dir/many/a_file 2 0B 0% tests/test_dir/many/hello_file 2 4.0K 33% tests/test_dir/many 1 8.0K 67% tests/test_dir 0 12K 100% 2) $ target/debug/dust -R tests/test_dir a_file 2 0B 0% hello_file 2 4.0K 33% many 1 8.0K 67% test_dir 0 12K 100%
Author
Owner

@trypsynth commented on GitHub (Jan 28, 2023):

I'd have to go with the second one, although I see advantages to the first. The second would allow for quicker skimming with linear speech, so I'd say that.

<!-- gh-comment-id:1407478759 --> @trypsynth commented on GitHub (Jan 28, 2023): I'd have to go with the second one, although I see advantages to the first. The second would allow for quicker skimming with linear speech, so I'd say that.
Author
Owner

@bootandy commented on GitHub (Jan 29, 2023):

Added in version 0.8.4:

dust -R

(dust -Rp for full paths)

<!-- gh-comment-id:1407616473 --> @bootandy commented on GitHub (Jan 29, 2023): Added in version 0.8.4: dust -R (dust -Rp for full paths)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bootandy/archived-dust#117