[austincheney]

Accessibility is closely tied to portability. As a minimalist its not about what you can add but rather what you can take away and ensuring everybody understands reading the code with minimal effort everywhere.

A more accessible and portable language is one that eliminates overloading and redundancy. Everything in the syntax and expression is deliberate and its not open to various subjective forms of reasoning.

Eliminate white space as syntax. Beauty is subjective, but it isn't necessarily accessible, and it certainly isn't automatically simple. White space as syntax is common in nearly all languages. Even in Java there is white space to separate keywords. White space elimination allows any manner of visual expression and beautification of the language. It also prevents corruption of the code over the wire due to reformatting of corrupting user-agents and OSes that have different line endings. One form of corruption is when a token is shifted, due to different reasoning of line termination, onto a previous line terminated by a line comment.

Eliminate operator overloading. In JavaScript the plus character could mean addition, or string concatenation, or type coercion, or other weird things. The plus character could be a single character operator or the dreaded ++ which could mean post-increment or pre-increment. In JavaScript the forward slash could mean division or regular expression. For a blind person reading the code as characters or tokens this kind of overloading is unnecessarily confusing bullshit.

Conversely JavaScript has two different syntax forms for assignment. The common form of assigning is using a single equals character. In object literals a colon is used for assignment. This is stupid and looks completely different from the algebra on which equivalent logic is based. Make the colon character the character of all assignment. This leaves the single equals character free for comparisons. If the language imposes a strong/static type system there will be no need for double or triple character comparison operators.

I would invoke a strong/static type system. This allows error detection very early which reduces testing time and jumping between application environments.

I would design the language in such a way that it encourages code in structures. It is easier to follow code when it reads similar to its flow control at execution time. In this regard I would write the syntax such that it encourages containment, nesting, function as organizational models that can be nested, and design everything around primitive data structures.

I am not a fan of OOP programming where the application is easier to write/expand than to debug or read. OOP constructs tend to be convention heavy, keyword heavy, and syntax heavy. Functional/structured languages allow the deliberate organization of its pieces to do much of the heavy lifting as opposed to referenced or logical organizations.

Don't worry about superficial tooling support. Solve the language design problems, the hard problems first. The helpful tooling bits will be easy if you have nailed the hard decisions and produced something with clarity, simplicity, and deliberation.

[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.