[kbp]

I don't understand what most of these points have to do with accessibility. Why would a blind person have more trouble with the fact that "x + y" might be addition or string concatenation than a sighted person? Why would compile-time type errors be more useful to a disabled person? And so on. It just feels like your opinions on a lot of language design holy wars where disabled people are just as likely to disagree with you as anyone else.

> Don't worry about superficial tooling support. Solve the language design problems, the hard problems first.

That's mostly what people have been doing for the last most-of-a-century, and it's led to a lot of software being much harder to use for disabled people.

[austincheney]

The nature of accessibility is in solving universal access problems. It includes blind people but isn’t limited to blind people. One of the largest areas of accessibility is solving for cognitive impairments.

The classic example is wheel chair ramps. Who benefits from those? People who have bad knees, people with strollers, people with heavy roller bags. The ramp was installed for wheelchairs but everybody benefits. If the solution were limited only to wheelchairs almost nobody would use it. It would just be in the way and be more of a problem than a solution.

If you are only solving for blindness you don’t really understand accessibility and are just in the way.

[kbp]

You misunderstood. I only used blindness for the specific example where you used blindness (the only specific example of affecting someone with a disability that you gave; why would that be harder for a blind person?). Most of your points didn't explain how they related to accessibility, they just said your way was easier and better without explaining how or to whom. That's what I was asking.

[austincheney]

Many people conflate access to aesthetics. There is a difference between actual ease of access and perceived elegancy resultant from vane conditions.

Specifically regarding programming languages the primary concern is parsing, whether that parsing is from software or people reading code.

As a person who has spent 10 years writing language parsers and code beautifiers the vane notions of what a language should look like are highly subjective and not incredibly beneficial. The mechanics and syntax of a language are far more important for understanding what code says very quickly. Like with natural written language elimination of ambiguities and redundant meanings speeds learning and reading which has second and third order consequences for the simplicity of tool design.