The Italian web developer community is abuzz — the css Zen Garden is not AAA compliant!
Since the beginning, the css Zen Garden has featured five links at the bottom of the site (or elsewhere, depending on which design was used to view it). Two of those links — 508 and AAA — deal with accessibility, and lead to the results of validating of the site with Bobby.
Pages 36 and 37 of the Zen of CSS Design talk about this issue:
After the markup was written, a quick check from Bobby confirmed that it passed most major accessibility checkpoints. A few quick changes were needed before launch to fix the few glitches that Bobby noticed. A link labeled “AAA” was added to the footer of the Zen Garden to signify that accessibility had been taken care of.
Or had it? It turns out the Bobby is not final word when it comes to accessibility. If you familiarize yourself with the Web Content Accessibility Guidelines published by the W3C (see “Better Accessibility” earlier in this chapter) you’ll soon realize there are guidelines that Bobby simply can’t check. Checkpoint 2.1, for example, states that all information conveyed through color needs to be available to the viewer without color as well — software like Bobby has no way of distinguishing this, especially if the information and color are embedded in an image.
In fact, if you do some digging on the Bobby site, you’ll also find this disclaimer:
Accessibility is ultimately a human endeavor. It is determined by whether or not a diverse group of people with a variety of abilities and disabilities can access information efficiently. Bobby is just one step in helping to make web pages more accessible, but cannot guarantee total accessibility.
So the Zen Garden’s HTML theoretically passed all accessibility checkpoints related to markup but there are further checkpoints that go beyond HTML. A few of them even apply to CSS, and it became evident over time that some designs weren’t taking these into account. And when you consider the accessibility implications of Fahrner Image Replacement… it’s easy to see how the CSS can quickly cause problems that no automated checker can diagnose.
The lesson learned is that automated tools like Bobby may serve as a useful starting point for building accessible Web sites, but WCAG provides many more checkpoints that are equally as important, which it cannot check for you.
By way of explanation, more than excuse, what we find is that markup I wrote two years ago — with, I have no problem admitting, less understanding than I have today — now seems imperfect in today’s context. We know more about accessibility, we know why the link is problematic, and we know that ultimately, true AAA-level accessibility is often unattainable.
So in today’s context, as the Italians who have emailed me pointed out, the links aren’t working. In many cases, css Zen Garden designs break AAA, AA, and who knows, maybe even A (depending on your level of interpretation.) Then again, some do not. But if it’s all or nothing, why do the links persist?
Two reasons. First, as I’ve also detailed in the book, the point of being able to change structural items of the markup has long passed. Content changes (ie. anything not in angular brackets) are still somewhat possible, as is evidenced by the fact that I seem to have gotten away with adding a line announcing the existence of the book. Structural changes (ie. anything between < and >) are not.
There are 150+ official designs, and close to four hundred others (the latter hosted on servers not controlled by me.) Changing the structure potentially destroys some or many of these. This is a deal-breaker. We’re stuck with having five links in that footer, for better or for worse.
The second reason is more philosophical. The links signify that efforts were made to pass accessibility tests. They call attention to the fact that the design work which is added to the site remains accessible, albeit in varying degrees. In essence, they are a wake-up call to those who might otherwise be completely unaware that accessibility and good design can co-exist. A simple link to a validator says more than a full paragraph could, and if not for some on-site recognition, then this point would likely be missed very often. Signifying that accessibility was intended is a major point of the site.
So the problem appears to me as one of simple nomenclature. How do we title these links? If AAA is not being met, would AA or simply A suffice? If there were a way to succinctly say that “this site was built with accessibility in mind; although the odd design here or there may not meet every requirement, overall it does pretty well” and cram it into 8 characters or less, I’d be happy to talk about it. So far I haven’t come up with anything myself, perhaps someone else will.
Ultimately, this discussion is frustrating, not a new one, and feels largely irrelevant. AAA is a stale guideline that has been in need of a massive overhaul for years. True accessibility requires much more education and thought than what’s found in the 14 guidelines of WCAG 1.0. Getting wrapped up in the specifics of what precisely constitutes AAA (or Triple-A if you insist) ignores the larger issue that the guidelines themselves need work. Let’s be honest, anyone knowledgeable enough to take part in this particular conversation should be aware of that.
But that’s an aside, not a shifting of the blame. If this is perceived as a genuine problem on this particular site, tell me what should be done. You now know my dilemma, so what’s the fix?
And as a polite reminder to those members of the Italian web design community previously referenced: context is everything. During the recent SxSW conference (which was mentioned in the sidebar on the same contact form used to reach me) email response time dropped considerably. Add the second conference I attended less than a week afterward (also mentioned), and I’m sure how you’ll understand why replying hasn’t been a priority. So while I can’t help but admire the devotion, the daily emails can be called off now. Much appreciated.