I have a confession. There’s an elephant in my room. The problem is I don’t want to be unkind; so day after day, month after month, I tiptoe around it, speaking of it only behind closed doors.
But guess what? That’s not working. Surprise. And now it’s turning into years.
A few weeks ago, for a reason I can’t put my finger on, I decided the jig was up. The time had come to pay attention to this elephant.
However, I knew just blurting it out wouldn’t help. At best that’s making it other people’s responsibility — and more likely it would come off as scolding. Unkind? You bet.
But then, thank heavens, the next day I woke up with an idea – something I could do to help.
So What’s My Elephant?
The Accessible Web is dowdy. More precisely, it’s perceived as dowdy.
This is quite obvious to most of the rest of the world, but people like me, Web accessibility crusaders, play Emperor’s New Clothes games around it.
If this were just my issue, I’d get over it. But I know I’m far from alone in this opinion. People use different words – stodgy, lackluster, behind-the-times, and so on. Whatever the pejorative, as best I can tell the vast majority (if they know about the Accessible Web at all) think this.
I realize that there are a growing number of gorgeous accessible websites, but in the aggregate? and long-term? not to mention some of its most central repositories? and thus its reputation?
In other words, we’ve got a serious image problem. To quote my sysadmin friend, Heather: “Why are accessible sites the orthopedic shoes of the Internet?”
What Took Me So Long?
I’m all about making the Web accessible for everyone and I love the Accessible Web community – the many wonderful people who work their rear-ends off writing standards, building tools to help meet those standards, teaching, and much more. They are my tribe.
Also, until recently I didn’t have a reasonable solution to my gripe, so it’s just as well I kept my big mouth shut.
In my defense, for me this image used to be just a momentary visual, gone almost instantly because I know better. My everyday reality is anything but dowdy. Most days I’m having a fabulous time building accessible websites. And once a week I’m on an international call (from Australia to Austria) with that tribe, i.e., other Web accessibility evangelists. Sweet!
Meanwhile, however fleetingly, it was irking me — like a little headache that just won’t quit. So I paid attention to it and I talked to friends like Heather to be sure it was as real as I thought it was. Sure enough.
Going Deeper / Related Issues
Issue 1: Frumpy Reputation
Dowdy isn’t bad per se. According to some of my gorgeous women friends, at times it’s a big relief to look less attractive.
It’s just bad for the Accessible Web. If you ask anyone in the Accessible Web community, the number one goal is to attract people to the cause. In our ideal world, the entire Web would be 100% accessible.
But a frumpy image does the opposite of attract people. It suggests, however incorrectly, a lack of pride and sense of self-worth. And who wants to emulate that?
So here’s the heart of this issue – why it’s serious. As we carefully craft every word and polish our code in hopes of getting more and more people on board, we often package it in wrappers that drive people away. They never get to those perfect words and model code.
Worse, most developers I know have an impression like this – and in their case it’s often exacerbated by having heard how hard and boring it is.
Issue 2: Lack of Easy Feedback
Actually, developers are wrong that it’s hard. Mastering the ins-and-outs of accessible code is typically nowhere near as difficult to pull off as the programmatic acrobatics most of these code wizards excel at.
I think the real issue for them when it comes to accessibility is that they don’t have to contend with the instant feedback of (1) a page going blank or spewing code or (2) management either pushing back saying “That’s not what I want” or praising them for a job well done.
Issue 3: “Boring”
Then there’s “boring.” This is one of those “ouch” things, but I think they have a point. Look no further than WCAG 2.0 (the holy writ of Web accessibility). It’s anything but normal-human-friendly, let alone developer-friendly.
WCAG reminds me of the law. I was a law librarian for 18 years and perhaps my biggest take-away was seeing first-hand how virtually all legal documents are the last thing anyone except a lawyer would want to wade through.
That’s what being a lawyer is all about – buffering the rest of us from that misery and boredom. So perhaps buffering is what Web accessibility enthusiasts like me need to get better at?
Issue 4: Overwhelmed By Volume
It’s true there’s a ton of first-rate information that aims to buffer WCAG. But even I, an enthusiast, am overwhelmed by the sheer volume of it. Normal developers don’t even try. So instead of being a buffer, this massive heap of documentation becomes yet another impediment.
The funny thing is, though, I think this is a minor issue – in the “too much of a good thing” category. Getting better at buffering doesn’t mean putting WCAG secondary documentation on a diet.
Issue 5: Perfectionistic Sensibility
I have a theory that what actually makes this secondary documentation an impediment is a surreptitious perfectionistic sensibility that creeps into it from WCAG itself.
Legal documents are known to be fallible. Law… making sausages… you know…. But Web standards? They are held up as the ideal. Perfect. Heaven forbid Web standards be flawed in any way.
And heaven forbid that secondary documents, those core resources which explain the standards, be anything less than perfect. This in turn results in a “design-by-committee” approach to the secondary documentation.
I’m nowhere near as extreme as the design-by-committee haters. (See, for example, Why Design-By-Committee Should Die.) It’s obvious to me that for official groups some degree of design-by-committee is required.
But these haters do make some good points. Think about it. The dowdy look of many accessible sites is a classic outcome. You know. . . a camel is a horse designed by a committee.
To be clear, I won’t be addressing Web accessibility design-by-committee issues. There are indeed ways to do that, but that’s beyond the scope of this blog. What really matters is to recognize design-by-committee when it’s happening, in particular its most negative consequences.
In the case of Web accessibility, the worst consequence is that the very audiences we hope to persuade to adopt our best practices inevitably pick up on some aspect of this perfectionism – and like sensible people, they turn tail and run. For example, they might happen across a secondary document that was updated this year but looks as if it was designed in 1999. As soon as the document opens in their browser, they glance at it and are gone — leaving with an impression that Web accessibility is, you guessed it, dowdy.
What To Do?
I sincerely hope my analysis of the issues hasn’t offended anyone. In case it has, let me explain. The only reason I’ve done it is because, in my experience, understanding the problem is the critical step. It’s what moves you from symptoms to diagnosis, which in turn makes cures possible. And I know beyond a shadow of a doubt that there are some great cures for being perceived as dowdy. Dowdy is a far cry from seriously ill.
So what’s needed for a cure, i.e., a solution? If one-by-one you turn the above issues around, there are five requirements:
- First the obvious: make it look attractive.
- Focus on tools and methods that give you quick, easy-to-understand feedback, and that have a positive feel. Forget those tools that scold you, e.g., giving you big red X’s when you get something “wrong.”
- Make it fun.
- Make it easy. This is actually a theme and variation of #5.
- Eschew perfectionism. Try the Pareto Principle, i.e. focusing on the sweet spot of Web accessibility. I think you’ll see that it’s true here too — that 20% of great accessible coding addresses 80% of accessibility needs.
Official committees can’t do things like ignore the flip side of the 80/20 balance. But individuals? You bet we can. We’ve got wiggle-room. Which leads me to. . . .
My Little Solution
Here’s where I come in. I’m a light-weight by nature. This was a deep, dark secret for 40 some years. But now I’m retired. Whoopee! And one of the biggest wonders of retirement is that it’s liberated my inner Roo. I don’t care if people know that I don’t know things – not to mention I have no bosses and I’ve got some time to muck about. I like to bob around and be happy. (Mr. Web Diva christened me Roo. He should know.)
In any event, it seems the thing I’ve chosen to do is to make creating the Beautifully Accessible Web easier and more fun for everyone – particularly normal developers and the wonderful people who already know how to code accessible websites.
My mantra? Lighten up. Think small. Do things in tiny bite-sized chunks. It’s already super easy to choke on an assignment of creating either an accessible website or a beautiful website. Put the two together and you’re almost guaranteed to choke to death – unless you take small mouthfuls.
So today I prepare to launch a series of easy, lightweight tips for creating “The No-Longer-Dowdy Beautifully Accessible Web.”
Stay tuned for the next installment. . . .