Over the last two years, it’s been my responsibility to build and maintain the Wiki Education Dashboard, a complex website that has become our primary tool for keeping track of hundreds of courses and thousands of students each term. It’s been an amazing journey so far — one I started with almost no experience in web development — and I’ve learned little bits of lots of facets of writing software and running a website. One area where our Dashboard is better than most sites is accessibility — but unfortunately, that’s not saying much.
Since the beginning of the Dashboard project, one of my most important power users has been Wiki Education’s Helaine Blumenthal. As our Classroom Program Manager, Helaine needs to be able to use the Dashboard efficiently to keep up with now more than 300 courses per term. Helaine is blind and uses a screen reader to navigate the web, which means that if a site isn’t accessible by screen reader, it’s broken.
With an interface largely written in the popular React framework and built from a wide variety of open-source JavaScript tools, the technology story of the Dashboard is pretty typical of recent web apps. Modern JavaScript frameworks have made it dramatically easier to build slick visual user experiences, narrowing the gap between what a designer can imagine and what a browser can deliver. But maintaining an accessible website has sometimes meant swimming upstream against the currents of web technology. JavaScript can rewrite a page in an instant, bringing us interactive “single-page applications” where you don’t have to reload the entire page to get from one feature to another. A site can show you just the information you need, right when you need it. But this visual information design often overrides the information hierarchy of HTML, which is the main way a screen reader makes sense of it as more than just a huge wall of text. JavaScript frameworks also mean that commons widgets and tools are easy to add to your site. JavaScript can make anything on the page look and act like a link or a button, even without the standard HTML tags. And with enough extra JavaScript code, you can make the webpage do just about anything, without worrying much about the underlying HTML.
In the last few years, the JavaScript ecosystem has gained a reputation as the ‘wild west’ of web development, with many exciting developments and opportunities against a backdrop of uncertainty and chaos. I’ve chipped away a tiny bit at this chaos when it comes to accessibility, making as much of the Dashboard usable for Helaine and any other screen reader users as I’ve been able to while reporting accessibility problems to “upstream” open source projects. But I didn’t really understand the scope of the problem until I started looking into options for help desk software, and taking a peak at the underlying code.
To support the continued growth of our Classroom Program — hundreds of courses, supported by one Classroom Program Manager and two Wikipedia Experts — we decided to invest in a system for keeping track of who needs help and who is helping them. Help desk / customer support software is a relatively mature “Software as a Service” niche, and there are many well-funded companies competing for market share. After surveying the landscape, I identified a handful of the most promising ones worth putting through their paces. At the top of the list was Zendesk, which seemed to be the most mature of the newer generation of help desk services (with about 1700 employees and 100,000 customers). Unfortunately, after signing up for a trial and testing it out with Helaine, it quickly became clear that having a large customer base and large engineering staff is no guarantee of good accessibility practices. It was unusable by a screen reader for even the most basic tasks, and from what I can tell by inspecting their website, they hadn’t even put in the smallest bit of effort. (We ultimately went with Desk.com as our help desk service; while far from perfect, it’s generally proved accessible enough for our needs — even with a similarly JavaScript-heavy interface.)
I’m always looking for ways to improve the usability and accessibility of the Wiki Education Dashboard, and I’ve still got a lot to learn. Now that I’ve dipped my toe into web accessibility, I find myself losing patience quickly with big software companies and open source projects that don’t even try.
What do you use Zendesk for? Email request queues? Knowledge base about the software? Other? I thought you already had GitHub, AskBot and maybe OTRS for that kind of stuff.
We’re using Desk.com for email-based requests and tasks, mainly the emails we get from instructors and students, along with alert emails that get sent from the Dashboard, so that we can easily reassign one based to the right person and deal with vacations and staff changes more easily.
AskBot is not very good for actually getting an answer back to the person who asked the question, and we use it mainly as an FAQ repository (for which it’s not as good as I had hoped… we’ll probably move that content into the dashboard itself eventually). For a help desk system, we did consider OTRS, but taking on the long-term maintenance of an OTRS server would probably be a lot harder in the long run, and our last memories of OTRS were from the bad old days in ~2011.