Pragmatica11y: On critical thinking and being acc-sexy-ble

Share on FacebookShare on LinkedInShare on Twitter

I want to tell you a story about a community of passionate individuals, fueled by the desire to make the Web a more accessible place for everyone: one that values inclusion and diversity. One that passionately believes people with disabilities and the elderly deserve to use the Web like the rest of us. A community that has become cloistered and has repeatedly burned bridges as it pounded its inclusion message away to the much larger community of people who build websites.

This is a community that not only advocates, but also evangelizes. A community that needs to step back if it ever wants to get mainstream acceptance from the industry it wants to save from the “evils of inaccessible wed design”. This community is ours. If you agree we have a communication problem, we need to change the way we bring our message outside of our cloister.

I want to take us on a journey. This journey starts by going back to the foundation of what we call Web accessibility. Forget all that you know about WCAG and just think about what truly matters. What we want is not WCAG 2.0 conformance – conformance is the antithesis of sexy. What we want is for the Web to be accessible. Accessibility can be challenging. Challenges are fun. They make developers tick.

WCAG 2.0 Guidelines

In the intimidating forest that is WCAG 2.0, every success criterion is a huge daunting tree, making it difficult for developers to see the forest. We get so caught up in the details of each success criterion that we forget the ultimate goal of accessibility. By expecting web developers to fully understand WCAG, we forget that in order to be able to grasp the meaning of accessible web design, developers need to start by developing their own critical thinking about accessibility.

We clearly haven’t found the best way to spread the word out yet. By trying to make our message clearer, we made it unappealing for those who don’t spend their lives thinking about digital inclusion. Too much emphasis was put on the WCAG 2.0 success criteria and what they entail, and not enough on what it is we try to achieve. We need to shift our focus.

Most of us already know that WCAG 2.0 guidelines and success criteria are organized around four principles. We know anyone who wants to use the Web needs content that is perceivable, understandable, operable, and robust; but do we really understand what these principles mean? Have we really given enough thoughts to the forest, or have we only been focusing on the trees?

John Foliot describes it best when he says “be specific in what you ask for and generous in what you accept”. What if, instead of beating developers down with the WCAG 2.0 success criteria stick, we taught them to think about the end goals of accessible design? Wouldn’t that be more productive? Wouldn’t it help develop interfaces and content according to the very principles that lay the foundations of WCAG 2.0?

Acc-sexy-ble

Be specific in what you ask for and generous in what you expect. Ask for accessible content, but accept solutions that may differ from your own. Do we really care how developers make their content accessible, as long as it turns out being?

Do we really need to teach the differences between success criteria? Do we really need developers to know each of them by heart? How useful is it for common developers to tell the difference between SC 2.4.4 and SC 2.4.9, as long as they understand that in order to be usable, the purpose of each link needs to be clear?

What if accessibility fostered creativity? What if this newly gained creativity gave birth to new techniques no one has ever thought about? What if accessibility became sexy, challenging, even fun?

Two years ago, we were all about “changing the game plan”, but what have we really done about it since then? Clearly, teaching WCAG 2.0 success criteria for the sake of the success criteria has only resulted in mitigated success. I say we cut developers some slack. By giving them some breathing space and letting them come up with solutions of their own. Let’s stop shoving ours down their throats.

What if we simply tried to teach them to think in terms of accessibility principles and to understand what these principles mean for end users? What if we became guides and started helping developers apply the same critical thinking and creativity to accessibility that they already demonstrate in other aspects of their work? Wouldn’t that leverage our chance of reaching our goals for a more inclusive Web?

Denis Boudreau

Denis is a Web accessibility consultant working for Deque Systems from Montreal, Canada. He has been helping organizations of all sizes build a better, more accessible Web for everyone since 2000.Pragmaticaa11y will be posting on the first Tuesday of every month.  

Download our Essential Guide to Accessibility

6 comments

  • Vincent François Permalink

    My 2 cents (the last ones, as the Bank of Canada is removing them…):

    1. Lets teach the principles and their meaning, with the help of real human users, to the developers and their project managers.

    2. Then – and only then – lets be ready to offer the WCAG (or SGQRI or RGAA or whatever) as the solution to the question thay have to come to at some point : “What do I have to do?”

    The rules, as a solution, should not be presented before the problem is understood by the the sites builders.

    These last years I taught around 900 peoples about Web a11y. In most cases, they got new rules to apply but the need does not came from them: I had to bring them both the solution AND the problem they were supposed to solve with.

    (Sorry for my English)

  • Joanne Lastort Permalink

    In keeping with the forest metaphor, what really we need is to show them the path. Sometimes showing people can make it real for them.

  • dboudreau Permalink

    Yes, I like that idea too. It’s an interesting metaphor to pursue. As long as we’re walking with “them” as opposed to leading them in one specific direction.

Leave a Reply