Enterprise-wide accessibility is receiving a lot more attention these days as large organizations work to implement accessible design, development and content practices into their processes. Today, we talk with Denis Boudreau about some of the goals and challenges of these scenarios.
Here’s our latest in our series of AccessU 2013 Speaker Interviews:
Denis Boudreau on Enterprise Accessibility
Feel free to download the podcast:
- m4a format, Interview with Denis Boudreau
- mp3 format, Interview with Denis Boudreau
- .ogg format, Interview with Denis Boudreau
Denis Boudreau transcript
This is the transcript of an interview recorded on April 25th, 2013 between Derek Featherstone, and Denis Boudreau, a long time accessibility professional with a focus on Enterprise Accessibility. It was recorded over Skype and posted as part of John Slatin AccessU 2013 podcast series.
Derek: The word “enterprise” means a lot of things to different people. In this episode, we talk with Denis Boudreau about what Enterprise Accessibility is, the work that he’s done in the past with the Government of Québec, standards, consistency and change. We’re running an entire series of podcast interviews with a number of great speakers for the John Slatin AccessU conference. Coming up May 14th to 16th in Austin, Texas, presented by Knowbility, this is THE conference to go to for in-depth, hands-on, minds-on accessibility training. Check it all out at Knowbility.org. That’s k n o w b i l i t y dot org.
Derek: Hi everybody, this is Derek Featherstone with Simply Accessible. I have a good friend of mine on the line today, Monsieur Denis Boudreau. Denis, how are you?
Denis: I’m very good, yourself?
Derek: I’m doing very well, thanks. It’s fantastic to get a chance to talk to you before you’re headed down to AccessU. It’s coming up May 14th through the 16th and it’s almost here. It’s kind of that last minute preparation and the last push to get people’s slides done and presentations ready and things like that. Are you feeling ready for your talk?
Denis: Things are coming along very well, yes.
Derek: Good, good. We’ll do a couple of things here. Your session is at 2:15 on the 15th and it’s called Cultural Shifts at Enterprise Accessibility. I guess what I’m hoping you can do is that we can take a little bit of time to first introduce yourself to people who may not know who you are or may not be familiar with your work, and then spend a little bit of time talking about the enterprise accessibility side of things.
Maybe you could just give us a quick snapshot overview of who you are and your work in accessibility and what you’ve been doing and how long for, and then we’ll work into the enterprise accessibility side of things.
Denis: Sure. I’ve been working in the field of accessibility since mid-2000, just about. I worked mostly with the Quebec government in the first 10 years of my career as an accessibility professional.
I guess the most significant work I did for them was basically write standards for them so they integrate accessibility in the whole process of the government itself. The government had been wondering about ways to integrate accessibility into what they were doing, so at some point around 2006 they came to me wondering if I could help them figure that out.
We did that. At the time, we were still working with WCAG 1 and WCAG 2 was on the way but it was still something a little shaky back then. We built a standard based on WCAG 1 at the time, and then as WCAG 2 was getting closer and closer to completion, we adapted what we had in order to be on par with WCAG 2 when it came out in 2008.
That standard was adopted in 2011 and since then, they’ve been working at putting these things together to improve the accessibility of the government websites in Quebec.
That’s what I’ve been doing, working mostly until last year when I started working with Deque Systems as a consultant for them, first on a part time basis and now on a full time basis. I’ve been working with them for about 11 months now doing basically the same thing, which is accessibility work, a lot of evaluations, strategic planning, road maps, everything related to improving a client’s strategy or content so it becomes accessible.
Basically that’s what I’m doing. I’m also involved with different W3C working groups. The one I’m mostly involved with is Education and Outreach. I’ve been involved with the Evaluation Task Force a little bit last year also, and the HTML 5 accessibility group about two years ago.
I try to keep a foot in these groups just to stay in contact with what’s going on. That’s basically it.
Derek: Cool. You’ve been doing this for a while and it sounds like you have a lot of experience on the government side, and now you’ve moved into another role where you’re working with different organizations, not necessarily government.
I’m curious I guess to know a little bit more about how that ties into your topic, enterprise accessibility, and I’m just wondering; different people have different understandings of what the word “enterprise” means and how it relates to accessibility. In the context of your talk, what do you actually mean by enterprise accessibility?
Denis: The first thing I need to say is that it’s not related to Star Trek in any way. Enterprise in the sense of organization, so businesses, companies, larger groups that need to get their processes together so it works consistently amongst different teams, for instance.
My focus on this basically comes again from the government where the different departments obviously have different teams. These teams don’t talk to each other within the same organization, and within different organizations they talk even less.
People, developers mostly, are usually left by themselves to do whatever it is they need to do, and they can’t always have access to other people to discuss with so they can share the good things that they create or maybe find tips and tricks that could help them do their work better.
I’ve always been concerned about that because as somebody who was coming in these organizations to help them, I kept finding the same problems all the time; people would make the same mistakes all the time and everybody was trying to reinvent the wheel all the time. Nobody really was able to take advantage of the knowledge of the organization itself because everybody was scattered in their own little corner doing their things.
One of the problems that came out of this also was that I was getting fed up being called at the last minute on a project, being told that people were going to deliver or launch a website in two weeks and that they needed somebody to assess their website to make sure it was accessible.
Of course, as you know, when you’re called at the last minute like this, the only thing you can do is see how many errors they made and you can’t help but notice that if they had known about these things earlier, they would have avoided these mistakes all together.
Because of this, having to all the time go back to these same problems with different people all the time, I started thinking about a way to make sure that at every step of their process they wouldn’t forget about accessibility. That meant making sure that designers, for instance, would know about color contrasts or that information architects would know about different things when it comes to thinking about the interaction of the different elements that they’re building for the website that they’re building.
Making sure that everybody who has something to do or say about the development of a project would have accessibility in mind when they did that. With my colleagues back then I ended up breaking down the lifecycle, the production chain, into about nine or 10 different roles that were general roles that would define everything that is being done into that process.
We ended up calling that the Role Based Responsibility Breakdown for accessibility, something that we built at the time for the government so that it would help them not forget about accessibility at every stage of their process. Then, I ended up bringing that into the Education and Outreach working group also, so that we can build this at the W3C level in a way that helps organizations around the world take advantage of this process so it helps them better integrate accessibility.
In a case like this presentation I’ll be doing, the class I’ll be teaching at AccessU, there’s a little bit of that in there. Not so much because I’ve talked about that in the past so I wanted to do something different, but at the same time it’s still a foundation for the message I have to convey in accessibility or what I feel I have to convey in accessibility at this point in my life. It becomes the foundation for a lot of things to me.
In this case, what I’m really interested in is looking at how an organization handles accessibility internally. Part of it is figuring out how to break down the responsibilities amongst every stakeholder, and then also thinking about how people interpret the accessibility guidelines so we end up with consistency within the organization.
If you have different teams working on different projects or different parts of the project and these teams have very different levels of expertise when it comes to accessibility, obviously the end result will be shaky at best. You want to make sure that people understand things in a way that is similar and that the results are ultimately pretty much the same, and hopefully they’re good.
A lot of the discussions that I’ve been part of in the past few months have been based around this idea of what is a real WCAG violation is as opposed to what is actually a best practice in accessibility. A lot of my work is related to doing assessments for clients, and I do that in a team of anywhere between six and 10 people who might be working on the same project as I am, or I might be working on the same project as they are, and we ultimately deliver reports that are for different parts of their website, so we want to make sure that there is consistency in what we’re doing.
If I call out on an issue and my colleague doesn’t call it for the similar page, then it becomes weird for our client because they don’t see the consistency that’s there. That was a problem on the inside for us. I had noticed that is a problem in most organizations that I’ve been working in, not from an evaluator’s perspective but from a developer’s perspective.
If somebody feels, for instance, that when they’re doing form elements they really, really need to have labels with a FOR attribute and then an input with an idea attribute, then that’s one thing. If somebody else believes that only providing a title attribute on the input is sufficient, then we have two very different ways of doing it and we don’t get the same benefits from using one or the other.
The third developer might come in and say, “No, I prefer to use ARIA.” Then he would say, “I’m not using title, I’m using ARIA Labels instead.”
These are all ways that are sufficient to do something, but it’s still not consistent in the way that things are being developed. When the fourth developer comes in and tries to adapt to this new environment where people who are already working in it, then it becomes difficult for him or her to really dive in and be comfortable quickly. It takes time for them to adjust.
I’ve done that a lot of times in the past in training where I would take a success criterion like 1.3.1, for instance, and I would have a group of 10 or 12 people in front of me, and asking them to write down what that meant and I would every time get very different answers. If I had 12 people, I usually would get 12 different answers to explain that same thing.
That relates a lot to what I’m saying about different interpretations ending up with different results, ultimately. Trying to build a common understanding through that class with the people who will be there about what really is a best practice, what works, what doesn’t work as well. That’s the kind of thing that we’ll be covering.
Derek: That sounds like it’s a really useful exercise. I’m curious, and you even mentioned this in your session description, we’re talking about a group of people who if you’re thinking about an organization, all the developers and the designers and all the other stakeholders are not experts.
You’ve even said in your description that one of the things that is really quite a significant challenge is that even people who are well known as accessibility experts and have loads and loads of experience and years or working with people with disabilities, even they disagree on having consistent methodologies and best practices.
I guess I’m curious to know what kinds of challenges that poses when you’re working with large organizations when you’re trying to get some of that consistency, partly because I think you said that in 2006 you were working with the government and you were working with WCAG 1. WCAG 2 became a standard in 2008, yet that wasn’t adopted fully until 2011, a full three years later.
That really surprised me when I heard you say that. What’s the challenge there? Why did it take three years to have that accepted as the new internal standard? How do organizations deal with that? Is that something that you can help them address via some of the things that are happening in your session?
Denis: In a way. To answer your first question, the reason why it took so long to get adopted basically is just government processes taking time to go through. I was co-chairing a group of 25 people who were coming from 25 different organizations where they’re to build the standard with us, but were also there to defend their turf if need be.
For example, if people were working with statistics a lot then they would be concerned about data tables and HTML, because that’s obviously a big chunk of it if you need to provide accessible tables when you have loads of data to put into one table. They would be worried about these things.
Other people who would be creating video would be worried about captioning, for instance. Everybody came with their own concerns, and ultimately it becomes dealing with a group of people who all have their own agenda, but also share a common goal of inclusion and also share a common goal of wanting to create the best experience possible because everybody’s proud of their work.
Everybody was coming in with their concern, and then going through everything that the standards include; having reviews, treating comments, doing everything that needs to be done so everybody’s on par and we reach a consensus on everything took some time.
We were meeting once a month, about eight times a year, for full day sessions, sometimes two day sessions. It took some time to do that. Once that was done, then the document left our hands and went to the lawyers who would re-write everything so it became acceptable from a government perspective. Re-writing that and then sending it back to us so we can validate that it still means the same thing took some time, as well.
While this was being done, the government organizations were actually creating websites already. Most of them knew about these things, so people would follow the standards on the draft versions, pretty much like we’ve all been doing when we started playing with HTML 5.
Some of the things that were in there back then didn’t make it to the last version that we have, so when you play with cutting edge technology or really new standards, you have to accept the fact that things might change along the way. That’s basically what people were doing.
Back in 2009, these standards became an official best practice with the government, so that meant that people had to follow these things. They also had to understand that they weren’t playing by the rules, which meant that some things might change along the way.
Derek: It sounds like consensus is an important piece, but it’s also one of the most challenging pieces. We’ve seen things before where somebody will ultimately make a decision on best practice for somebody rather than building that by consensus. That has been successful.
I guess there are other cases where building consensus has been successful. How important do you think that consensus building is in terms of enterprise accessibility and having people integrate things into a process to ultimately end up with a process that ends up turning out more accessible products?
Denis: I think consensus gets you buy-in, in general. What you really want when you have to deal with an organization that either doesn’t know it’s about accessibility or doesn’t care as much as you’d like them to, you need to find ways for them to feel like they’re part of something; that they’re creating something that will be better. That’s buy-in in general.
Consensus is really important for that, if anything else. In our case, with that experience I was talking about with these 25 people, they were the champions in their organization for accessibility. If for some reason I wasn’t able to convince them that we were doing the right thing, then there was no way in hell that they would go back to their organization and sell this to their people.
In order to get 25 organizations to start moving in the same direction, you need to make sure that the 25 representatives of these organizations all agree on the same thing or are at least okay with the decision because not everybody agrees with everything all the time, obviously.
Making sure that you get that approval from everybody and that people understand why they’re making these decisions and why we’re going into a specific direction makes all the difference, I think, in making them move towards the goal that the bigger organization has set for them. In this case, the government is saying, “We go for accessibility.” The different organizations are having to find a way to achieve that goal.
Derek: Right, I think that makes perfect sense. I don’t think it’s always going to be easy to do that.
Denis: Actually, it never is.
Derek: One of the things that I noticed in your session description is a statement, and I’m just going to read it here. “This session will begin by demonstrating how accessibility standards can be filtered into a series of simple, straightforward, and easy to implement requirements that can help organizations tackle web accessibility more efficiently.”
That sounds pretty good. I’m really interested in the “easy to implement requirements” part of that. I think we’ve seen this in a lot of our work and you maybe have in some of your work, as well. “Easy to implement requirements” is not necessarily a phrase that rings true for many projects.
Can you give us maybe a sneak peek into what you mean by “easy to implement requirements” and scenarios where maybe it doesn’t naturally seem like this is going to be an easy to implement thing?
An example of this would be going back to what I was saying about 1.3.1 earlier where you have different people understanding different things based on a rather vague guideline to begin with or success criterion in this case.
Easy to implement would mean in something like this to go back to the techniques, which nobody ever does, analyze what the intent behind these techniques is, and then instead of referencing so many different techniques for success criterion, talk about what these intents are.
Whether it’s structure, semantics, using proper mark up to convey the information, different things related to forms to tables to headings to lists to block quotes or whatever, extracting from the success criterion the intent that’s behind the techniques that describe it, and use that as a mean to understand what that success criterion actually means.
I’m starting to think more and more that instead of teaching people about accessibility by either using those techniques or just talking in general about the success criteria and what they mean, there needs to be some analysis of the intent that are in those techniques first, and use that as a mean to explain the success criterion and then use all the success criterion in a specific guideline to talk about that guideline, and use those guidelines and talk about the principle.
Get to the point where we teach accessibility by talking about the principles mostly. If somebody really, really, really wants to go into the technical details, then eventually they’ll find the techniques on their own. Not referring to these techniques as the solution to implement a success criterion, but rather talk about the intent behind it.
Developers are creative, so they will always come up with interesting ways to create something; not always the best thing for accessibility, but it can be if they understand what’s expected for accessibility. I’m thinking more and more that if we teach them about that intent and we leave them to do things on their own afterwards, then they can create new ways to do this, ways that work, ways that are inclusive, and ways that can eventually become new techniques for our techniques documents.
It describes a little bit what I’ll be doing with this, and it also ties in with the idea of role based. In some way they connect together, but it’s a long term project that is not finished. I’m using that as a foundation, but it’s always a moving target.
Derek: That sounds good. I think that’s one of the important things about this is that it is a moving target and the techniques documents are written in such a way that they’re very clear and they state up front that these techniques documents will continue to evolve as new techniques are invented and people come up with creative ways of solving problems, that new techniques will be added and will continue to evolve.
It’s a fine balance, I think, because we’re looking at a scenario where you have people who want to make things accessible and they want very specific guidance, and that’s a fine line to walk between giving them the principles and focusing on principle based teaching versus focusing on techniques based teaching.
I think one of the things that we need to recognize, and I’m sure you’ve found this in your work and on your own, but also with the Education and Outreach working group, is you need to have a good balance between both principle based discussions and techniques based discussions in order to make sure that people are really, truly actually getting it. I think that’s a fine line to walk, there.
I think your session will be really interesting. You have a full three and a quarter hours, so I’m sure people will get a lot out of it. That sounds fantastic.
I have one final question for you, and then we’ll call it a day. You’re going to be in Austin, there are lots of people coming to AccessU who are not from Austin and you’ve been to Austin many times. What is your favorite thing to do or place to go or food to eat while you’re in Austin?
Denis: I did go to Austin a few times already. Unfortunately, most of the times it’s for conventions like SXSW or for AccessU, so I get there and then I leave right after to go back to my family.
I never get to visit so much, but one of the things that I did last year was the Alamo Draft House movie theater, which was really cool because to me that was a totally new experience. In Montreal, movie theaters are rather boring, I’d say. You get your food at the food counters and then you get into the room where they’re playing the movie and then if you want something else, then you’ll be missing a part of the movie because they won’t pause it for you, obviously.
At the Alamo Draft House, they have these waiters that are always there for you and will go into the rows pretty much like when you’re going to a bar and you can order whatever you want, including beer, which is cool.
Last year I ended up going to The Avengers at that theater. Instead of showing us the same previews that every theater shows, they’re putting up some freak show before the main event where they have people who brought in either footage that they made themselves or things that come from vintage footage from years before. They present you these things.
It really creates an atmosphere that’s very special, and also this is a place where some of my favorite bands when I was a teenager have played. Bands like Minor Threat, Circle Jerks, and stuff like that. I’m pretty sure most people won’t know what these bands are, but punk rock bands from the ’80s. Just knowing that I was in the same building as these guys were 30 years ago is rather cool.
Derek: That is cool. The Alamo Draft House is definitely a huge part of Austin, and it’s quite an experience. If you’re coming to AccessU and you haven’t been there and you get a chance to go, it’s really quite something. It’s definitely a pleasure to catch a movie there.
Have a great AccessU, Denis. Sorry I won’t see you there, but I know you’ll have a blast. It sounds like your class will be fantastic. Thank you so much for taking the time with us today.
Denis: Thank you very much for putting me on your list.
Derek: Absolutely, I wouldn’t have it any other way.
Derek: Again, that was Denis Boudreau, one of the speakers at the upcoming up John Slatin AccessU conference. Get all the details at knowbility.org
– that’s k n o w b i l i t y dot org.