167
you are viewing a single comment's thread
view the rest of the comments

Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.

The fact that there (I assume?) isn't a braille oriented text editor that can handle space-based indentation in a smarter way is a bit depressing. Maybe the solution should be better tools based around accessibility rather than convincing everyone to switch to tabs, which is a project that will just never succeed.

[-] atheken@programming.dev 12 points 1 year ago

So your fix is “convince all the people that want/need the better handling to use a specific editor?” - perhaps it’s a smaller number of people, but do you not see the irony there?

I honestly don’t care about tabs vs. spaces, but if there’s a low cost change in my setup that makes it easier on others, why not?

My spontaneous reaction is that making some sort of braille oriented setting for some or hopefully most editors used by people with braille displays (I have no idea if using a "normal" editor even makes sense if you're using a braille display) is the most pragmatic solution to their screens being taking up by spaces.

First of all, convincing everyone to use tabs is a monumental task. Convincing people with braille displays to use more convenient tools on the other hand seems pretty easy, why wouldn't you want to use more convenient tools?

Secondly, there is a large amount of code written with spaces today, so even if people switch with tabs in the future you might still want to be able to read legacy code.

Thirdly, I don't think that the choice of tabs vs. spaces is completely arbitrary because of alignment. Using tabs for indentation and space for alignment leads to a lot more micro management of whitespace compared to just using spaces. I would guess that alignment isn't very braille friendly anyway, but it does make the code more readable for other people. Having a good braille editor affordance might be closer to letting us have our cake and eat it too.

Of course, I don't know what this would look like exactly, and maybe there's some sort of obstacle that I'm overlooking, I do want to be clear that this is just of the top of my head as someone who has never used a braille display.

[-] atheken@programming.dev 0 points 1 year ago

There’s a difference between doing something that’s “easier” and what’s right.

Whether there is more legacy code with spaces or tabs is irrelevant. Most of the code that will be written hasn’t been written yet.

I disagree with you on “micromanagement” of spaces vs. tabs, that is nonsense. Set up a formatter for commits and set your IDE to display how you want.

The pragmatic view on one or the other is that for a one group of people, using tabs appears to be significantly better, and for everyone else, it barely matters at all, except as personal preference.

That being said, I’m not vision impaired, so I don’t know what the preference would be.

The reason we’re even talking about it is that someone that has studied it from an accessibility perspective has asserted that tabs would be preferred.

There’s a difference between doing something that’s “easier” and what’s right.

The way I see it, there are two competing strategies for improving the experience for braille screen users: making tabs more widely used and improving braille oriented editors. Without knowing for sure, my guess is that improving editors is a better strategy and this is in part because it is easier.

As a matter of principle it might be "more right" for people without visual disabilities to adjust themselves to people with visual disabilities than vice versa, but I also think that it's important to care about what is actually likely to improve braille screen users experience and not default to the more principled goal without any consideration for how realistic it is.

(Of course, I might be overestimating how easy it is to get better braille oriented editors, but since you referred to this as the "easy" solution it doesn't sound like you're disputing this specifically.)

[-] TheCee@programming.dev 3 points 1 year ago

Of course, I might be overestimating how easy it is to get better braille oriented editors

A braille display traditionally is a personal, almost handfitted (estimated by price) device controlled by its screen reader software. Not the editor. This has some unfortunate implications:

  • There is no (standardized) API to control your braille device directly. You could hand your screenreader filtered data, but that would be read as well. At best, you might be able to script your screen reader software to a varying degree of success. However:
    • Every aspect about this is extremely abysmal in every possible way, so it will likely require you to fork over some biiiiig amount of cash to one of the vendors to provide a brittle plugin. In particular if we are talking about JAWS. Think of extremely unstandardized COBOL dev with less stability and more price gauging involved.
    • As far as free readers are involved, only the proprietary and licensing aspect go away. Still, developing extensions is terrible in many ways. For example, for ORCA, I was able to find out that you can extend it somehow. Alledgedly. NVDA on the other hand has better documentation. That is to say, it has documentation. Now, you might recall that NVDA is written mostly in Python, and its devs rightly don't even pretend that one could develop stable software in Python, so APIs might change. However, I wasn't able to find a Filter function specific to braille output. That's likely because
  • From my superficial experience, developers of screen readers think of braille displays mostly as an alternative to speech. It even took them quite a while to be smart about not displaying redundant, long lines of text.

So yes, you might be overestimating how easy that is, compared to telling some diva asswipe chucklefuck to use that formatter or work at McDolans.

Thank you for the insight, didn't expect it to be that dire. Tabs and spaces nonwithstanding, hope that the screen reader/braille display tooling situation improves in the future, sounds like it is sorely needed.

[-] TheCee@programming.dev 3 points 1 year ago

I sure hope so, but I'm not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn't easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.

So unless very specific regulation takes place, I don't see standardized access to braille displays happening.

[-] atheken@programming.dev 0 points 1 year ago

Let’s agree that we aren’t going to affect this change in this comment thread, so which one is more “pragmatic” is beside the point.

What does matter is whether we decide to have an inclusive view on this issue, and are willing to make extremely minor modifications to our settings and workflows to be more accommodating for others.

I am encountering more and more cases where people behave in inexplicably selfish ways, and this just feels like another one. It’s low/no-cost to do, yet could yield benefits to others. Low cost/risk, high potential reward.

Starting with “we’re not going to even consider raising awareness and let the market decide” is just a very cynical way to approach the world, and I’d argue is even actively harmful to the people that hold that view.

[-] zygo_histo_morpheus@programming.dev 3 points 1 year ago* (last edited 1 year ago)

Do you think it matters if getting a large number of people to switch to tabs is an achievable project at all? Maybe I am a bit cynical but this seems to me like something that is actually very difficult to do.

When faced with a problem like this I think it makes more sense to approach it from a perspective of what would be a practical way to actually address it and refusing to do that does I think in its own way betray a different kind of cynicism.

For the record what I'm saying isn't that I wouldn't switch to tabs for the sake of people with various disabilities, I'm saying that spaces are slightly better than tabs if you don't have any relevant disabilities so if there is a way to have the cake and eat it to that would be a nice bonus, but that's honestly besides the point.

[-] atheken@programming.dev 2 points 1 year ago

You are treating this as a binary/zero-sum game. Will we get to 100% use of tabs (or spaces)? No. Will we get a "perfect" viewer made and then adopted by all visually-impaired people? No. Making people aware that a fairly mundane choice has a negative impact on others might change their behavior, or at least challenge it.

Change like this is incremental, so just having the conversation, and asking you to consider that making a small change to your config might help some people down stream is something. Asking you to bring this point to the next conversation about tabs vs. spaces, is helpful.

I’m saying that spaces are slightly better than tabs if you don’t have any relevant disabilities

This is my fundamental issue with your original statements, and this thread: It's a subjective choice that you think is slightly better than removing a barrier/major annoyance for an entire group of people that may want or need to interact with your code. It's closing the door on possibility for a minor personal preference.

I think that there might be a fundamental missunderstanding here: I'm not saying that we shouldn't use tabs to accomodate people with disabilities, I'm saying that better editor features seems like a better "solution" to the problem.

In the abscence of editor improvements I agree that it makes sense to use tabs to accomodate disabilities, I just don't think that it will catch on that mutch. I don't think that spaces (imo) being slightly better is a good reason to not accomodate dissabilities by using tabs right now, but I do hope there is a more editor oriented solution some day because I think it would propably be better both for people with visual disabilities and without.

Being in a slightly argumentative mood might have led me down towards validating this false dicotomy between editors and tabs, and I apologize for wasting both our time because of this.

You do have a point that I personally might have more influence over if a given project has spaces or tabs than if better editor features are made, but I think that there can be a point to having the poor support for programming that is apparently offered by screen readers to take some place in the discussion as well since that is a potentially more important piece of the puzzle.

I can't imagine that there is much of a point to keep replying after this so I think I'll leave it here.

[-] pexavc@lemmy.world 4 points 1 year ago

Yeah. It is depressing.

I’ve always wanted an accessibility feature that uses haptic feedback to mimic braille patterns for reading purposes too.

In general a lot of creative stuff can be done if we focused on it even a tiny bit more.

this post was submitted on 05 Sep 2023
167 points (79.7% liked)

Programming

17314 readers
554 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS