I’ve been toying with the idea of creating a new authoring language (as none of the existing ones seem a good fit) and would like to make it easier for blind and partially sighted users.
Can anyone give me insight into which languages work best with screen readers and why?
I would imagine that structured BASIC is one of the easier languages to use, followed by Pascal, and that C and Perl are likely the toughest to use.
My reasoning is that BASIC has different keywords to start and end code blocks, Pascal uses “begin” and “end” whereas C uses curly braces and Perl is just full of punctuation.
I could be wrong though, hence this post.
I’ve also been wondering how common it is to use speech to text software to enter code, as I would guess using non-English keywords (such as “WriteLn”) would make that more difficult.
Inform 7, with natural-language coding, might be a good model for this since most of it reads like English. The difficulty would be formatting elements that include brackets, tables, and tab-formatting.
I could see a screen reader having a lot better time with
Entry Hall is a room. The description is "This is the way in. Exits lead North and South." Portrait Gallery is north of Entry Hall.
as opposed to something like
{room: [Entry Hall]
description: "This is the way in. Exits lead North and South."
exits: north { to: [Portrait Gallery] }
}
(Second example is just random and not indicative of any actual coding language!)
I agree with this. Bracket matching is the worst in any language, which is why editors come with visual assists for it. I can’t even imagine trying to keep track of that stuff in my head. Some languages like python use indentation instead, but that is definitely not going to help blind readers.
The most important part is that the IDE uses the appropriate accessibility APIs so that screen readers and braille terminals can do their thing. Nothing should require drag and drop to work. Scriptablity is a big plus.
Screen readers can be configured to speak punctuation and indentation, so neither are absolute barriers. (Indeed, punctuation vs indentation seems to be as much a matter of personal preference as it is for sighted users.) I wonder if Inform is actually in an uncanny valley where it requires just enough punctuation and indentation to be annoying both with and speaking them turned on. On the other hand I wouldn’t be surprised if the major even readers are flexible enough that they can be scripted to only speak punctuation and indentation between certain comments.
You might find some of the answers to this StackOverflow question useful. None of this is a substitute for real testing with real users, of course.
@HanonO : I was thinking of something with an emphasis on natural language, maybe borrowing ideas from COBOL and BASIC.
@tayruh : Yes, meaningful whitespace seems like something to avoid.
@rockwalrus : I am hoping to allow any text editor to be used - even if I do create an IDE - as some users might want to use speech to text software, such as Dragon Dictate.
I have bookmarked that StackOverflow question to refer to later. Thanks for that.
You might want to consider writing a Language Server for your language so that people can get a lot of IDE features from the editor of their choice. A lot of editors support that standard.
Ruby is my favorite general language, and one of the reasons for that is its extraordinary flexibility, and one of the things Ruby-ists do with that flexibility is write domain-specific languages (Creating a Ruby DSL). When Ruby-ists say DSL, we mean an internal DSL: it’s really just Ruby, but with effort (sometimes a lot of effort) you can enable writing code that’s very readable and pretty highly writable. I’ve done a little noodling on an IF system in Ruby – here’s a code excerpt:
# create a "describable" class with name and desc attributes
self.class.maker('describable', name: "", desc: "")
# make the "room" class a subclass of Describable with attributes for the directions
Describable.maker('room', *(raw_dirs.flatten))
room :the_living_room do
name "The Living Room"
desc "The living room is a mess."
down :basement
end
room :the_dining_room do
name "The Dining Room"
desc "The dining room is very tidy"
north :the_living_room
end
The room definitions themselves aren’t that exciting; we don’t see there much utility beyond what one could get with a YAML file. The more interesting part is that the room class was created dynamically from a describable class that had been created dynamically. Additional attributes and classes can be added that easily. (Of course *(raw_dirs).flatten isn’t pretty, but users of the system wouldn’t be defining room themselves.)
The class definitions aren’t as clean as I’d like them to be; I haven’t spent time with this since the initial couple of days of hacking.
If you haven’t done so, please check GameMaker. Its script is very close to BASIC. The big problem with BASIC is the non compatible dialects. QB64 / FreeBasic seems to be very common, but still not what I consider universally available.
I once came up with a parody language where methods were bulleted lists like something out of PowerPoint. Needless to say, it was pretty verbose. It borrowed a few pages from COBOL.
@rockwalrus : It’s probably a little too early for me to start thinking about IDE features at this stage.
@Zed : I’d prefer to avoid using an interpreted language to create a DSL, especially one that would need to be installed separately by Windows users.
The Ruby examples at Wikipedia also seem quite hard to follow.
@ramstrong : From what little I have seen of GML, it doesn’t seem very screen reader friendly, even if you use the Pascal style block delimiters.
I’m not sure what you mean by “universally available” but QB64 is available for Windows, Linux and MacOS, which are the most used modern platforms.
In any case, this would be a new language even if it does end up being a domain specific version of an existing one. I am hoping to create it using a cross platform compiler and not require installation (if I can avoid it) though.
@nilsf : I actually found COBOL to be reasonably easy to learn about 30 years ago. The toughest part was remembering which columns were used for what, but I’ve heard that doesn’t matter as much in more recent versions.