ATutor

Happy too soon…

ATutor’s email links are still un-RESTful. The bug has not been fixed. Since I am sure it worked a few days ago, I’d say the bug has become even more serious than before: It now occurs randomly… Sigh. How long does it really take for the ATutor devs to fix these serious usability bugs?

Apparently, ATutor’s RESTfulness bug has been fixed

Clicking on forum post links in email no longer sends us back to a course home page. So it looks like this serious bug has finally been fixed. Still no idea why the bug existed in the first place, but this is some good news.

A real course this term

This semester we have a real course again. It can even be anything really. But I missed the course add deadline, so what I have is just what I would have had if there were still no electives in our program. Anyway, it’s an ATutor course too, complete with forum discussions which we have not had for two straight semesters. It’s embarrassing but having seen so many complaints on Canvas, ATutor — with all its numerous and serious failings — doesn’t really look so bad any more. It’s embarrassing but I feel at home doing these ATutor discussions. I can even fantasize about being able to just do this ATutor stuff and pass program requirements. But of course I know this isn’t real. Unlike another “real university” here which shall remain unnamed, we don’t have course-based programs here; we are an art school, we have higher standards =P

Why ATutor is inaccessible and always will be

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.
Syndicate content