Welcome to “Pragmatica11y”

I like to think of myself as being a pragmatic. I’m also very passionate about what we affectionately call “a11y”, or accessibility. So it should come as no surprise that when Deque asked me how I wanted to name this new column for our blog, I decided to call it  “pragmatica11y”.

To me, “pragmatic accessibility” means keeping an open mind about different ideas and accepting that there may be more than one solution to a specific challenge. In a world where every accessibility expert has his or her own (often diverging) opinion about the best way to meet a specific success criterion, how are the rest of us supposed to determine what is the best way to achieve accessibility compliance? How can any organization learn to trust our practice and, even more importantly, us as practitioners if we can’t even agree amongst ourselves as to what our best practices are?

I have never believed in one-size-fits-all rules. I am not a big fan of universal or absolute truths either. I believe that in the quickly evolving fields of web development, assistive technology, and accessibility, there can be no such thing as unalterable and permanent facts or techniques.

We need to be able to constantly adapt if we expect to stay on top of our game. Every new release of a screen reader changes our landscape. Every improvement for accessibility in web browsers or updates to HTML5 is likely to consign an otherwise widely accepted accessibility best practice to oblivion. And whether we like or not, understanding and staying on top of WCAG 2.0 is not an easy thing.  I find it a very humbling experience to constantly go back to the standard and read about the success criteria and the underlying techniques. Compliance is just one of those things that takes time and patience. In order to plan accessibility properly, we need to understand what it is we’re dealing with. We need to read the &%@*! manual.

Facts are good. Documented test cases are even better. Opinions often lead to misinformation and misinformation often lead to mistakes. Mistakes in interpretations, mistakes in projects. Mistakes that can be very disheartening and costly for an organization that does it’s best to comply with a set of mandatory requirements. The last thing we need is motivated developers dropping the ball because accessibility seems impossible.

Since most web developers rarely get much farther than reading the success criteria in WCAG 2.0 (when they even go that far), it should come as no surprise that their understanding of what needs to be done is usually off track and inconsistent. What we need is strong test cases that tackle a specific topic, with examples of what works and what doesn’t so we all finally start to get along when it comes to WCAG 2.0 compliance. This is something we’re currently working on internally at Deque and this is no small task.

I certainly don’t have all the answers, but I’m hoping I can get a discussion going in this column with all of you, for the better good of Web accessibility and digital inclusion. And with a little bit of luck, we might even succeed at putting an end to some of the dogmatism and misconceptions we often run into in our field!

So stay tune for a few blog posts here and there on the topic. I’m hoping that in the next few months, we can all learn together, and maybe even align as much as possible to share a common vision of Web accessibility techniques and best practices.

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.Pragmatica11y will be posting on the first Tuesday of every month.