Elements or Lower

Thu, 13 Jul 2006

Odi et Amo

I recently wrote that my new, long-term mission would be to get the administration area of my CMS working with both the WCAG and ATAG.

Truth be told, I haven’t yet made any progress with this, other than to give some of the issues rather more thought. In doing so, however, I’m already being pulled in two different directions.

This first is to try and make the “Administration Shell” work, at least to a basic extent, in all browsers — even with JavaScript disabled. One of the key challenges here is the way that the Shell uses a visual editor to help publisher author HTML content. Sans JavaScript, the page contains a regular textarea containing the raw HTML code. With JavaScript, this is transformed into an editable representation of the HTML, with toolbars and whatnot.

Fundamentally, then, a publisher can edit content if they have JavaScript disabled: they merely need to know HTML first. And that, of course, isn’t really good enough.

Until recently, I’ve been very much of the school of thought that the only accessibility issue with JavaScript is whether or not the functionality you’re providing works on at least some level without JavaScript. The trouble is, that’s not true. As evidenced by some of the recent work on AJAX and accessibility, assistive technologies such as the JAWS screen reader operate on top of Internet Explorer — so, if IE has JavaScript enabled, so does the screen reader.

This, in turn, means the visual editor needs to be operable in a screen reader context. We can’t assume that if you’re using a screen reader, you’ll have JavaScript turned off. It means that popup windows such as those created by tools in the visual editor to allow the creation of links and insertion of images into content, have an impact. It means that the visual editor’s tools need to be device-independent. Those functions I’ve tucked away in a right-click menu become a problem.

On the other hand, I’m falling in love with script.aculo.us. Some well-placed visual effects here and there, and a little bit of AJAX magic in the right places, can work wonders on overall usability.

For example, the Greenwich Community Network’s contact form has some questions that ask you to expand on your answer to a prior question. Hiding the questions you’re not expected to answer using JavaScript improves the form no end.

Equally, The Woking Forum has a bunch of ongoing discussions with many, many responses. On page load, messages older than three weeks aren’t included, but a little AJAX incorporates them into the page if you want them.

In the context of the Administration Shell, there are a number of places where these kinds of technique would improve usability in general. For example, the Shell includes an expandable sitemap to help the publisher select the page they want to edit. Although it already takes some steps to split the DOM manipulation required to open and close levels of the hierarchy into manageable chunks, everything would be so much snappier if levels of the sitemap were only loaded when expanded, using AJAX.

The Shell also has a number of places where the publisher is asked to sort a list of items as they choose. For example, a navigation list for a level in the site hierarchy isn’t generally sorted alphabetically, or by date, but according to an arbitrary sort order of the publisher’s choosing. Coding a usable interface for this kind of thing isn’t easy.

Except, of course, it is. The current Administration Shell doesn’t use a drag-and-drop list. Instead, it uses a series of buttons marked “here” for the publisher to indicate where they want to position an item within a list. But this is terribly clumsy, means that anything other than the shortest list takes up an acre of screen space, and means that it’s impossible to alter the position of more than one item at a time.

The main problem with scrip.aculo.us’s drag-and-drop sortable lists, however, is that in being drag-and-drop, they’re as far from being device-independent as you can get. It’s not possible to use the keyboard to sort one of these lists. I had hoped to improve accessibility within the Shell, not make it worse.

So, on the one hand, I want to be able to claim WCAG compliance for the Administration Shell. I want to be able to lift the browser-sniffing on the Shell for Window on Woking. I want to be able to apply the same rigour to the back-end of sites that I’ve started to apply to the front-end.

But, equally, I want to make the Shell as easy an environment to use as possible. I want to be able to take advantage of the good things to come out of “Web 2.0” (but not the name).

I’m hardly alone in trying to get to grips with this kind of problem, and the community will find answers in time, just as it always has. For me, I suspect the answer may lie in having a set of preferences for the Shell, where publishers can make the choice as to whether they’re comfortable with drag-and-drop or not, and whether they want to edit content using the visual editor, or using Markdown. As long as I don’t find myself tempted to stick a bunch of JavaScript into the preferences screen, that is.