Some time ago I had the chance to talk about ATutor with one of its developers, or perhaps that was not the right word: I had a heated argument with one of its developers was more like it. Until that point, I never knew we hold such divergent views on web accessibility. The crux of the heated argument was, in essence, ATutor’s reliance on Javascript for one of its most basic and essential functions, namely to log the user in, for what amounts to, technically speaking, no justifiable reason; it was, in a very real sense, a deliberate exclusion put into place. For someone who had primarily been a text browser user until just a few years ago, this was unacceptable, and this was doubly unacceptable when ATutor claims itself to be usable with text browsers. This is in effect, one could argue, a textbook case of “inaccessible” — it doesn’t matter if you can use its other functions, it is inaccessible if you can’t get in. I had, and still have, the opinion that if a web site — unless it’s an online game — relies on Javascript for any essential functionality, the site must have serious design flaws somewhere. The flaws might be hidden from view or latent and yet to be discovered, or the flaws might even have nothing to do with the “Javascripted” functionality; but, I maintain, some serious flaw must be present and it must be fundamental, because such use of Javascript demonstrates a fundamental flaw in the developer’s mentality. This was, or should I say is, not the opinion of ATutor’s developers. To them, Javascript is fair game because any “modern” browser would have it. Besides being insulting (I still consider w3m modern, thank you very much, and people who consider Javascript a security threat still exist), less than a month ago I happened to run across a BBC article about a UN accessibility report on web sites that stated quite bluntly that one of the “key shortfalls” for 73% of web sites tested was that they “relied on JavaScript for important functionality“ because “JavaScript does not work with some screen readers used by those with impaired vision.” [emphasis mine] Were ATutor tested, the UN testers would have failed it for relying on Javascript for, quite literally, its most essential functionality. This was vindication for me: I was told they didn’t consider Javascript reliance an accessibility problem; the UN thought otherwise. Some time ago I was told Pina can’t use ATutor: there could not be anything more revelatory than this. And I still maintain that there is no essential functionality — zero, nada, zilch — in ATutor that absolutely requires Javascript. What’s worse, I looked at their code base and their code is not amenable to automatic testing. In our program we claim to aim for Agile, but Agile relies in a large part on automatic testing (in the form of TDD or BDD). Short of a major code overhaul, there’s no way TDD could be performed on ATutor’s code. Thus the false claim that ATutor works for text browsers (most likely it used to in an earlier version) when in fact it doesn’t and no one noticed. Two months ago when I was looking at its code I wrote it was a “genuine piece of crap.” Their developers claim integrating small patches is expensive, but ATutor in its current state can’t be tested; of course the integrations are expensive. It wouldn’t be an exaggeration to say that the mentality of how ATutor is developed flies directly in the face of everything taught in our program, in particular designing for the extremes and disability as a condition caused by design flaws in the environment. Unless ATutor’s developers have a change in mentality, I don’t foresee ATutor achieving any semblance of true accessibility any time soon, if ever.