Movable Type and TypePad, like all blogging software, fail to meet the Authoring Tools Accessibility Guidelines. The difference here is that Six Apart has known about it for years and claims to care, yet has done nothing.
Six Apart continues to receive venture-capital funding and other investments and, from time to time, announces significant licensing deals. Furthermore, now they’re buying LiveJournal, the service that real bloggers think is almost completely worthless and nearly a total joke. (LiveJournalers feel likewise of us.) Six Apart has at least 60 employees (published estimates vary: 79; “about 40”; “about 78”; “70+ and growing”) and offices in three countries – including the San Francisco headquarters. Six Apart likes to tell us their products are standards-compliant.
It’s a success story, isn’t it?
Not as far as one pressing detail is concerned. It’s not a mainstream issue and I doubt you’ll care about it, but then again, you’re probably not seriously disabled and only a minority of you are all that interested in using a mere blogging tool to produce accessible content.
Complying with ATAG
Between 2003.05.05 and 2004.01.29, I instant-messaged quite regularly with Anil Dash of Six Apart (and formerly of the Village Voice, where I wrote frequently). After breaking the ice a bit, I explained that blogging tools are actually authoring tools and, as such, fall under the ægis of the Authoring Tools Accessibility Guidelines (or ATAG, pronounced (aytag”).
- ATAG and the User Agent Accessibility Guidelines (UAAG; pronounced “youag”) are the orphan twins of Web accessibility. Every Web developer worth his or her salt knows about the Web Content Accessibility Guidelines (WCAG or “wikkag”), but few developers, whether they’re standardistas or not, have ever heard of ATAG or UAAG.
- We can usually assume that WCAG-compliant pages are reasonably accessible to a wide range of people with disabilities. We know of exceptions, of course; and there are other accessibility standards; and the lowest level of WCAG compliance, Priority 1, doesn’t even require valid HTML; and WCAG 1 and 2 are themselves notably strewn with errors, but the foregoing generalization remains broadly true.
- An ATAG-compliant tool makes it easy to produce accessible content and is itself accessible to a person with a disability. This is important; we can’t very well have only nondisabled people creating content of all kinds, including accessible content. You can’t go all the way with that idea, though, or else books would never be converted into accessible forms and captioning and audio description would disappear, as would sign-language interpreters. Accessibility for people with disabilities is inextricably linked to the work of nondisabled people. That doesn’t mean it’s permanently or exclusively linked in every case forevermore – hence ATAG.
- A UAAG-compliant tool lets you enjoy and understand Web content. It makes available any accessibility features coded within that content and may provide accessibility options of its own (e.g., a minimum font size or easy dictionary lookup).
To make the relationship among the three guidelines clear:
An authoring tool creates Web content that you enjoy with a user agent.
- Web content is something I defined back in the day as “whatever gives the visitor pleasure, or adds value, or informs, or makes the visit worth the time and effort.” (See paltry W3C definition.) Content is the what many types of sites principally provide. Even Web applications and service-based sites also indirectly provide content.
- A user agent (definition) is any device that renders or presents Web content. All your browsers and media players are user agents, as are RSS readers and, for that matter, Adobe Acrobat and Microsoft Word, both of which can open Web pages.
- An authoring tool (definition) is any device that creates Web content. GoLive, Dreamweaver, FrontPage (yes!), and any text editor you happen to use are all authoring tools. So is every kind of blog software on the market, including Movable Type and TypePad.
Now, if you’re Six Apart and you make a big deal about supporting Web standards, as Anil Dash did in his interview with A List Apart, you are actually signing yourself up for much more than the mere task of serving valid, semantic code. I assume Dash knew that when he wrote, in that interview:
Basically, we want our pages to be valid so that they’re accessible to the largest possible audience. And we want that broadness of accessibility to be a motivator for people to do justice to the breadth of their audience in terms of the quality of the ideas they express using our tools.
That interview was published in June 2003. Dash and I continued to instant-message for six more months. I talked to Matt Müllenweg and Matt May (“MC May Techno Dance Remix”) about the same issues. Matt May walked right up to Anil Dash at SXSW in ’04 and talked to him about ATAG, which Dash already knew about. And when I was last in New York, a comedy of errors prevented Dash and me from actually meeting (e.g., his shoephone skipped straight to voicemail whenever I called him from a payphone).
Six Apart has had a very long time to get a handle on this.
What would it take for Six Apart to do things right?
So what’s the holdup?
A detail of note here: Many browsers comply with most of UAAG, and we have a few thousand sites more or less accurately claiming to comply with WCAG, but nothing whatsoever complies with ATAG, including demo projects created by the W3C itself, like Amaya.
We could sit around and wait for inconsequential and minor products like Amaya to comply, or we could go big right away. Movable Type is pretty big, isn’t it? And aren’t they committed to standards compliance and accessibility, at least on paper?
That’s why I lobbied Dash for half a year. If we make a big commercial package like MT accessible, then:
- the whole thing suddenly appears possible after all
- it raises the bar for competitors
- it immediately attracts people with disabilities, accessibilitistas, and standardistas, who can combine the two statements above (“Movable Type does it. Why don’t you?”)
ATAG is not a trivial thing to comply with. It’s not a minor implementation detail, like using
alt="" for spacer graphics (if for some reason you’re using them in the first place). ATAG 1.0 has seven categories of guidelines and ATAG 2.0, still in draft form, has four. You need to laser-print the documents, read and decode them (they’re as hard to understand as everything else from the W3C), then come up with a candidate implementation for your particular system, test it, and release it.
But that’s the sort of thing a single Six Apart developer working half-days could finish in a week or two, at least to the public-beta stage. If they’re already doing things like publishing an API and localizing Movable Type into four languages (plus Dutch, albeit without localized documentation) – well, come on, Six Apart, you’ve got more than enough technical ability to comply with ATAG.
What about Blogger?
If I’m saying we need to make a big splash with ATAG compliance, couldn’t we make a bigger splash by making Blogger ATAG-compliant?
Of course. But it’s a lost cause. Start with the fact that Pyra were rather clubby (half its staff could be described as Blog A-List “Classic”), then note that Google is now resolutely corporate. They’re as easy to lobby as General Motors, and I don’t know anybody there in the first place.
But more importantly, Google doesn’t give a shit about accessibility or Web standards. Gmail is still inaccessible (see later complaint), despite one developer’s promise to fix it. I challenge you to find valid code on anything Google produces (for that, you want Find Forward).
Google doesn’t believe in valid code. Their computers are strong enough to bulldoze through whatever shite people put out, as far as they’re concerned. Let’s harken back to the days when Pilgrim actually still wrote a blog:
Sergey said, “Look, putting angle brackets around things is not a technology, by itself. I’d rather make progress by having computers understand what humans write, than by forcing humans to write in ways computers can understand.”
Google has invested millions of dollars into their code, and they can do amazing things teasing meaning out of piss-poor markup. They’ve written sophisticated algorithms to figure out which bits in a morass of nested tables and presentational markup are important, and they make the best possible use of the few tags that are universal (
titletag for page titles,
atag for links, and so forth).
Then again, Google doesn’t really have a choice. It’s their code, but it’s not their markup. So of course they’re going to invest money in code. It’s far more cost-effective to throw money at your own code than to try to get millions of independent developers to change their ways just to make your life a little easier.
But what if it’s both your code and your markup? Then you have choices.
What if you owned Blogger and set it up so that it complied with ATAG and WCAG – that is, the tool you own makes sure that average bloggers put out accessible code?
If freedom of the press belongs to whoever owns one, doesn’t accessibility of the press belong to whoever owns the blogging tool? You own the code multiple ways. The writer owns the original content, but you own the infrastructure to make that content accessible.
Isn’t that actually compatible with prevailing Google chauvinisms while actually aiding Web standards and accessibility?
And if Google isn’t doing something as simple as that (remember, even the recent Blogger redesign doesn’t validate), then are they really doing no evil?
What about WordPress?
If the makers of commercial blogging software like MT and Blogger are too lazy or uninterested to provide accessibility, shouldn’t we exercise our capacity as consumers and simply turn our back on them? Lousy code and poor accessibility are bad for business, and we can take our blogs elsewhere, as to WordPress, the open-source platform that runs this Weblog and another one I write. (That one’s actually hosted on Matt Müllenweg’s box, so I have some investment in the WordPress mafia.)
And here we find the same outcome with a different cause. Because of the decentralized nature of WordPress development, we need someone actually committed and, most important of all, actually competent to take on the task. (Open-source development relies on decentralized work.) Nobody’s done that yet, not even me. (I know WCAG; I’m not an expert in ATAG or UAAG.) Apparently one fella has recently taken on the task of WordPress accessibility, but he essentially told me to get lost, so the ball’s in his court.
Nobody’s got an excuse
Nobody’s got a decent excuse here, though WordPress’s comes closest to bare-minimum acceptability. But time is simply up for Six Apart. Unlike Google, they’ve positioned themselves as proponents of standards compliance and accessibility without actually following through. They’re famous and, while they’re not universally loved, they further position themselves as listening to complaints and reacting to them in the true Weblog style. Plus they’ve got lots of employees and lots of money when the task involves a tiny investment of work hours and next to no cost.
So, you know, I call bullshit on Six Apart.
What are the minimum requirements?
As part of the TILE project that later came to carry the title Best Practices in Online Captioning, I wrote a requirements document for a blogging tool that would support accessible online video.
In actual fact, I initially wrote that for Anil Dash and Matt Müllenweg (separately!). It didn’t go anywhere, so I made the terminology generic and published it elsewhere. It requires ATAG compliance as a first principle, then extends beyond that. It’s a useful place for makers of Weblog platforms to start, and it’s been online for months. Now you know!