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.
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.
Some time ago I was told Pina can’t use ATutor: there could not be anything more revelatory than this.
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.