Supports for blind CS students: Guest blog post from Andreas Stefik

After my post last week on learning CS and programming by blind students, Andreas Stefik sent me an email.  Stefik has been working for years on these issues, and created the first programming language explicitly designed for blind programmers, Quorum,  He provided additional information on some of the things I’d talked about, and corrected me, too.  I asked if I could turn his message into a blog post, and he kindly agreed. Thanks!

Mark,

I came across your latest blog (about learning CS blind) and thought I would add a couple thoughts. Your student has it pretty spot on for the most part, but there’s a lot of variation in this community and thought I would add my perspective, for what it’s worth. First, if you aren’t aware of it, there’s a mailing list that many blind people use to discuss issues they face in blind programming called prog-l. I’ve lurked on there for years to try to get a sense of the diversity of needs in the community. It has everyone from total learners to experienced pros, with various levels of vision. People vary quite a bit in this community, so it’s a nice place to probe people’s brains and get opinions.

Second, blind CS students should know there’s a conference they can participate in called EPIQ. That’s our national Quorum conference, which is heavily attended by TVIs (teachers for the visually impaired) and blind folks. This year, the conference was mostly on writing 3D games in Quorum (audio + visual). It’s the first time we’ve tried to make something as complicated as 3D gaming accessible, but I think it went really well. If students want to go, they should apply. We almost always have funding to help students come out.

In terms of the post, there’s only one thing I would mention that is maybe questionable. That is when you say:

The second surprise was about their tools. They showed me Visual Studio and EdSharp, a plain text editor developed by a blind programmer for blind programmers. I asked what features made an editor good for blind programmers. They said, “It works with screen readers.” And really, that’s it. They don’t want specialized tools with non-standard interfaces because of the cognitive load of switching between the standard screen reader interfaces and a novel interface.

This is a tricky issue and in my view is not correct. Screen readers are not universal in the same way programming languages are not and blind programmers vary massively in their tool preferences. Different programming languages also connect to them in different ways (some good, some less so). Further, there is no such thing as a universal “screen reader API.” That doesn’t exist. I want to make this clear because it sounds like there would be, or at least should be, and it’s counterintuitive that it’s not true. On the web, it is true (it is called Aria), but not for desktops. A few examples:

1. JAWS: Windows screen reader. Popular. Expensive. JAWS doesn’t have an API. It has a custom programming language you can learn to adjust settings, but this language isn’t very powerful. It works with some versions of some software on Windows. Visual Studio works mostly ok’ish with it.
2. NVDA: Free screen reader on Windows. Less popular, but free. NVDA does have an API and it is extremely flexible. By far, it is the most flexible reader on the market, which uses Python as a backend for customization. It also works with some versions of some software. There are lots of problems here too, but I won’t get into them.
3. Voice Over: The primary reader on Mac. It’s about as flexible as a piece of cement after it has dried, but works really well for applications written by Apple. It’s also free. There are other versions of Voice Over (e.g., tablets, Apple TV), but they are different. To my knowledge, there’s no API to adjust it. If you are writing custom software on Mac, you are at the whim of the programming language you are using, and UI toolkit, as to whether you even “can” support accessibility with it. Even if you can, “how well” is another issue.

   This isn’t to say that Apple doesn’t put a lot of work into making an API for accessibility: https://developer.apple.com/accessibility/ They do and it’s fine. But, the moment you stray from their API, which is in their languages, on their hardware, with their rules, it all breaks. Even if you connect into their API, voice over itself doesn’t have the kind of scripting capabilities that something like NVDA has, to my knowledge.

Now, this is even trickier once you start taking other platforms into account. Most platforms have some mechanism by which they claim accessibility works. Oracle’s Java has an accessibility API. Does it work? Not very well. Other languages (e.g., smalltalk): total crapshoot. Java on Android? Totally different. Microsoft’s API is one of the better ones — yet somehow even Microsoft Edge isn’t accessible (yet), even though IE was. The language wars impacts this community, if nothing else because it makes this stuff such a mess at the global level.

So, when I hear that an individual thinks connecting to a screen reader is good enough for an editor, I think that’s not quite right. That’s true today just because the field as a whole is incredibly inaccessible across the board, so when you get something — anything — working well, you suffer through and learn it. This is why some of my blind friends just use notepad and the console. However, we know from research that just a plain old editor for code, where you move up and down line-by-line is incredibly tedious and inefficient. Ignoring my own work on the topic (e.g., blind debugging) for a moment, check out this wonderful paper by one of Richard Ladner’s students (Catherine Baker): http://dl.acm.org/citation.cfm?id=2702589&CFID=653320883&CFTOKEN=24820033

The lesson: Even simple navigation aids in an editor make a big difference. For debugging, compiler errors, and so many other issues, this is true as well, although not in her paper. We try to combine all of the literature into Sodbeans (especially version 6), but our tools have their accessibility flaws as well. Our biggest flaw is caused largely by the fact that we connect through Java, which has accessibility problems caused by the JDK itself. Even with that flaw though, it’s used heavily in residential schools for the blind nowadays.

Anyway, this is a lot more than I was planning to write, but of course, I’m fascinated by blind programming and like this community a lot. I just felt like sharing, so there you go.

Stefik