A while back I mentioned I made a AAA web site that conformed to the Web Content Accessibility Guidelines (WCAG) version 2.0. The site was for California disability rights attorney, Lainey Feingold, who works primarily with the blind and visually impaired community on technology and information access issues. She is nationally recognized for negotiating accessibility agreements and for pioneering the collaborative advocacy and dispute resolution method known as Structured Negotiations. That’s from her site — a site which is one of just two AAA implementations (the other being Vision Australia).
I didn’t talk about it too much back when I made it. I was waiting for the higher-ups to hand down their verdict, confirm its status, and list it on their site. It passed. It’s now official. And it’s listed: you can check out the details of this implementation on this W3C WAI page. And now that that is done and the WCAG 2.0 is “real” — meaning officially implemented (proving it works) — and that it’s about to become our web accessibility guide after the proposed recommendation’s review period (the final recommendation is slated for release this December), it’s time to briefly discuss the overall experience of working within. Getting there, and making it so — some impressions.
That heading best describes my impression of the WCAG 2.0 when I first set eyes on it. At the time I wasn’t looking forward to upgrading, so to speak. But that was down the road, albeit not nearly as far down that road as I had thought. I didn’t know I’d find myself neck deep in it so soon. I had a job to do, though, so I rolled up my sleeves and got to work. I started by doing some reading. Lots of reading. Too much, I dare say. One of the problems I noted almost immediately was that I was reading typical W3C-generated content. In other words, long pages with wall-to-wall text, monster links from hell, well, you probably know what that’s like. While the WCAG 2.0 is very thorough, it suffers from a lack of simple readability.
I cannot fully lay blame on the publishers. It’s a conundrum. You’ve heard the expression that describes packing ten pounds of stuff in a five-pound bag, right? That’s what the W3C’s WAI had to do. Personally I’d prefer more page views with less scrolling and a narrower main column. That’s me. In my opinion that would aid readability and thus make the material easier to digest. Someone else, however, may like just the opposite. I think it’d be a good idea to add a style changer to better accommodate individual tastes allowing users to study under ideal conditions.
Regardless, all this aside, in no time at all it’ll be just like working under the WCAG 1.0: no heavy reading. We’ll be working with a document one has become familiar with. Give it time.
Getting Into It
It didn’t take days or even hours to sense the direction of the WCAG 2.0. Essentially I quickly saw it as more rigid and matter-of-fact. Less gray area. The WCAG 2.0 is very clear, albeit wordy. It leaves very little for erroneous interpretation, unlike the WCAG 1.0. I immediately felt that was a positive attribute. With the WCAG 2.0 there should be fewer false claims, fewer misleading icon fliers touting wishful thinking, and other “accessible site” maladies.
I also realized the core accessibility is essentially the same. A developer meets each applicable individual success criterion contained within each applicable guideline under the recommendation’s four principles. The game itself has changed very little in many regards. User needs haven’t suddenly changed, today’s accessibility requirements are much the same as they have been all along. Many developers, myself included, have been incorporating the logical bits of the WCAG 2.0 for a while. An example would be
input placeholder text; it hasn’t been needed for quite a long time. I haven’t used it but once in the past three years, and it wasn’t for accessibility.
One change is how one has to be somewhat more methodical during development (but maybe that’s because I am new to the WCAG 2.0 even though I’ve worked with it), and how one publishes their optional conformance statement. Expect more tedious albeit optional paperwork getting there if it’s going to be official. It reminds me of growing organically. Anyone can become an organic grower, it’s easy, but if you want to sell a tomato and tell buyer’s it’s organically grown, by law you must support the claim via recognized certification.
In light of this it seems to me accessible sites will be made in one of two ways in the future. First you’ll have those who make a site, make it accessible, and then go on to the next project. Then there will be those who will make a site, make it accessible, then spend another day or more explaining what success criteria were applicable to the site, and how each applicable success criterion was met (or not). I will probably produce accessible sites the easy way, making no claims. This will satisfy most developers and most clients. Some companies, however, are going to want and need a proper conformance statement — documentation supporting the legal claim of their site’s accessibility. After all, why would they bother making their sites accessible if they aren’t complying with the law or being forced to. Sorry, I’m not trying to sound negative, but I don’t see many companies making their sites accessible for the sole purpose of providing access.
Room for Abuse?
I mentioned applicability above but didn’t explain. It’s really quite simple. If you embed an image on a web page, for example, then any success criteria associated with doing so must be met in order to claim that page’s conformance. Conversely, if you have no embedded images on that page, then you can ignore the applicable criteria — for that page — claiming partial conformance or none at all. Where once having a failing page would’ve changed the status of the site as a whole, now pages and even whole sections can be written off. My concern is I wonder if we’ll see long and complex partial conformance statements cropping up, linked to from a global footer. One vaguely declaring an accessible site. You know, like a badge.
The WCAG 2.0 is more rigid and matter-of-fact, as I said before, but it may also be looser because of this partial conformance alternative. If one can discount individual pages, that helps lessen the challenge of actually having to figure out a way to get the job done right and going for that ever useful whole-site accessibility. Will developers be content making some accessible pages?
To the credit of the WCAG 2.0, one page that doesn’t make it can lead to whole sections not making it and that is quite fair. An online shop is a good example of how this might apply. A real example, in fact, is my hosting site. It’s very, very accessible, one of my better builds and one of my favorites. I didn’t bother claiming it, though (even though I could), as I’d have to disclaim the shopping part of the site in the statement. The shop itself is just fine, fully accessible, but final check out is at PayPal and I’m afraid they just aren’t there yet in terms of making their stuff conform. A la WCAG 1.0 thinking, I don’t feel comfortable “claiming” anything because of this issue. In my eyes a web site is a whole package and it is either accessible or it isn’t.
Unless I am specifically hired to create a site that claims to conform to the WCAG 2.0, complete with documentation, I probably won’t bother. I’ll just make my typical AA whole-site and be happy people can use it. I will make no claims. Anyway, actions speak louder than words. If the site is accessible people will be able to use it. Claims or lack thereof won’t have a bearing on this fact.
My advice, make and keep your stuff accessible. If the WCAG 2.0 allows something you know isn’t as good as it could be, then do it right. Don’t take liberties at the expense of others just because you’re permitted to. Also, don’t bother with writing a conformance statement unless you’re prepared to upgrade the entire site, or at least the bulk of it. Don’t think you’ll be doing anyone any favors making an “accessible” site that “conforms” if you’ll be disclaiming big chunks of it. The WCAG 2.0 may allow and maybe even condone this, but I think it could be a cop out.
And if you do plan on doing it right, do it for the right reasons. In the case of LFLegal.com, some of what was added to the site was added solely for conformance. Some of it, like the dumbed down page summaries, I personally feel detract from the site’s usability, cluttering it unnecessary. In the case of that site, though, reaching AAA was an end, not a means.
Also be sure to charge appropriately. Not for the accessibility. That should already be part of your pricing and not an extra as you’ll do no less. If you’re going to claim the site, though, making it official, expect to burn away some hours doing so. I think a documentation up-charge of anywhere from 10-40% of the site’s projected cost will be reasonable and expected.
This is my opinion as of this time. I may be right, wrong, or simply confused. I am not yet intimate with the WCAG 2.0 (that’ll take years), but the observations I shared herein are what I came away with from this virginal experience. All in all, minus a few troubling items, I feel the WCAG 2 is generally headed in the right direction. A lot of its success will hinge on how developers use it and how companies try to abuse it. And of course, much will depend on whether or not businesses and institutions are compelled to even go there. Time will tell.
This was quite the experience and I did have some help along the way. Specifically I’d like to say thanks to Lainey Feingold for choosing me as her developer, to Jim Thatcher, Gregg Vanderheiden, Ben Caldwell, and Joshua Miele for their expert accessibility suggestions and insights, to Louis Libert for helping with content coding, and to Thierry Koblentz and Dave Woods for some CSS bug-tracking and screen shots, respectively.