What AccessU is all about: Sharron Rush

Feel free to download the podcast:

• m4a format, Interview with Sharron Rush
• mp3 format, Interview with Sharron Rush
• .ogg format, Interview with Sharron Rush

And, be sure to check out AccessU at Your Desk this year!

Transcript

Interview Summary

Derek:What can technology professionals learn from the Arts? In our final interview before AccessU, we talk with Sharron Rush, Executive Director of Knowbility about the parallels between inclusion in the Arts and Technology. Sharron also shares some exciting news about next week’s AccessU.
Presented by Knowbility, May 14th to 16th 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.

[Intro Music]

Derek: Hey everybody, this is Derek Featherstone with Simply Accessible. We are winding up our series of interviews leading up to AccessU. AccessU is May 14^th to 16^th in Austin, Texas. That’s coming up real soon. That is hosted and presented by a wonderful organization based in Austin called Knowbility.

I have with me on the line today Sharron Rush of Knowbility. Sharron, how are you doing?

Sharron: Hi, Derek. I’m great. How are you?

Derek: I’m doing very well, thanks. I’m excited that the time of year is almost here when everybody kind of descends on Austin to get the very best in accessibility training. I love this event and I know you do, too. It’s something that all of us who get involved with AccessU are very passionate about.

Maybe what you could do for the wonderful listeners out there is just tell us a little bit about who you are, what your role is with Knowbility, and tell us maybe in a few words what your grand vision for AccessU is; why does AccessU even exist? Maybe just an intro to you and then to the event.

Sharron: Okay. Let me say first, we’re going to miss you, Derek. I understand you have good reason, new kiddo, to stay home, but we’re going to miss you and really appreciate the fact that you’re sending so many of your gang from Simply Accessible to be with us in Austin.

My name is Sharron Rush, as Derek said. I’m the Executive Director of a nonprofit group based in Austin called Knowbility. We spell it with a K not to confuse people, but to make the connection between knowledge and ability and that’s what we’re all about. We’re all about where community meets technology meets disability and using the technology to make sure that people with disabilities have equal access to the communication technologies that we all love and use every day.

We started Knowbility in 1998 to highlight the fact that technologies were evolving and there was a strong risk that people were going to be left behind because people didn’t think about accessibility in their design. We decided that what would be a good thing would be to raise awareness of that, because most developers don’t sit down and say, “Hey, I’m going to lock all the blind people out of my website.” What happens is they just don’t think about it.

To raise awareness, we started a web design contest called The Accessibility Internet Rally. We like to think of it as one of the very first hack-a-thons. What we did was train people about accessibility, what it is, what it means, and how to do it. From that, people started saying, “Boy, that training was really useful. You only have a contest once a year. Could we get the training somehow?”

We started providing classes. John Slatin, the late Dr. John Slatin, who was a dear friend and a mentor to so many of us who care about accessibility, was at the University of Texas here in Austin. Glenda Sims and John Slatin and I sat in his office one day and just moved little sticky notes around on a white board and said, “Well, we’d want to teach people this and that and the other.”

In 2000 we did the first one. We’ve done AccessU now in California several times, but most often we do it in May at St. Edward’s University in between their semesters. We just invite the best and brightest minds to come share what they know and invite people who need to learn about this to come and have a submersion experience and learn all about it. We try to do it before Austin gets too hot, and we even had some rain this year so everything’s green and lovely.

Derek: Wow, that sounds pretty cool. I actually wish I was going to be there to see the green. I think it’s been very brown most of the times that I’ve been there in May.

It is a really wonderful conference. I think you invited me back in 2005 for the first time, and I’ve taught at several events. It really is an amazing experience to see everybody coming together.

Not being able to be there this year, it’s been really kind of wonderful to have the chance to talk to so many different speakers and just get that reminder of all the different perspectives on accessibility. We quite often think and we look at things from our own perspective, so I look at most of accessibility from a design or development perspective, but there are all kinds of other perspectives.

Lainey will be talking about the legal side of things, of course, and there will be people talking about document accessibility and people looking at even things like the policy side of things.

That’s, I think, one of the beautiful parts about AccessU is that it brings together not just one perspective, but all different perspectives. How appropriate is that for an accessibility conference, right?

One of the things that you do, and I know that having been there several times there’s an incredible focus on the arts and on making the arts accessible to everyone because we believe, I think in a lot of ways, that a really well rounded person gets that education, gets that experience in the arts and in other pieces that aren’t necessarily looked highly upon in society. The arts are really a critical piece to making a whole person, I believe.

You’ve really embraced the arts as part of AccessU and ensuring that everything is accessible so that people can have accessible experiences with the Arts. Can you talk a little bit more about some of the events that are happening as part of AccessU and some of the things that you do to help encourage accessibility and the Arts together?

Sharron: I would be so happy to talk about that. I think it’s one of the things that really sets AccessU apart. We do have a really holistic look at accessibility and just the whole experience of technology.

If you think about the way that technology empowers people, it’s not simply a matter of working or learning, which those are so important and we certainly emphasize those, but look at all the ways that we now get our music online and we share videos and we share these artistic experiences. Austin kind of prides itself on being a creative place, a creative city, and of course South by Southwest (SXSW) is one great example where all these creative folks come together.

In doing AccessU, we’re always real pleased to partner with a sister disability organization called VSA Arts. VSA to the Arts is what Knowbility is to technology. It really is an empowering organization.

We worked with them to do performance – on Tuesday nights, that’s the night when everybody is going to be there, whether they’re just going for Tuesday or Wednesday, most of the people are there on Tuesday night. We try to do some kind of arts exhibit or art show.

One year we did a movie at the Alamo Draft House which you might recall, Derek. You can get beer and a meal and watch a movie and we had audio description and captioning for the film that we showed. We passed the equipment around and people go to see what it was like to go to the movies with audio description.

One year, and I remember you were at that one because I think it kind of took the top of your head off when we did the “Sight, Sound, Soul” show with Henry Butler, a jazz pianist. Henry’s playing his jazz and we had a painter kind of paint the music so that if someone was deaf they could see this expressive piece of art take shape while Henry was playing. The whole thing was captioned and audio described and ASL interpreted.

Last year we did a dueling piano thing where everybody went down to 6^th Street and we had kind of the live piano, but also the ASL interpretation. At the end the pianists asked the interpreters if they wouldn’t think about becoming part of the band because they thought it enhanced the experience so much.

It’s just like that in the arts, the same way it is in every other aspect of disability and accessibility that I know about. When you start providing access in these different ways, you think you’re targeting a particular group of people, but then everyone has a broader ability to experience whatever it is. Whether it’s getting into the building by opening the automatic door, or watching a movie while listening to it being described, you get another dimension to the experience.

When you include people with disabilities, you’re also broadening the experience for everyone. This year I’m so excited. There was a series of dances that was put on the University of Texas co-op from student choreographers and student directors. They got to do their final show, and we saw one in March called “The Way You Move Your Body.” It was mixed ability dancers.

They have dancers in wheelchairs and not in wheelchairs and blind dancers and deaf dancers who experience the music very differently, as well as fully able bodied dancers in this group experience. It’s just remarkable. It’s called “The Way You Move Your Body,” and the part that was missing is they didn’t have audio description, and they didn’t have the ASL interpretation for the narrative part of the dance.

We’ve worked with Lotus Signs to do the ASL and with VSA to do the audio description, so we think that we’re going to have an even richer experience on Tuesday night this year. “The Way You Move Your Body,” and it’s going to be at the conference hotel, so everyone who’s staying there of course, so even the people who are in town, it will be very close for them to get there. Last year we had some problems with people finding parking downtown.

We’re very excited. We’re turning this hotel ballroom into a dance studio. I can’t wait for that one. I think it’s going to be terrific.

Derek: What a wonderful event. That sounds magnificent, really. I do remember Henry Butler and the “Sight, Sound, Soul” performance. I remember feeling the goose bumps, literally feeling goose bumps as this complete experience was created and crafted around this one location.

I can’t imagine how much fun it would be to see this dance routine on Tuesday night. It really does sound wonderful. It sounds like you’ve done it again and really put a wonderful event for people not just to experience the arts, but to —one of the things that you said, Sharron, is that we look at creating a more inclusive experience in say the arts, and it enhances things for everybody. I love the parallel between what you’re seeing in that scenario and what we do in the digital space. I think that’s really important for people to see that these principles of inclusion and accessibility to all types of different communication and information and any type of material like that, I’d love for people to see that relationship between what they see and experience in the real world and how that translates to their world of creating accessible and inclusive digital experiences.

Sharron: I remember when we did the “Sight, Sound, Soul” there at the Palm Door. I’ll probably never forget. You just got so, I thought you were going to jump out of your skin. You said, “We should always have events like this.”

That was really affirming to me because I think, “Oh, am I just kind of wandering down this pathway into the arts because I think it’s cool?” Just to see how people’s understanding of accessibility is transformed through those kinds of, not that your perception needed transforming, but just to have it deepened and broadened. It’s fun and it’s really exciting.

I think you can’t really draw a line between that’s art and this is technology or that’s life and this is art because those things support and extend each other so much in terms of we are able to make the technology or the art experience so much more rich now because of technology. It’s technology that allows that to happen.

Going through an art exhibit with a headphone now and to be able to hear these things described, so many museums are doing audio description in their art tours not just for sighted users, but also for blind users to say, “Here’s what it looks like. Here’s what the history of it is.” The technology is so empowering in that way.

I think for those of us who work mostly in technology, to remember how it’s used. I think you talked to Whitney Quesenbery, didn’t you already?

To keep the user in mind and understand that people bring so many different experiences and expectations to the world of technology and that we have the capability to meet so many of those needs, and in ways that we sometimes don’t even know. We can’t even imagine.

It’s a very exciting field.

Derek: It is, and that’s the beauty to me of getting all these ideas and all these different people together to create something new. We create new meaning from the experiences that we have together.

I know I feel that every time that I’m down there in Austin and I experience something new. I feel enriched, I feel connected, and I feel like we’ve been able to just through interaction and talking through different things that we’re struggling with, that we’re succeeding with, that make some other piece or some portion of the world more accessible. I feel pretty fantastic every time it happens.

I think that’s just a testament to the type of environment that you’ve created there, Sharron. Huge thanks to you for everything that you’ve done for putting on this type of event and for everything else that you’ve done not just for Knowbility but for accessibility in general.

Sharron: Thanks, Derek. I very much appreciate that. Accessibility is one of those things where it is so much not a solo act. I feel so fortunate to be in the community of people that I’m in.

A couple of years ago we submitted a panel idea to South by Southwest called “Accessibility: the Musical.” We talked kind of about this, the fact that you can make the arts experiences so much more accessible because of technology and trying to get the technologists who attend to think about things like captioning and audio description and just the accessibility of the arts experience and really helping people to understand what they need to do to make it most broadly accessible.

We tried to make the thing. I had people from VSA and one of the ASL interpreters. I had a deaf panelist and Desiree who’s a blind woman and a great musician.

We kind of tried to give as many examples as possible, and then we actually got the audience to sing with us with bouncing ball karaoke that was accessible to the blind that Desiree had showed off and all that. At the end, James Craig who you know James from Apple, who used to live in Austin and was an early participant in AIR. James said, “Now if we made accessibility this much fun all the time, we wouldn’t have nearly the resistance that we have.”

I think that’s our goal. That’s always our goal here at Knowbility is that we try to let people see the creative, empowering, fun side of it. We all know there are enough really naughty problems that we have to solve. Sometimes I think it’s just good to be reminded. There’s this extra bonus of creativity and access to things that you might not have anticipated or expected that make it really, just that feeling that you just described of joyful accomplishment.

Derek: It really is. The unintended consequences, that knock on effect that when you see something that you’ve facilitated or created and having this wonderful effect in a way that just wasn’t anticipated at all is really kind of an amazing experience.

It’s coming down to the deadline. It’s really a week from today. We’re recording this on Tuesday, May 7^th and it starts next Tuesday. I know we’ve been doing these podcasts for a little while and we’ve been releasing them for a while. Hopefully people have already signed up.

I know it’s getting a little late for making arrangements to get to Austin. The last minute flights aren’t always easy to come by and making changes in plans is quite often difficult.

I know you mentioned briefly to me sort of offline that you have sort of a special, secret surprise for people who aren’t going to be able to make it there, even if they want to. They can’t go and experience the full three days of wonder that is John Slatin AccessU. Can you tell us a little bit about the secret?

Sharron: The secret is we weren’t sure we could pull it off. Last year at AccessU, our friends at Environments for Humans, Ari and Chris, put together an AccessU Summit so that people who couldn’t attend in person could attend from their desk.

This year Ari and Chris were already booked, and so the question was are we going to be able to broadcast the way that they did? We just weren’t at all sure that we would have the bandwidth, that we’d be able to organize with all the other organizing that we were doing.

We put out a survey a couple of weeks ago and said, “If we were able to do it, what would be of most interest and value for a very short day, just six one hour classes?”

Most of the classes at AccessU are either an hour and a half or three hours. We do try to get people to go in depth, and then we have an all day post conference session. This year Molly’s doing one on CSS of course, Henny Swan is going to do mobile accessibility, which there’s a lot of interest in. Then Karl, your own Karl, is doing the forms, an in depth look at how to make accessible forms.

There’s so much depth to those that there’s no way that we are able to really offer that. What we did say is on Wednesday the 15^th, we put together six classes based on the voting that we put out there on SurveyMonkey. I have the list here.

The first one will be Strategic Accessibility. Jeff Kline is going to talk about it. He manages accessibility for the Department of Information Resources here in the state of Texas for all the statewide agencies. This is a strategic look based on his book.

You mentioned the fact that there was a lot of interest. This one and the mobile accessibility clinic were the two that got the highest number of votes. Strategy and mobile were the ones that people voted for the most.

The mobile accessibility clinic is going to be Henny Swan and Paul Adam, basically solving problems and answering questions. We’re not going to do the teaching like we do in the post conference, but it’s going to be people who attend will be able to bring their questions to Henny and Paul to do a real time problem solving.

We’re also going to walk through the resources of the Web Accessibility Initiative at the W3C. Just a walk through what’s there. They’ve done a lot of work this year in trying to make some tutorials available. They have a before and after demo. There’s a lot of new stuff there besides all the ARIA work. We’ll show that off.

There’s an hour on open source tools, and hour with Whitney Quesenbery on usability testing, and then Susann Keohane of IBM accessibility is going to talk about integrating accessibility in Agile development scenarios. Those were our top vote getters.

We’re going to put those six online on Wednesday. I think the registration for that should be open tomorrow on the website. Of course, anybody who’s attending, if they especially wanted to come in to the site because it’s all going to be onsite at AccessU, people can also sit in and take those classes in if they wish.

Derek: Brilliant. It sounds like you have some options for everyone, for the people who get the chance to get down there or up there, I guess depending on where you are; get to Austin to see it firsthand. They have a huge range of classes to choose from, but it sounds like you’ve picked six absolute winners in terms of doing this as an AccessU at your desk. That sounds really wonderful.

We’ll make sure that when you get the link for the registration, let us know and we’ll make sure that we post that as part of the transcript and as part of the show notes.

Sharron: Okay, sure.

Derek: So that people can get to that directly. That sounds really fantastic. We’ll definitely highlight that.

Is there anything else that you want to share with us, Sharron, or let people out there know about Knowbility or about the conference?

Sharron: I guess I would just remind people that we do AccessU and we do the Accessibility Internet Rally, AIR. We transformed AIR last year. It had always been a city based competition, so we would do eight hours of development for nonprofit organizations. Teams would get together and do that.

It got to be increasingly difficult to do everything that people needed to do in eight hours. When we started doing AIR, it was really very simple sites that nonprofit organizations need. Nonprofits, too, have gotten more sophisticated in what they need. People want to learn more about the advanced techniques.

I would encourage people who can’t get here and can’t take this training to look into participating in Open AIR. Rich Schwerdtfeger who leads the development of ARIA at the W3C; he’s also the CTO for accessibility for IBM. He is the Chair of that Open AIR competition and he’s really opened it up so that people can participate wherever they are, from all over the world, learn about accessibility, and then donate some time to develop a website for a nonprofit organization.

It’s a good way to get training, also to get practical experience actually applying the training that you get, and then to get the feedback from the judges about how well you’ve accomplished what you wanted to accomplish. That’s a great way to get training, as well.

We have AIR and we have AccessU, but Knowbility trains all the time. That’s a big part of what we do. If anybody out there can’t get to AccessU, doesn’t really think they can participate in AIR, and just needs training, I would encourage them to join in and be part of the Knowbility community. Let us help you figure out what you need.

I think the fact that we train in the way that we do where we pull in people like Simply Accessible and St. Edward’s University, you don’t very often find people who know everything, other than you, Derek, of course.

Derek: You’re too kind.

Sharron: We try to be a resource for connecting people to the exact expertise and kind of help that they might need in their accessibility journeys. It’s always a journey. We try to give people what they need and help them have some fun along the way. AccessU is a big part of it.

It’s been interesting as the podcasts have gone out, it’s hard to tell, but registration keeps coming. It looks like we have a capacity at St. Ed’s; it’s a small university. It’s a lovely and very small university, but we’re getting close to capacity now. I think this was a really good idea to let people know a little bit more about what’s going on, what happens there when you get there, what is AccessU all about. It’s been really great.

Also, we’re always here. Call if you have any questions about what to expect and especially if you have any access needs yourself. Just give us a call. Me or Kim or somebody will be here to answer your questions and make sure you get what you need. That’s our mission.

Derek: A wonderful mission it is, Sharron. Absolutely wonderful to talk with you. It doesn’t happen nearly enough. Thank you so much for taking the time today. I think this was really fantastic.

We’ll get this posted on the website right away. Thanks again for all that you do, but also for all the things that you inspire other people to do. I think that’s a huge part of this.

Thanks again. I can’t wait to see you in person again.

Sharron: I know. It’ll be great to see you. Thanks for everything.

Derek: Thank you, Sharron.

Sharron: Great to be here. Bye.

Derek: Bye.

Derek:If you haven’t met Sharron Rush yet, you simply must. Register now for AccessU or find out more about all of Knowbility’s great programs at knowbility.org
– that’s k n o w b i l i t y dot org.

[Outro Music]

Most people are familiar with that old idiom of the carrot and the stick, where there are two methods that can be used to affect change. With the carrot, you use positive motivation and psychological or physical incentives to encourage a person or an organization to adopt a new behavior. And, with the stick, you use negative motivation to reinforce the unwelcome consequences of undesirable behavior. Both methods work, and one tactic is to use them as a combined approach. However, for a lot of people, the desire to increase awareness about accessibility often raises difficult questions. How much does one use the carrot, and how much does one use the stick?

Over the last several years, there’s been a growing amount of significant milestones in legislation to ensure equal access to web content for individuals with disabilities. And, as an advocate who worked within corporate America for years making the business case for accessibility, I’ve often referenced some of those landmark lawsuits as cautionary tales. So, I confess, I used to lead with the stick, and then I’d follow up with a lot of carrots to make the case. But, I ask you, do we always need the stick? Is it possible to affect major change and to see a full cultural shift in individuals or organizations, just by promoting all of the benefits that one gets from inclusive design?

Let’s consider Japan. Many people hold that Japan is one of the most accessible and inclusive countries in the world. With Braille support and wheelchair accommodations prevalent in every major city, inclusive and people-centered design seems to be a way of life in Japan. Likewise, thanks in large part to the incredible efforts of accessibility advocates like Makoto Ueki at Infoaxia, Tokyo has benefited from as many as FIVE accessibility unconferences in about a year and a half. These accessibility camps provide a welcoming and approachable space where people can discuss everything from disability rights to accommodation needs to HTML5 and ARIA techniques. And, it’s all free and open to the public. Each time they host an Accessibility Camp Tokyo, their numbers grow. Makoto is now helping to support the first Accessibility Camp Seoul.

When I asked him about Japan’s perceptions about accessibility, Makoto once told me that several major companies were making concentrated efforts to improve the accessibility of their websites, but unlike many corporate organizations in the United States, “the motivation behind their efforts comes from CSR and/or customer satisfaction.” Makoto said that when Mike Paciello visited Japan in 2002, he once remarked to Makoto that Japan clearly had “accommodation in mind in general.” However, all of this, and there’s no stick, no litigation risk for companies. Japan has no official legislation that governs web accessibility. Instead, they have a set of standards, JIS X 8341 Web Content (Japan Industrial Standard), which provides guidelines for accessible design and development. This is a movement towards best practices and standards, though, not an enforcement.

So, as we’re thinking globally today about accessibility awareness, I’d like to encourage you to look for new ways to achieve success. In this season of responsive and mobile-first design trends, let’s try to cultivate an attitude of “mindful accommodation” with carrots instead of sticks. Who knows? We might just get more allies than we expect.

While reading about all the different ways that people are celebrating Global Accessibility Awareness Day (GAAD) this year, I came across a case study from Samoa conducted a few years ago and their efforts to create a model to provide inclusive education for children with disabilities. After findings from a survey conducted by the Samoa Ministry of Education, Sport and Culture uncovered issues with segregation, lack of equality in education, and even higher mortality rates for children with disabilities in Samoa, a sub-project was formed to address these problems. The strategic plan prioritized two key principles:

• Every child has a right to an education, and
• The education system has to change to include a broader range of abilities and learning needs.

The Samoa team presented the results of this case study in 2009 as a part of the Pacific Regional Initiative for the Development of Basic Education (PRIDE) Conference. Through this case study, they demonstrated a sustainable system to provide inclusive education for Samoan children with disabilities. What were some of the important discoveries from the case study?

• Too few students were integrated into village schools.
• There was a lack of referral information and resources available to families.
• Teachers weren’t properly equipped to facilitate inclusive education practices.
• There was limited access to information about children with disabilities.
• Some of the basic access needs for children with disabilities were missing, including ramp gradients, railings, and appropriate door widths.
• Even those who were responsible for developing inclusive education practices displayed negative attitudes.

I think it’s significant and worth mentioning this case study today as we kick off GAAD 2013. I know it’s about children and education, and it’s set in a part of the world that most of us don’t really have on our regular travel routes. But, it doesn’t really matter whether we’re discussing children or adults; it doesn’t matter whether we’re talking about access in Samoa or in your own country: accessibility is the same everywhere you go. The drivers are planted firmly in the conviction that inclusion is a human right, and the challenges all center on a lack of awareness, education, resources, and process. Sound familiar?

What did the Samoa team do to overcome these challenges?

• Get leadership (at the national level) to support their efforts.
• Establish standardized design guidelines.
• Create a publicity and marketing plan to increase awareness and education about disabilities.
• Capture the success stories and share them so that a sustainable long-term system could be built.

Again, does this sound familiar? To me, it reads a lot like the case studies that you may have encountered, where champions for change within an organization outline their steps for success. Heck, it reads a lot like presentations I’ve given about my own experiences in advocacy. So, as you’re thinking about accessibility awareness and global or local change, remember this. We are not alone in this struggle for inclusion. And, while our experiences aren’t necessarily unique, that doesn’t make them any less important. Quite the contrary, we should learn from shared stories and build on the same principles to achieve our bigger goals. Get buy-in at the highest level you can, establish some standard guidelines, and (this is my interpretation) be loud and joyful about your efforts.

Case study article: Making education inclusive of children with disabilities in Samoa

Web Accessibility and Gamification with Glenda Sims

Feel free to download the podcast:

• m4a format, Interview with Glenda Sims
• mp3 format, Interview with Glenda Sims
• .ogg format, Interview with Glenda Sims

Transcript

Interview Summary

Derek: Today we talk about the accessibility family, the tools that people use to produce web content, gamification and addiction — all tied together by Glenda the Goodwitch Sims. She’s teaching classes on DreamWeaver Accessibility and will talk about how accessibility is broken in her classes as part of next week’s John Slatin AccessU in Austin, Texas. Presented by Knowbility, May 14th to 16th, 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.

[Intro Music]

Derek: Hey everybody, this is Derek Featherstone with Simply Accessible. We are here today with Glenda Sims talking about the upcoming AccessU conference in Austin, Texas May 14^th to 16^th.

We’re going to talk a little bit about the conference today and a little bit more about Glenda and talk about the wonderful organization, Knowbility, that organizes and runs AccessU every year.

Glenda, how are you doing?

Glenda: I am doing fantastic, Derek. It’s so great to hear your voice.

Derek: It’s great to hear yours, too. It’s not often that we get to talk. It’s kind of bizarre because we have all these technological tools that we could use to connect to one another, and we do connect over Twitter and Facebook and through email. One of the things that is kind of lost in all of it, I think, is voice. We don’t use our voice enough. You’re absolutely right, it is good to actually talk.

Glenda, some people may not know who you are, as crazy as that sounds. Lots of people are getting ready to head down to Austin, Texas for AccessU. Tell us a little bit about you. I’m really interested in hearing more about your history with Knowbility because your history with Knowbility is longer than mine. Mine started in around 2005. I’d love to hear a little bit about that and why you do so many different things with Knowbility.

Glenda: Knowbility really is the birthplace of my accessibility knowledge. I am commonly referring to myself as Glenda the Good Witch, Accessibility Goddess.

I got started at the University of Texas at Austin with my mentor, Dr. John Slatin. While Dr. John helped me understand accessibility from the perspective of people with disabilities as well as the technical perspective, one of the first people he introduced me to in the community was Sharron Rush.

I can still remember the day where I was sitting in John’s office with Sharron and we were talking about taking an accessibility internet rally, a competition, and bringing it to the University of Texas. From the moment I met Sharron, which was probably in the year 2001, with John, we became the three accessibility amigos.

Every experience that I’ve had with Knowbility has been so meaningful, both in extending my knowledge, constantly keeping my knowledge sharp, as well as teaching others how to make the web accessible and having a damned good time. Let’s just say Knowbility is irresistible to me.

Derek: That’s very cool. You started with Knowbility working with them back around 2001. You are actually part of the reason I’m involved with Knowbility in the first place. You were part of getting me to come down to Austin, Texas for my first AccessU in 2005. We have that connection. There’s really something special about Knowbility and about Sharron.

I know we’ve talked a little bit about Knowbility in general and how you got involved with them, but what is it about Knowbility? Clearly it means something to you. What’s the meaning?

Glenda: Knowbility is different from any other organization that I’ve worked for because it is a nonprofit, but more importantly it approaches the problem of accessibility as though we are a family.

I often refer to Sharron Rush and John Slatin as my accessibility parents. I’m the love child of the two of them in being birthed into this accessibility world. While that may be my personal experience, I sense that that is what everyone feels like when they participate in a Knowbility event.

Whether it’s coming to the conference of AccessU or being involved in one of the accessibility internet rally competitions, you may come to it thinking, “Oh, I’m going to get knowledge.” Instead, what you find is community and support and caring. We care about the whole person, whether it’s a person with disabilities who may need some help with a website making it accessible, or it may be a web developer who is currently blind to what it takes to make their site accessible.

It is that complete support system that Sharron is there for you as a caring friend and a mom; the accessibility mom.

Derek: That’s fantastic. She really is something. We’ll be interviewing Sharron a little bit later this week and getting that out there. We could not do this series of interviews without including Sharron because she is so important to so many people. Just the way that she approaches things is so open.

Really I think it’s fair to say that she’s full of love. She really, truly is. There’s no question about that. She’s not just a mutual friend, she’s a mutual mom to us, I think.

You’re getting ready for your sessions at AccessU and you have two of them on the schedule. One of them is called Accessibility is Broken: A Game Changing Perspective. You have another one that is Dreamweaver Accessibility.

I kind of want to do them in reverse. I want to talk about Dreamweaver Accessibility first because that one kind of surprises me. I remember that one being on the schedule back in 2005 in that era when I was there. Tell me more about what people are going to get in terms of the Dreamweaver Accessibility session and why Dreamweaver is still important.

Glenda: I think that’s a good question. It’s funny, when I look at the classes and think about, “Wow, we still need that one on the schedule, seriously?” It’s because there’s demand for it every year. Yes, it is very similar to the class that I was teaching years ago. The only difference is that when you come into this Dreamweaver class, we have a number of state agencies that are still using Dreamweaver as their major way of publishing to the web.

For people who are in that Dreamweaver scenario, so many times they don’t have a technical background. They’re using a tool; they’re using a WYSIWYG editor. What this tool does is open their eyes to even if you’re non-technical, there are things here that can help you create a more accessible site.

You don’t even need to hold your checklist next to you for some of these items. There are features built into Dreamweaver that proactively prompt you to put ALT text in, proactively prompt you to put in table headers, form labels.

It’s through this that I have a class every year, as long as they want me to have a class, where I have a room full of people. At the beginning of the class I ask, “How many of you could duke me out for the front of the classroom on accessibility?” I always have some heavy duty developers in there who also want to know how can they teach their content contributors that are using Dreamweaver to do things in an accessible way.

It’s one of those pieces of the accessibility puzzle. It may not be geared for the high level developer to learn something technically super fantastic, but for the content contributors and the more entry level publishers, it is that doorway to, “Oh, and this is how it relates in the tool that I use in my workplace.”

Other things that I tend to sneak in, I do sneak in a little bit of the CSS features because while Dreamweaver is a WYSIWYG editor, you can turn it off and just go into the code editor and it’s a damned fine code editor, too.

Derek: That’s cool. It sounds like it’s something that is perfectly placed given that one of the things that we need in accessibility is this understanding of other people and other people’s experience. I think one of the things that happens too often is we assume such a high level of skill or knowledge that’s specific to code or to design, and we tend to leave people out of some of the solutions that we create; people who are really just content contributors.

I don’t say just. I mean this really in the sense that contributing this content is a really critical piece of accessibility, but it’s a part of their job, it’s not their entire job. They may spend five out of their 40 hours working in a week generating web content, and they do other stuff the entire time. Knowing how to use tools like this I think is, as you said, one piece of the accessibility puzzle. If we want to get that thorough, end to end coverage where everybody is contributing, I think this is a critical piece. That’s good to hear it’s still on the schedule.

Glenda: I want to add one more thing because I think you’ve totally nailed it. So much of what’s offered at accessibility conferences is aimed at the developer and the designer. Think about it. How much of your website is developer or designer created versus how much of your website is content contributed? I do think that we, the designers and the developers, are the bun and the content is the meat.

You’ve now made me very excited about teaching this class again. Thank you.

Derek: You made a good food reference there. You were talking about the bun and the meat. I hope you were talking about a burger or something like that.

Glenda: I was.

Derek: There’s lots of colorful garnish that goes on a burger, too, unless of course you’re me and you don’t put any garnish on at all. Your other session sounds pretty colorful to me, although it may not be garnish. I think it’s kind of an interesting topic, Accessibility is Broken: A Game Changing Perspective.

I know a little bit about this through talking with Elle and some of the discussions that you have had with her. Can you tell people a little bit more about first, why you think accessibility is broken and second, of course without giving away your entire talk, what perspective change you’re hoping to bring to accessibility?

Glenda: You may have even been in the room with me at South by Southwest when this topic originated. I was attending Jane McGonigal’s session on Reality is Broken.

As Jane explained to us that life is not giving us good feedback on how to be successful, I mapped what she was saying into what we were doing in our world of accessibility. So many of our tools that help us define where there are obvious accessibility issues, when a new user comes in and triggers one of these tools to run and they see 115 errors or 300 errors on a page, they’re overwhelmed. They don’t know where to start. It’s like, “Ugh, why don’t I just give up?”

What Jane explains in Reality is Broken is we need to create interfaces to our tools and our work environments that are as compelling and as addictive as games. What can we learn from things like World of Warcraft of Draw Something that would layer what we need to do in accessibility in such a way that you can’t wait to solve the next problem.

That’s a little bit of a taste of what I’m going to cover. I will say that gamification of accessibility is my passion extraordinaire. I’m sharing that right now with a number of colleagues, including the fabulous Elle Waters. If anyone thinks that gamification is just some dang buzz word and that this isn’t real, I challenge you to come to the session and feel that way after the hour because what is gamification? It’s actually extreme usability. You don’t play a game unless it’s good. Honestly, you’re not going to fix these accessibility problems unless I make it rewarding.

Derek: That’s interesting. One of the challenges, of course, with that, is how do you make things rewarding for people? I know that we work with a lot of clients and you probably work with a lot of clients as well where a lot of the motivation for accessibility comes through legal mandates or through just simple requirements that are maybe not a legal mandate directly on the person who’s building the stuff, but it’s a legal mandate for the person they’re building it for to procure accessible solutions and software.

There may be some kind of a tension there between those two things because we’re talking about something that, as professionals, there’s stuff that we just need to do. On the other hand, we’re also talking about yes this is your work and this is what is required of you to do your job well, but then there’s the other side of it where we’re saying, “We know it’s kind of boring and we need to make it exciting for you.”

I imagine that there’s some tension there between those two schools of thought. Is that something that you talk a little bit about?

Glenda: I do, I definitely do. What I think is that because of the way our society has approached things like work or can I even say other things that make for good health; in this case I’m talking about accessibility health, but what about eating right and working out?

These things can be dull, like, “Oh, you have to only eat 1,200 calories a day. I need you to move more. I’m going to make you feel bad if you don’t do this.” Or, we can go with something more positive like the FitBit where it actually becomes an interactive game and it’s giving me constant feedback.

Just like how many calories I eat a day and how much do I move my body can be boring or fun, why the hell can’t I do that with accessibility? I actually don’t think there’s a tension there in reality. I think society put one there in the way we created measurements and feedback loops. That means it’s time to pull out our creative juices and design better feedback loops for that same activity that makes it fun and rewarding.

What’s intrinsically under this that is so incredibly powerful and may not be as powerful in some other work areas is the work that we’re doing is truly meaningful. It is providing independence to people, it is opening the web. When you can tie the work that you’re doing to something that makes the world or the web a better place, that intrinsic motivation is just waiting to be tapped into.

Derek: That’s interesting. I’m really curious to see how this ultimately plays out in the long run, as well. We don’t have that long view right now because we can’t. So much in the web standards world or even just the web in general, it’s seems very old but it is still very new.

One of the things that I kind of wonder about aloud is seeing things like my son. I have an eight year old son who’s about to turn nine. Seeing his addiction to video games and how that plays out in terms of his behavior and what that means for other things, I’m concerned with gamification in general.

I think it’s a fantastic concept. I think we can really use it well. I also wonder about, and forgive me if I’m wrong here, but I wonder really deeply about what it’s actually teaching people and what the addictive nature of these games actually is teaching my son.

I’m also curious to see, not that I’m saying the same thing would happen in accessibility or in any other work environment type thing, but I’m really curious to see what happens down the road in terms of if we create these behaviors, are we creating something where the intrinsic motivators are becoming dulled, so to speak, so that people are only going to do things if they are motivated by some of these gamification ideas. I’m really curious to see what happens.

Glenda: That’s an interesting question, Derek. As usual, you make me think outside the lines.

What I would say is there are so many different factors that go into designing good games. A piece of that is that when you create the addiction, that you don’t hurt the person.

I have heard and seen situations where people have gotten addicted to games like World of Warcraft and, let’s be honest, I’ve never touched World of Warcraft, but I’ve seen people fall in there. Their real lives go abandoned.

As we’re designing any kind of gamification for the work world, I need to look at something that creates balance. Wait, this would be a really good problem. You’re so addicted you can’t stop solving accessibility issues that you forget to, oh wait, I need you to eat and sleep and have a social life.

I do understand what you’re saying that we don’t want to create an environment where our children are only motivated by really good interfaces, have no self discipline, have no drive of their own. I think that’s an interesting thing to keep in our minds as we design.

Trust me, we care about the whole person, going back to the Sharron Rush Knowbility school of thought. We’re not just here to fix accessibility problems. We’re here to make the world a better place. For us to do that, we have to take care of the individuals, as well.

Derek: I think that’s a great point. I really wish I was going to be there at your talk to hear it.

Glenda: Me, too.

Derek: I’m sad to say I won’t be there. I think I’ve said this to every person that I’ve interviewed. I’m kind of living vicariously through doing all these podcast interviews and stuff.

It does sound like a really interesting topic and things that people can really put some thought into when they’re trying to figure out how to best get accessibility best practices and principles adopted at the organizations at which they work.

This is definitely one of the tools that we have. I think that’s probably where some of the balance comes in is that gamification is not the tool, it’s a tool. It will help us in many ways with lots of different aspects of this process and of this growth, but it can’t be seen as the only tool, otherwise we do lose that sense of balance.

It’s really, really interesting stuff. I’m glad you’re thinking about these kinds of things. It’s a huge topic and it’s something that people definitely need to keep thinking of. That’s very cool.

Glenda, you live in Austin.

Glenda: I do. I have that good fortune.

Derek: You do. I think it’s a wonderful city. I’ve been there many times myself. I’m really curious to hear the insider’s perspective. You know Austin inside and out and there are a lot of people who are going to be coming to AccessU from elsewhere who don’t know Austin.

What are a couple of things to see or do while people are in Austin if they can find some time and pull themselves away from the conference for maybe an evening or something like that? What should they go and do while they’re in Austin that are really, truly sort of Austin treasures?

Glenda: It’s interesting you should ask. Whenever I have people come and visit me from South by Southwest, I have this list of things that I want to show them. Not the things that they’re going to be told by everyone else, but those little treasures that if you live here you know about.

My first stop for most people is to take them to my favorite toy store. There’s a toy store called Toy Joy, and it is the craziest place on the planet. It is close to the University of Texas at Austin campus, and when you walk in it’s a sensory overload. There are toys everywhere. You can hardly walk through the aisles. Your eyes can’t take it all in, and then you look up at the ceiling, there are toys and Christmas trees hanging upside down on the ceiling.

It’s one of those places to go and play and discover your lost childhood. Me, I never seem to lose my childhood.

The other place that I love to go is called Zilker Botanical Gardens. We have such a beautiful city, and those of us who are uber geeks sometimes forget to go outside. I take people to the botanical gardens and we walk. There’s a gorgeous Japanese garden. It has waterfalls and little wooden bridges and you can walk on stones across the pond and see the koi.

A whole other area that I discovered just this March when instead of leaving the park where I normally leave, the person I was with said, “Can we go down this path? What’s down there?” An entirely new section with more waterfalls and dinosaurs and blue bonnets.

I would say these are two of my favorite treasures; play and gardens.

Derek: That sounds absolutely fantastic. Hopefully some people will get a chance to check one or both of those out while they’re in Austin.

Thank you again, Glenda, for taking the time with us today. This has been fantastic. It’s always great to talk to you. Thanks, and have a great time at AccessU.

Glenda: Thanks!

Derek: Thanks, Glenda. Talk to you soon.

Derek:Awesome stuff from Glenda — make sure you get yourself to John Slatin Access U to experience it first-hand. Register now at Knowbility.org – that’s k n o w b i l i t y dot org.

[Outro Music]

AccessU Keynote Speaker Kimberly Blessing

Feel free to download the podcast:

• m4a format, Interview with Kimberly Blessing
• mp3 format, Interview with Kimberly Blessing
• .ogg format, Interview with Kimberly Blessing

Transcript

Interview Summary

Derek: Kimmie Blessing has worn a lot of hats in her 20 year career on the web. She’s a developer, a manager, a speaker and a great leader in the web standards world. We’re running an entire series of podcast interviews with a number of great speakers from the John Slatin AccessU conference.

We talk with Kimmie about change, culture and four letter words as she prepares for her keynote address at AccessU. 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.

[Intro Music]

Derek: Hi everybody, this is Derek Featherstone with Simply Accessible. We are continuing with our series of interviewing speakers for the upcoming AccessU. I have with me today Kimmie Blessing. How are you, Kimmie?

Kimberly: I’m doing well, Derek. Thanks. How are you?

Derek: I’m doing really well. I’m getting kind of excited. We’re getting closer to AccessU time. I know people are deep in their preparations and getting ready.

Many people are out there trying to make the decision as to whether or not they’re actually going to be able to make it to AccessU to attend. I just wanted to spend some time with different speakers and help push people over the top a little bit. I think that John Slatin AccessU, put on by Knowbility, is literally the best accessibility specific conference that there is going. One of the reasons is that we have a lot of great speakers and this year is no exception.

I was really pleased to see that this year you are doing the keynote. I think that’s fantastic. Before we get into the keynote, maybe you could spend a couple of minutes just to share with the audience, people who don’t necessarily know you, maybe you can tell us a little bit about yourself and maybe a little bit about what accessibility means to you.

Kimberly: Sure. When most people ask me what I do, I tell them that I’m a web developer. I started developing websites almost 20 years ago. In 1993, my first site went live in ’94. That seems like both an incredibly long period of time and also like the blink of an eye. It’s great to be in a field that has changed so much in such a short period of time because you’re constantly on your toes and learning new things. That’s what I really love about it.

In reality, I haven’t had fingers on keyboard so to speak for 20 solid years. I’ve moved around and had a lot of roles. I’ve been in management, I’ve done program management, I’ve done standards, I’ve done strategy work, but always related to the web because that really is what I’m most passionate about is helping people connect using technology.

It’s funny because when I first got into the web, I got into the web I guess because I was a computer science student, but I was also doing IT work as a way to sort of pay my way through college. One of the things that I remember very distinctly, and I kind of say this is how I got my start with accessibility, was right around that same time. It was actually in 1994.

I was asked to install a couple of pieces of software onto a computer that was in a public library because they had gotten funding because somebody in the community had a disability and needed special software in order to be able to use the computer and the computerized card catalogue, and soon after that to use the internet and what not.

Literally the software just got dropped on my desk. Nobody knew anything about it. I just picked it up, I went to go install it, and I thought, “Wow, okay. Wow, this would enlarge a section of the screen so that somebody who was low vision would be able to see these words. Wow, that’s magnified 2000%. Okay.” Things started to click for me.

I met a member of the community who was going to use the software. She let me observe her using it and she explained how things could be better set up so that the entire system was more convenient for her. We actually moved the computer to a lower table because her wheelchair sat lower than most people prefer to sit on chairs.

I kind of got this entire hands-on tutorial thanks to just this rare opportunity. When I really got into web development as a full time profession, that just stuck with me. When reading the specs as some of us used to do and it said, “Use an ALT attribute on your images in order to give some descriptive text for the image in case somebody’s using a screen reader,” that made perfect sense to me.

I guess I should even mention that I myself have never been a big fan of the mouse. I like to keep my fingers on the keyboard. I’ve always been sort of a tab based navigation person, so those kinds of things, I guess in thinking about accessibility, I’m not thinking necessarily about even folks who would consider themselves to have a disability. I’m thinking about people who just have their own preference for how they want to interact with technology and with the web. I want to make sure that we honor every person’s preference as much as we possibly can.

That’s where accessibility really ties into things for me. I’m just really honored to get to be a part of AccessU this year, I guess I should say. I’ve never had the opportunity to attend before. I guess when I was a manager I was always sending my staff because I thought, “I want them there. I want them to get that same kind of hands on experience with people who can really communicate the importance of this far better than I can.” Now for once I get to go myself. I’m really excited.

Derek: I think you’re going to have a fantastic time. It really is a wonderful conference with lots of different people and lots of different perspectives. I think that’s a huge part of it.

I’m interested in hearing a little bit of your talk. I don’t want you to tell us everything that you’re going to talk about, but the name of your keynote address is Change is Not a Four Letter Word. Tell me a little bit about that.

Kimberly: Usually I give technical talks, and when I was approached to give the keynote I was sort of both really flattered and a little bit frightened because obviously in giving a keynote to this type of audience, what I understand about the conference and what I really want to do is help people understand that they are agents of change.

They have it within themselves to help their organizations, their peers think of accessibility in the same way they do. They’re passionate about it, they believe it’s important, and we really are at least in terms of the U.S., I think sometimes the U.S. is perhaps a little bit behind in some ways when it comes to legislation regarding accessibility, especially on the web, but we are at this kind of pinpoint opportunity where things are really about to change in terms of laws and various legislation.

The knowledge that people are getting at AccessU, I really want to help people feel empowered to take that back to wherever they’re from, whether it’s an institution of learning, whether it’s a giant company, a small consultancy, or whether they’re just independent and they have the opportunity influence a larger community of people. It’s important that they know how to do that, to understand that they already have it within themselves to do it. I want to help them understand some really simple steps that can make that process of introducing change much easier.

A lot of times when we talk about introducing change in an environment, the initial reaction is fear. That’s what I’m talking about. It’s true enough when people say, “Oh, it’s time to change something,” there’s a lot of cursing. Usually that comes out of a sense of fear. People get comfortable with the way something’s done. It works for them, and so in order to make a difference, it does mean adapting. It does mean possibly failing. That’s how we grow as individuals, it’s how we grow as a community, and it’s how we’re going to grow and make the web into the powerful tool of communication and worldwide interconnectedness that I think a lot of us see it as.

Part of it, I hope to be inspirational, and in part of it I hope to be very practical by telling stories about opportunities I’ve had to influence and create change in organizations. I can demonstrate very specific steps that the audience can go and take so that they don’t even have to be fearful about being that change agent that they can see. It’s just a series of steps. It’s a methodology. Not everything always works, but you can try and try again until you get it right.

Derek: It sounds like a lot of what you may be talking about or working with people on is that idea of introducing change and helping people overcome that fear. Are there any little tidbits that you could sneak peek to us that might help people, just so they get a sense of what kinds of things you’re going to be talking about?

Kimberly: Sure, absolutely. I think there are a couple of really essential things that people need to understand. The first is that they’re not alone. There are others out there, and some may be local and some may not. There still is a community that they can lean on.

As much as they can leverage that community to help them and support them, it’s going to reinforce that they’re doing the right thing and get them through those tough times when either they’re surrounded by a lot of naysayers and nonbelievers. It will help them brainstorm and give them ideas for other ways of coming up with tactics to address the audience that they’re going after.

One is to make sure that you’re finding those people and reaching out to them and building that community of support. At the same time, it’s really important to find sponsors. This is particularly important when you’re working in a large organization because if you’re a low person on the totem pole or somewhere in the middle, you may not necessarily have the authority to just say, “Hey, we’re going to change. We’re going to make all of our websites accessible.”

What you’d probably need to do in that case is start to find that community that does support you, but then find those folks who are higher up who can sponsor your ideas, who see the value in it, will back you up, will help you find other ways of getting your message across. Probably eventually those will be the people who can use their authority to say, “Okay, now our policy is to make all of our websites accessible.” You want to make sure you spend time finding those sponsors.

In order to find those sponsors, sometimes you have to change your language and learn how to speak a different language. Most of the people I know who are really passionate about accessibility come from either a design or a development sort of background. We’re used to either communicating in perhaps soft terms or very technological terms.

If you’re in a large business, those terms really may not make their meaning clear to, for example, a finance person who’s focused on financial figures. It is sometimes a matter of taking a step back, looking at what it is you’re trying to communicate, and seeing if there are other ways to get that same message across. Tell the story, but tell it in a different way so that you’re connecting the dots for the intended audience. You’re not making them connect the dots on their own.

` That can actually help to bridge any gap much more quickly. It’s a lot easier to go to a finance person and say, “We need $2,000 to buy a copy of JAWS and a new computer to set it up on because…” and then you demonstrate the financial value of making sure that the site is accessible. Maybe it’s expanding the intended audience for a product and increasing the overall revenue of the company. Maybe it’s avoiding lawsuits and the financial payouts that have to go along with that.

Even though you may have internalized it as doing good in the world or this is important because other people have different technology preferences, sometimes your audience will go, “Yeah, yeah, yeah. That’s nice, but speak to me in my language.” That’s another bit that I’ll be talking about in the keynote.

Those are kind of three things. I have five different techniques. I’ll only give you three as a little preview. Those are some starter ideas. Hopefully that’s enough to pique folks’ interest and get them to attend.

Derek: I think it will be. I don’t think people will want to miss this. One of the questions that I’m asked all the time, and as you know I speak quite a bit to different audiences, sometimes designers, sometimes developers. I was at a conference in the Netherlands in December and we had gone through this entire full day workshop and the designers were all ecstatic. They loved it. One of them put his hand up at the end and he said, “Okay, this is fantastic, but how do I sell this? I don’t know how to sell this to the people who I report to. I don’t really know what to do there.”

I think it’s interesting, some of the things that you’re talking about. Empathy for the other person’s point of view is something that is built into us as people who are supporters of accessibility and good design in the first place. We don’t always think that way when it comes to the tactics that we use for trying to do things like create change. I think your point about speaking to people in their language, I think there’s almost that empathy in trying to create personas for different types of people that we need to work with in an organization would be really useful just to get a sense of what’s their likely frame of mind and what is going to be useful to them in order to help them make this decision.

Any other thoughts about your talk or anything that you want to share?

Kimberly: I think if you look at the AccessU site, it talks about my experience at AOL and my technical career. One of the things mentioned there is the Web Standards Project, which is obviously Derek, you know, how we know each other I think initially or best. We have experience in working to create change in sort of a massive scale, trying to speak to an audience of web professionals the world over.

We could probably speak a lot about successes and failures of that group as it relates to change and the ability to empathize with one another and communicate effectively. That’s just sort of another example of why these basic tenets of understanding how people process change and how to make it an easier transition are really important.

I think these are the same principles. I read an article years ago about how a number of employees at a company banded together in order to get daycare into their organization. To me, it read exactly the same way. This is not just about creating change necessarily in order to bring accessibility to the forefront of web professionals’ minds and in order to make it a reality for everyone, although obviously in terms of this conference that is what’s most important.

These same techniques will apply anywhere and hopefully that will also resonate with people because it may be less scary to try and do this in some other regards first. Just trying to get your kids to do their homework or trying to get your community to actually sort their recyclables, which is actually another story that will probably be in the talk, as well. When I was in high school a very long time ago, before recycling was commonplace, I tried to get the school to recycle.

These are the kinds of things that I’m betting that people will be able to relate to. They’ll already have some kind of experience trying to do something similar, they just haven’t connected the dots for themselves. I think as soon as they latch on to that and realize that they have either been through this before somewhere else in their lives and hopefully been successful with that, that will also empower them to realize that being that champion for accessibility within their organization, their whole lives have been preparing them for this. They’re going to do great when they get there.

Derek: That’s fantastic. That’s already an inspirational message. Hopefully not just the people who are there at AccessU listening, but anybody else who listens to this podcast as well will be inspired by that. I think you’ve made a lot of really great points. You had me at convincing your kids to do their homework. I’m sold already. I think that’s huge.

This is definitely something where the things you’re going to talk about are not going to just help with accessibility change, but with change in general. That’s fantastic. I think we need more of that within the accessibility community because quite often I think in the accessibility tribe, we don’t necessarily have a lot of those skills. What ends up happening is we end up trying to create change by what seems to be forced methods. That just leads to resistance and things don’t change.

I think some of these skills and the techniques that you’re talking about or will be talking about will be incredibly useful.

Last question. Tell me about something that you want to do. We have a lot of people coming in from outside of Austin who don’t know Austin. We’re playing sort of virtual tour guide here. What is a must see/must do thing for you while you’re in Austin? If you could give advice to people on one thing that they absolutely must see or do or eat, what would it be?

Kimberly: Okay, I have one in each of three categories. The must eat for me is the Moonshine restaurant, which is downtown. It’s actually near the convention center. I think it’s just a beautiful location and they have popcorn as an appetizer which I just love. Their meals are just delicious. I’m hoping to find time to eat there.

I’m hoping to make it to Waterloo Records to go record shopping. Waterloo Records is one of the top record stores in the country. I always try to make time to go there for a bit.

If I had the time, I’m not sure I do, I would go to the Alamo Draft House and Movie Theater to catch a movie.

Derek: Very cool. Thank you very much, Kimmie. We’ll talk again soon.

Kimberly: Thanks, Derek. Have a great day.

Derek: Those are some great lessons from Kimmie — this should make for an excellent keynote. Go register for AccessU at Knowbility.org – that’s k n o w b i l i t y dot org.

[Outro Music]

Plain Language and Usable Accessibility: Whitney Quesenbery

Feel free to download the podcast:

• m4a format, Interview with Whitney Quesenbery
• mp3 format, Interview with Whitney Quesenbery
• .ogg format, Interview with Whitney Quesenbery

Transcript

Interview Summary

Derek: In the past, people often thought of accessibility as a checklist — a set of rules that you needed to follow when building web sites. Now, Accessibility is sometimes seen as part of user experience. Today we talk with Whitney Quesenbery, a User Experience Researcher that works to incorporate people with disabilities into her UX practice. 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.

[Intro Music]

Derek: Hey everybody. This is Derek Featherstone with Simply Accessible. I am proud to sit here and talk today with Whitney Quesenbery.

Whitney, I’m really happy to have you here. I have a lot of questions for you. Thanks for being here. How are you doing?

Whitney: I’m doing great. Thanks, Derek. I love being here.

Derek: Excellent. We’re talking about getting ready for AccessU. We have a lot of people that are coming from all over the country and some people that are local to Austin. We’re converging on Austin for what I think is probably the best accessibility conference going. One of the reasons is that there’s a huge diversity of instructors.

You’ve been an instructor at AccessU before. One of the things that I think is interesting is that you talk about different aspects of accessibility than most people are probably used to. I wanted to talk to you a little bit about the work that you do. We’ll get to your sessions.

For people that aren’t as familiar with your work, maybe you could share a quick synopsis with us of the kind of work that you do and how it all ties into accessibility.

Whitney: Sure. The big, broadest umbrella today for what I do is called user experience. That’s kind of a gathering up of a lot of really individual skills like information architecture, usability testing, design research, design, interaction design, and content. All of those have to come together to create the experiences that we, as users, have when we interact with all the great tools that we make.

I think one of the things that’s happened in the last maybe ten years or so is that we’ve begun to think about accessibility not as something that’s separate for those people over there, but simply as a broader view of better experience for more people.

That’s sort of where I come to accessibility. What I actually do with my life is most of the time I’m working with a team that’s developing some sort of online product. I’m the person who is in charge of going out and understanding how their audience will see it, whether that’s early testing of new ideas or usability testing things as they launch them, or even going out into the field and seeing what people’s lives are like and how this new product might fit into that life.

Derek: That sounds fantastic. When most people traditionally think about accessibility, they tend to think about the development side of things and the code things that they need to do. It’s clear, I think, that it’s something that is much broader than that, as you suggest.

What sorts of things do you do when you’re working in the field with people with disabilities? What sorts of activities are you doing with them? How are you working with people with disabilities and integrating them into that user experience work that you talked about?

Whitney: I’m not doing anything special that I don’t do with everyone else. Let’s say we’re working on a product to help you manage your travel. I might want to know what kind of travel you do. Are you travelling for business? With your family? What are some of the problems that you face today that you wish somebody would solve and make go away? Hopefully the ideas that we’re working on line up with that.

I might take you through some prototypes and ask you to think about how that might work or maybe make suggestions for how we could make it work better. If we’re a little further along, I might just sit back and say, “Let’s pretend you’re starting a trip. Go on and start working with this.” Then sit back and simply watch you work.

The thing that working with people with disabilities adds to that mix is it means I have to think about not just people who are interacting with that tool in one way, maybe visually and through a mouse, but who might be using a screen reader, who might need to make the text bigger than some other people might, who might have trouble turning pages or handling physical objects. Then try to make sure that we have included all of those in our thinking.

These days, we also might be thinking of people who are trying to do things with just one hand because they’re standing in an airport, dragging a suitcase behind with the other hand. There are all kinds of overlaps between what we call situational disabilities, things that make it hard to interact with the technology not because of who you are, but because of what the situation is.

Derek: That makes good sense. We’ve talked with some other speakers as well and they’ve sort of mentioned similar ideas. We create these solutions that work in sort of a lab setting or on the developer’s or designer’s desktop. They don’t necessarily always reflect real life. We get that different perspective there when we have that real life side of things.

Whitney: We used to call this human-computer interaction. The model was a person at a desk with their hands on the keyboard in front of the screen in a sort of office setting. That’s not technology today. It’s certainly not technology in the future.

One of the things that’s made usability, accessibility, and user experience all come together is the way that technology is so much more pervasive in our lives. We use it in many more ways. We use it in less predictable ways.

For me, this is a really exciting time because it’s the first time in my career that I’ve seen the needs of people with disabilities to have flexible technology, the needs of everyone to have flexible technology across devices, and the understanding that everything from the first paragraph on the screen to the deepest code all contribute to that. All of a sudden, that idea isn’t just special needs. It’s mainstream.

Derek: Exactly. I think that’s something that we’ll probably continue to see.

This leads me into, I think, one of your sessions. You have a session at AccessU on the 15^th in the morning that is called “Usability Testing for Usable Accessibility.” Some of these things that you’ve been talking about, are those the kinds of things that you mean by “usable accessibility” or are you thinking of something else?

Whitney: Absolutely. I’m doing this session with Kate Walser, a colleague. She and I were actually on the 508 Refresh Committee together. That’s where we met.

Lots of people do usability testing these days. I think that a lot of people want to do work with people with disabilities, but they’re afraid that they’ll be rude, that they’ll make a mistake, that they’ll say something inappropriate, that the session won’t work well.

We hope that this session, which is a three hour workshop, will not only help people who are learning to do usability for the first time come up to speed quickly, but it will also give people a chance to actually practice running a usability test with people with disabilities who are going to be part of the facilitators’ group for this course.

They’ll be able to try out some new ways of moderating in a safe environment, where they can actually stop and ask if something was okay. They can think about how to adjust their own approach to usability testing to accommodate a broader audience.

Derek: I don’t want you to give away the punch line or anything like that, but are there any little teasers that you can give us? Are there things that typically show up when you’re doing usability testing with somebody with a disability?

What are some of those things that are a little bit different or things that make people pause or that maybe need a little bit more attention than they would in doing usability testing with somebody that doesn’t have a disability?

Whitney: One of the first problems, of course, is getting the computer set up. People who are using assistive technology need that assistive technology set up correctly. I think that’s also become a lot easier as more and more people have mobile technology or laptops that they can simply bring or where the tester who’s running the test can actually go to them. That’s sort of the first step: helping people who may not have seen a lot of assistive technology in use understand what that’s like.

When you’re working with someone using a screen reader that really does change the session a little bit. One of the ways that we do usability testing is to ask someone to use whatever it is they’re using and to talk while they’re doing it, to kind of narrate their experience. “I’m looking for this. I just don’t see that button. I wonder what that means.”

If you’re listening and you’re interacting with the technology by hearing it, you can’t be talking at the same time. Often I switch to what we call a retrospective, where we sit back and let someone interact in their own way, then ask them to stop. Then we’ll go back and go over that with them verbally.

The other thing you have to think about in working with somebody with a screen reader is whether it’s important for you to be able to hear what they’re hearing in the way they would normally hear it, or if you need them to slow down so that you can hear exactly what they’re interacting with.

You, I’m sure, have heard a lot of people using a screen reader. The speed is faster than I can hear. If I want to be able to follow what they’re doing, I have to not only ask them to slow down for me, but I have to be able to make sure that I’m watching their hands on the keyboard so I know what hotkeys they’re hitting. That’s a little different level of observation that I might need to do.

Or I might choose not to do that. I might say, “I’m just going to sit back and let you do what you do and see it in as natural of a way as we can, then get you to tell me about that.”

Derek: That’s an interesting thing to observe. When you’re working with people with disabilities and seeing somebody with a screen reader and you’re doing a usability test with them. It really is quite interesting.

One of the things that I find or have found in the past is that there’s an interesting interplay between the technology and the experience. One of the things that I think everybody struggles with is determining how much the issue that somebody with a screen reader is experiencing is due to the code or the design or how much of it is their experience and relative experience with the screen reader.

We all know that just as there are expert computer users and novice computer users, we see exactly the same thing with screen reader users or users of any type of assistive technology. Is that something that you typically take into account in your testing scenarios? How do you deal with that and still try to be sure that you’re getting valid results?

Whitney: Absolutely. I think that’s a problem, in fact, when thinking about any technology for anyone. This is that we all have different things we’ve learned about how to use our technology and that interplays with how well we know what we’re trying to do. You might be an expert in booking travel, but not an expert at using your brand new phone, for example.

I think the same issues around how comfortable people are with technology apply to people, for instance, who might have low literacy, people who not people who work at offices and have technology surrounding them all day long but who use it in a more casual way.

I think we always want to think about who the audience for our products are, what range of expectations we might have about their comfort with the whole idea of using technology to do whatever we’re asking them to do.

Then you have to decide how much you’re going to meet them where they are. If you have an audience that includes people who are brand new to their mobile device or are brand new to their assistive technology or who are just not all that interested in becoming experts in technology, are you going to leave them behind just because they didn’t bother to learn all the hotkeys? Are you going to make sure that your product speaks to them, helps them, is supportive, and doesn’t just kind of bark at them?

Derek: Right. I think what it speaks to and what I’m hearing is that you would do this for everybody. This is not something that is unique to people with disabilities. This is something that, again, is part of user experience for everybody.

Whitney: For a while I did a lot of work in a medical cancer domain, doing information products. People would say, “Oncologists are the experts in this field. They want to read serious material in a serious way. It’s okay if they have big blocks of hard to read paragraphs.”

Yes, they can read it. They can understand it if they take the time to do it. They’re also really, really busy people. They want to be able to scan through that treatment guideline, just like anyone else would.

The things that help, say, an expert oncologist scan through information about how to treat a certain kind of cancer are the same techniques that help someone using a screen reader scan through headings or help someone who doesn’t read that well scan through the headings to find the right paragraph to read.

Derek: Exactly. A couple of times now you’ve mentioned the consumption of information and some of the issues that we face with people that have literacy difficulties. Your other session at AccessU is on the 14^th, also in the morning. It’s called “Plain Language: Accessibility for Content.” Can you give us a little taste of what that’s about?

Whitney: Sure. I love talking about 508, because we can talk about the actual laws that support accessibility. There’s actually a law that supports plain language. In 2010, the Federal Government passed a law that said that when the Federal Government speaks to the citizens of the United States, it has to do so in language that’s appropriate to the audience and the content.

To me, those two together say we have to make our code accessible. We have to make our technology accessible. We have to make our content accessible. That’s really what we’re saying. We’re making it accessible to people at varying degrees of knowledgeability about the content and maybe reading skill, as well.

Derek: This session that you are doing at AccessU, then, is all about plain language. What do you mean by plain language? How can we create things that are easier to read? What’s the relationship between plain language and accessibility?

I think you’ve given us an overview of that. It’s an hour and a half lecture. Clearly it’s not going to be a hands-on thing, but are you going to get into different examples and techniques and things like that?

Whitney: Yes, absolutely. We’re going to look at different examples. It actually will be hands-on. I’m going to give people a few short exercises to do to think about how we could say something in a way that is easier for people to understand.

It’s interesting. Once upon a time, back in HTML1, I was kind of an expert in HTML. Those years are long gone for me.

What I’m finding is that just as it’s important for someone who’s thinking about how to structure the code to think about accessibility for day one, if we think about what the mental model is, how we’re structuring the information, how we’re structuring the interaction from the point of view of a very broad audience, it gets easier. It gets more accessible. Accessibility becomes less about remediation and more about baking it in.

That was pretty exciting for me as someone who’s long been a supporter of accessibility but was kind of struggling to understand how my skills could be part of that.

Derek: I think understanding is a huge piece of this. We tend to say from our perspective, or as much as possible, when we’re working with clients or we’re teaching other people about accessibility that there are really three major components to an accessible solution.

One is that we have really fantastic technical execution. One is that we have a wonderful design that supports accessibility. Then the third piece is that content is really well structured and edited and is set up in such a way that it really facilitates that quick consumption and making things as easy to understand as possible.

Whitney: Yes. Can I actually do a pitch for a book I have coming out at the end of the year?

Derek: Please do.

Whitney: At the end of the summer, actually. Sarah Horton of the Yale Style Guide and I have been working on a book on accessibility. Instead of sort of marching through the technical things, we’re actually looking at how we structure a project, starting with clear goals at the very beginning.

It’s of a solid structure, make sure the interaction is easy, that the way-finding and navigation is helpful, that the design is in a presentation that supports people, that the language is clear, that the media is accessible, and that the whole thing adds up to accessible usability.

Although we certainly touch on the technical issues, it’s really designed to help people think about the process of getting that whole end-to-end design process to be accessible from the very bottom.

Derek: That’s just crazy talk!

Whitney: Yes, it is. I mean, I want to say, “It’s easy. Accessibility is just what you’re doing, a little better.” But there’s also a little shift of direction. That shift of direction is thinking about people who are more than just you.

Derek: That sounds great, Whitney. What’s the name of your book?

Whitney: We call it A Web For Everyone: Designing Accessible User Experiences. It took us a long time to come to that. We were trying to really figure out what the core of what we were saying was. We had all these very technical names. We suddenly realized it was simple.

We all love the web, right? We work in the web because we love it. We want everyone to be able to use it.

Derek: That’s fantastic. It’s a great way of thinking. I think that frames it really well. It’s something that we really want designers and developers and content creators and even people that are sort of business decision-makers. We want them to be thinking about this not as some statistical thing, but this web is actually for everyone. I love that title. I think that’s fantastic.

Just to wrap up here, you’re getting ready to head to Austin. You have a few other things happening before that. What are you most looking forward to when you get to Austin? What are some of the things that you’re going to do and see or that you really recommend other people make sure they check out when they’re in Austin?

Whitney: You mean Austin, itself?

Derek: Your call.

Whitney: I have to tell you, I’m a cave-dweller. What I love most about going to conferences is being able to kind of immerse myself in people who have the same ideas and the same interests. For me, it’s a great chance to gather with what Sharron calls The Tribe.

Everybody at AccessU is there because they either want to learn about accessibility or they’re an advocate for accessibility or an expert in accessibility. For me, it’s a chance to learn as much as it’s a chance to teach.

Derek: That’s great. We’re all in good company when we’re at AccessU, that’s for sure. I’m sad to be missing it this year, but I’m sure you’ll have a great time there with The Tribe.

Thank you for taking the time with us today. I hope that we see a lot of people at your sessions.

Whitney: Thanks, Derek.

Derek: Again, that was Whitney Quesenbery — just one of the diverse, experienced 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.

[Outro Music]

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

Transcript

Interview Summary

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.

[Intro Music]

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 14^th through the 16^th 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 15^th 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.

Part of my concerns are about creating consistency in the process in general. What I mean to do in that class at AccessU basically is go from some lectures on the way to present these concepts, and then try to work with the concept of play shops as much as possible. Play shops as opposed to workshops where we would either take examples of code where we have different ways of doing things that technically all are accessible, but provide different results in terms of user experience, for instance, or other cases where we would just discuss what a success criterion actually means to different people.

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.

Denis: Thanks.

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.

[Outro Music]

Topics will include things like:

• Accessibility: a traveler’s guide for non-residents
• Yes, you really can make accessibility more affordable
• Five things every web developer should know about accessibility
• Modals and lightboxes: How I learned to stop worrying and love the focus path
• Got a topic you want us to write about? Let us know and we’re on it!

Also during Global Accessibility Awareness Day, or GAAD, the Simply Accessible team will start up some rapid fire Twitter discussions. We’re rolling up our sleeves to work with the UX and web development communities online so we can form some real action plans to increase accessibility education and awareness. We’ll provide even more sneak peeks and info about AccessU 2013, kicking off this month on May 14th in Austin, Texas. And, finally, we’ll be showcasing exciting local accessibility news and events from around the world. From New Zealand to India, from the Middle East to South America, and from Canada with love, beautiful and accessible design is happening everywhere, even in Pago Pago!

Molly Holzschlag at AccessU on the Open Web

Feel free to download the podcast:

• m4a format, Interview with Molly Holzschlag
• mp3 format, Interview with Molly Holzschlag
• ogg format, Interview with Molly Holzschlag

Transcript

Interview Summary

Derek: Today we talk with Molly Holzschlag about CSS, resolving accessbility tensions in design, ARIA and the culture in Austin as we prepare for Knowbility’s John Slatin AccessU. 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.

[Intro Music]

Derek: Hey everybody, this is Derek Featherstone with Simply Accessible. I have Molly Holzschlag with me today. We’re doing some interviews, talking about accessibility and talking about the preparation for AccessU put on by Knowbility, May 14-16 in Austin, Texas.

Molly, how are you doing?

Molly: Doing great down here in the wild, wild west. How are you?

Derek: I’m doing well. I’m happy to have some warmer temperatures today. We’re still feeling some pseudo-winter here in Ottawa. I’m happy it’s a bit warmer today.

Molly: Crazy weather this year, I think.

Derek: It’s been absolutely crazy. Sadly, I don’t get to come to AccessU, so I’m kind of getting my chance to talk with all my friends and people that I would normally be speaking with in person and be in the conference schedule, but I’m not going to be there this year, so we get to do these interviews instead.

Molly: Participating; ever part of a tribe.

Derek: Exactly. Molly, believe it or not there may be one or two people who are listening to this who don’t actually know who you are. You kind of are one of the long time stewards of the web and I’ve known you for many, many years and consider myself very lucky to have met you pretty early in my career.

Can you tell people out there who you are? I know where you work, but they may not know where you work. Tell people who you are and maybe a little bit about your history and a little bit about yourself.

Molly: Okay. Currently I’m working with Knowbility. They are, of course, the nonprofit organization that we do a lot of outreach and education, the goal being to bring technology to children and adults with disabilities, whatever that means.

Whether it’s technology that we’re using on the web, obviously, or other assistive technology, we’re there. Obviously the web is where a lot of it is happening, so a lot of our focus at Knowbility has been in the web arena and working to educate, provide opportunities for people to contribute to the community, to work, to learn, and to grow as a result of the activities that we have, AccessU being a premiere one of those activities each year.

That’s really what I’m doing these days. Of course, what some people might know of me, I’ve been around a long time as you were saying, Derek, but then again so have you. We have good stories to tell about each other. I think that from the days of web standards, I like the word you used, you used the word “steward,” or stewardess, I suppose. I think that’s a good word. It’s better than evangelist, which has so many strange connotations to it.

I was well known for a while in that arena for the web standards movement. Of course, there came a certain time where that movement continued and the web standards project continued, but I was offered to come onboard with Microsoft as a consultant. Once I was taking money from the place we were working with, I could no longer lead the grass roots organization.

Of course, as you know, I left that and went on to work for several different browser companies including Microsoft, and later Opera Software.

I have a lot of interesting points of view that I’ve been very fortunate in my career to be able to be on a variety of sides of the creation, via the W3C, watching the technologies get made which is kind of like watching sausage get made; truly, not a pretty sight. Then moving on into actually developing and designing, so making the technologies, using the technologies, teaching the technologies, and then trying to fix the technologies.

I feel that I’ve been very fortunate because I’ve gotten to see a very broad spectrum of the industry. Of course, my fundamental principles and what I will probably ever be known for is that it’s always back to the vision of that transcendental platform.

What we’re creating should be completely barrier free. The word accessibility in this case, when it comes to the web, it’s simply access for all; all people, all operating systems, all user agents, all devices, all abilities. It’s just part of the bigger picture, is how I see it.

That’s a little bit about me. I write books and articles and I’ve done a lot of that, too. My focus now really is on attempting to kind of coalesce all of this various work we’ve done to an actual model. That’s really emerging as what is being called the Open Web Platform, and I think that’s a really exciting place to be and we’re seeing a lot of great things coming to bear because of much more community outreach and activism.

Derek: Definitely that’s the case. Things have clearly changed over time. I think in the very beginning of the web we didn’t have the long term view because we couldn’t have the long term view. Now we get to balance all the short term gains and the long term vision of things.

You make a really good point. It’s sort of a natural evolution of what web technologies are, what the web stack is, and how it all fits together into creating something that’s bigger than all of us and that just fundamentally works and provides access to everyone, regardless of what they’re using or what their abilities may be.

It’s important that we call continue to bring that message forward. Thank you for everything that you do and have done and continue to do. It’s always a pleasure to work with you. That’s important for us to keep doing this stuff. You’re a leader and always have been.

Molly: Thanks, Derek. You are of the same ilk and I have great respect for the work that you have done throughout the years, diligently learning. It’s been fascinating to watch my friends grow, too. That’s another thing that we don’t necessarily always talk about.

We’re talking about educating other people through AccessU, the outreach we do, the work we do, but one of the things that is greatest, I think, and most remarkable is how wonderful it is to see the growth of the people around me and what sparks their interests and how they move through their careers.

It’s becoming very fascinating to see the industry mature a little bit. It gives me great hope because there are still some very, very strong minds that came out of all that time of chaos of the mid to late ‘90s, I guess would be really when Web Standards Project emerged for the first time in ’98 because there was just browser chaos beyond belief.

Now we have even more browser chaos, but better inter-op overall. It’s a very fascinating thing to see. I was thinking of my very first job as a web designer. We’d talk in terms of a three to give page or 10 page site. It would be one person doing some HTML. If they were exceptionally lucky, they had a clue what they were doing. If they didn’t, it still worked. This is what I think was really amazing.

We’ve come from that sort of slipshod, democratic, creative, anything goes environment into where at least for the professionals among us, we have created in less than 20 years something that has deep art, deep science, and deep knowledge that is required of those of us who do the work. It’s incredible to see that we’ve been able to adapt so quickly to it and how we do that as individuals. It’s been very fascinating to me.

Derek: Seeing the development of people over time is definitely interesting. That’s something that I think all teachers are really ultimately interested in.

One of the things that any web professional needs these days, I think anyway, is we need that accessibility knowledge. You mentioned sort of the chaotic times that we’ve been through and are in. We still continue down this chaotic path to some extent.

One of the skills that people need is something that you’re actually talking about at AccessU. Your main conference session is CSS related. I know that’s a skill that, put to good use, can be such a powerful tool. I love this line from Uncle Ben Parker from Spiderman, “With great power comes great responsibility.”

One of the things that you’re going to be talking about is CSS and some of the accessibility problems that we actually create when we don’t use CSS correctly. I don’t want you to give away your entire session, but can you give us an example of what are some of the main mistakes or maybe one or two examples that you can give us so that people know what kinds of things you’ll be talking about in the session?

Molly: I think the core issue; there are a lot of different issues. By the way, the title is called CSS Oopsies, in other words things we do we don’t necessarily mean to do that oddly, just like you were saying, cause problems from an accessibility standpoint.

Of course, a lot of this has to do with color and contrast; big issues, right? How we choose fonts, things of that nature I’ll be going through.

Let’s just take a few well known examples just to give a little sense of what I’ll be doing. A lot of it has to do with where focus is and how we help people focus on either the functional pieces of the application that they’re in, or the pieces of information that they want to be reading or interacting with.

Essentially what I see there is that we got into a bad habit because people started removing the lines. I think it was IE that showed the lines around, anytime you used Focus, it would put a visible line that people would then hide that line. The point is that we need not to do things like that because if we are hiding a feature that is an accessibility tool and required by certain people to comprehend and interact with that average site, then you’re causing problems.

We really need to look at focus in CSS, and also we’ll be looking at animations, we’ll be looking at transitions. Anything that moves, blinks, or otherwise causes visual or other problems.

One of the things that I am addressing that I think has not yet been discussed a great deal is it’s become very popular, backgrounds with very, very thin, close striping so that when you move it, it looks like it’s moving. It’s a strange effect and it really is causing people like myself and other people who have photosensitive epilepsy; I get to a site like that and let’s say they’ve used a background like that and then I’m looking at a dress on a shopping site and the dress has stripes and the background has stripes. All of a sudden, everything begins to move visually and I become nauseated and feel the world begin to spin.

People who have sensitivity to these sorts of things have to be aware. We don’t spend a lot of time on what visual things can actually harm people. We’re always talking about, “For the people who are blind, we provide this.” What about the people who can see, but have problems with how that information is interpreted neurologically?

That’s one of the things about accessibility that I think we miss a lot of times. What works for one may not always work for the other. We tend to focus on gnome issues. We have to look outside of that into the bigger world and the realities of just what it means to be human and living and aging.

I’m sure we all can agree. When I passed 40, I lost a certain percentage of my near vision. Past 50, it’s all gone. I can’t see anything a foot in front of my face. These are realities of being of the human flesh.

Whether you have a disability or don’t have a disability, fundamentally these issues will distract or cause users discomfort or problems. That’s really where I’ll be addressing. I’ll be addressing some topics that are normally not addressed, as well.

Derek: Cool. That’s good because one of the things I think that you mentioned, and we all feel this, is that the first reaction when people talk about accessibility is that it’s about screen reader, screen reader, screen reader. We all know that not to be the case, but it is definitely one of the populations of people or groups of people who have a significant difficulty using the web, so it’s pretty natural to focus on them, but there are definitely other groups that we need to focus on. I’m glad that you’re going to talk about those.

One of the things that you just mentioned that I kind of wanted to pick up on is this idea of what’s good for one may not be good for another. That’s a tension that I think a lot of designers and developers feel because they’re told to do things one specific way for a particular group, and then they face other things.

Like you mentioned here, a visual design that might be really good for one particular group of people and simply because of a change in CSS might be more difficult for another group to use. How do you resolve that tension between something being a feature that’s really good for one group of people, but an absolute nightmare for others?

Molly: That’s a very, very tough question. I think this is where, what I was saying earlier about the professional growth and watching people kind of fill their shoes over the years. I’ve watched us start out as web designers and developers and turn into real engineers. A lot of us, we’re ending up having to make those kinds of decisions.

First of all, I think it’s a collaborative decision. Those kinds of decisions should never be made by one person. I also think that the best way to get information about that is to do user testing with the people or the diverse user groups that you are working with to reach. You have to gather real information. You can’t just make assumptions about how people use things.

It goes back to that whole, first of all, that costs a lot of money. You know what? It’s all part of the engineering process, and that’s the difference now. We are no longer just designing and developing. We are engineering. When we are engineering software, especially in the web apps world where we have a lot of interaction and a great deal of complexity going on, what I think we really have to do is we have to put that stuff right into the environment of a wide variety of users will be using and take a look and really see what those differences are.

You have to work through that, and then you have to study it and I think you have to talk about it. It becomes a collaborative solution, and there is no one size fits all. Somebody had a session at SXSW this year, and I didn’t get to see it because I was working the Knowbility booth. I heard the title and I just loved it. It was called One Size Fits None. I thought that was just brilliant. I think that kind of sums up the issue.

Derek: That’s great. I’m going to have to track down that talk. I didn’t make it to SXSW this year, but that sounds like it’s philosophically a great talk.

I like the approach. This sounds crazy, but that actually sounds Molly like you’re advocating that we actually do research.

Molly: You mean actually work?

Derek: Actually do research and test with real people? That’s crazy talk.

Molly: I know, I know. What can you say? I have these ideas.

Derek: Unreal. I wanted to talk really quickly about your workshop, as well. You have a workshop on May 16th, a full day, called Pragmatic Accessibility for the Open Web. That sounds like it’ll be a fantastic full day with Molly.

Can you give us the brief 30 second elevator pitch on your workshop, what it’s about, and what kinds of things you’ll be looking at that day?

Molly: Absolutely. It exactly reflects what I’ve just been talking about, about now looking at this from the point of view of being engineers. It’s not just engineering, but from a professional, a high level profession of art and science. Looking at the entire stack from the core, from HTML 5, extending into ARIA for rich internet applications, working with that. Working with CSS, working with SVG, working with graphics, working with media.

Everything that we do in the stack, and really looking also at that stack as a mature both in the front end and every moving toward this restful, decoupled kind of model where things happen, especially like with node where you can actually create things that happen where there’s very little conversation between application and server. You are basically at that point running a decoupled application.

I’m going to be looking at that entire stack and speaking about the role of the variety of technologies and how they play into that with obviously some focus, pun intended, on ARIA, on aspects of HTML 5, on best practices as we go through that process.

Derek: Cool. It’s interesting; there was a word that you used in there that I kind of picked up on. I find it’s an interesting conundrum in the work that we do on the web because you talked about us maturing as professionals and that we’re in a maturing profession. We’re much more mature than we were. Some of us are never mature, but that’s okay.

Molly: I might be 50, but I’m just not mature.

Derek: Mature in the sense of talking about some of these technologies. ARIA, for example, is still fairly new, even though it’s not. ARIA has been in the works since 2004 or even earlier than that, and drafts started to appear in the 2005 timeframe. Here we are, it’s 2013, and we still don’t have ARIA support for lots of different things. We even have scenarios where we’re seeing problems because there is incomplete ARIA support or buggy or spotty ARIA support.

One of the things that I struggle with is making recommendations where people want to rely on ARIA, but we know that from our experience in testing with real people with disabilities and using different assistive technology that ARIA is a solution that only satisfies some very specific needs. It certainly doesn’t make everybody’s web experience accessible.

I know I struggle with that quite a bit in terms of recommending ARIA as the solution.

Molly: It isn’t. That’s exactly it. Everything you just said could be said about SVG also, except it even has a longer history going back. Here was have, at least with SVG, we have an XML based language where the data is exposed and we could do things with that, but no. We have a whole info graphics movement that has to be in binary format, which graphic representation is of no use to somebody who cannot see that or understand it.

It’s a big conundrum, but I think part of the thing with ARIA right now, and I totally agree, there is no part of the web that’s a magic button. I think you actually helped me kind of identify the core reason for this class at all because it’s really about that. It’s really about getting in there, understanding what the toolsets are, and learning how to make good decisions about a given problem. Again, one size fits none.

I think with ARIA there are some advocates, and Richard himself, the person who is the editor, has advocated or I’ve heard that he’s advocated, “Use ARIA everywhere.” I think that’s not really the best way. I think you have to really think about when you’re using it, where you’re using it, and less is more; where it’s really relevant.

I think people also don’t understand. They think it’s a technology that does something in the browser, but except for live regions and all of that, the role and state is just simply information passed on to assistive technology, not to the user directly or not to the browser directly unless we tap into that in some way.

I think that’s a big issue that people don’t really quite understand where it fits in the stack. We’ll clarify that in that class.

Derek: This has been fantastic. I just have one other question for you, and I’ve asked everybody this, and this is about Austin because there are going to be a lot of people coming to AccessU who aren’t based in Austin, so they’re going to be maybe hitting Austin for their first time. What’s your must do or must see event or place to go or thing to eat or whatever in Austin, Texas when you’re there?

Molly: You know, the thing is there’s so much to do. Let me tell a brief little story from last year, and I think that this puts what can happen in Austin into the frame.

During AccessU, we had a party at a dueling piano bar. We had set it up so that the pianists were there. We had a private party at 5:00 to 6:00, hors d’oeuvres and drinks, and then they opened the bar and people come in and a lot of us stayed.

We had three women who did music and they were signing, so they were doing interpretive signing of the music. We had some audio description and we had some other things going on there that was quite fun.

When the bar opened up and the people from the street are just coming in, couples coming in or whatever just to see what was going on, you have these three women up there dynamically signing and it was great because the two piano players and there were a couple of other people playing music, as well, started picking up on some of the signs. You know how they do call and response? They would do a call and then we’re all responding in sign. It was so much fun. The entire bar was just having a great time.

Everybody in there, whether they were associated with accessibility or not, learned how to have extra fun because that was going on. It was really a blast; one of the best nights I ever had in Austin; so much fun.

I think that no matter what you do, you have to get down to Sixth Avenue, you have to see some of the music, you have to eat some of the food, and Tex-Mex is great and of course, the barbecue. What can you say? We’re planning to all go to barbecue, so that’s real important.

Derek: That’s excellent. It sounds just like all the AccessU events that I’ve been to. It’s exactly the same; a great experience and a great chance to hang with like minded and differently minded people and experience the local culture. That sounds great.

Thank you very much again, Molly. This has been great. Have a great AccessU and I’ll catch up with you again later.

Molly: Thanks!

Derek: And, there you have it. It’s time to get yourself registered and head to Austin to see Molly and all the other great speakers. Again, it’s the 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.

[Outro Music]

Google Docs Accessibility with Shawn Lauriat

Feel free to download the podcast:

• Interview with Shawn Lauriat, m4a format
• Interview with Shawn Lauriat, mp3 format
• Interview with Shawn Lauriat, .ogg format

Transcript

Interview Summary

Derek: You’ve probably heard this before: “Accessibility is easy.” And there are parts of accessibility that are easy. But at the same time, some people are tackling really tough problems, like Shawn Lauriat who works on Google Docs Accessibility. We talk with Shawn about screen reader versions, support for other types of assistive technology and great food and music to try while you’re in Austin. 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.

Let’s go…

[Intro Music]

Derek: This is Derek Featherstone with Simply Accessible and I have Shawn Lauriat on the line with me. Shawn is one of the speakers at the upcoming AccessU in May happening in Austin, Texas, being put on by Nobility.

Shawn, how are you doing today?

Shawn: I’m doing well. How are you?

Derek: I’m doing very well, thanks. It’s a pleasure to have you on here talking with us. I know we have a lot of things to talk about. I always like talking with people that are working on really tough problems. I think, from what I can tell, your background and the things that you’re working on right now are pretty tough problems.

Your session is all about making accessibility work for complex web applications. Maybe you could tell us a little bit about yourself and the work that you’re doing, and how that kind of relates to your session. Why should we listen to you in terms of your topic, why are you a good person to listen to for making complex web apps accessible?

Shawn: Sure. I’ll do my best to answer that question. Basically I’ve been working in the web world itself for awhile, since about 2000. I started working with accessibility specifically about 2002, so I have a little over a decade with accessibility experience.

However, since I’ve moved to Google Docs I’ve seen some challenges that are quite new for me. It involves some very complex pieces of coding, pieces of interfaces themselves, and really bending the web to do things that it wasn’t really designed to do in the first place.

Making all of that work with assistive technologies, making all of this work usability wise for people using different input devices, people with different levels or eyesight, people with different levels of cognition, these are all things that are super challenging in Google Docs, but hopefully I’m making things better there.

Derek: That’s cool. It definitely is a complex area to be in. Maybe what you could do is share a little bit more about some of the real difficult challenges. You talked about a few different things there. You’re talking about doing things with the web that it wasn’t really designed to do. Can you tell us a bit more about that, what do you mean by that?

Shawn: Sure. I’ll go into a little more detail during my talk with some concrete examples on everything.

Specifically with the documents editor, which is where I started at Google as just a regular engineer on the documents editor, there are certain concepts in there that are not really cohesive to how web standards work. The concept of pagination with margins, headers, footnotes, page numbers, and such, just the rendering that is expected to work and look the same as it does when you print the document as it does when you’re looking on the screen, whether you’re looking at it in Firefox, Internet Explorer, Chrome, or Safari, it really presented some challenges.

We’re basically using the dom, using HTML and CSS in order to render the page visually on the screen. However, the actual dom itself, which is a little frightening to look at and a little intimidating at first, but once I realized and was gently introduced to the concept of this is purely for visual rendering, this may as well be rendered in SVG, it could be rendered in Canvas, it could be rendered in Flash (but we’re not going to do that one,) it could be rendered in anything.

It’s not actually there for the typical dom structure, which is defining the actual structure of the page. So you have paragraphs and you have spans for specific spans of text that you want to actually effect. You don’t have that with Google Docs rendering, because it’s there specifically just to work the dom into something that will look like something that you would expect a word processor to render.

Having that work with things like screen readers, which typically with web applications are looking for cues from the dom as to where they are, that presents some challenges. We’ve put in place a solution, which I’ll talk about in more detail during my talk, but that works decently in the current iteration. I’m hoping to improve that in my current work. It works decently, but only because of how we’ve introduced another layer of logic in there so that we’re basically doing another level of rendering but instead of it being visual it’s an audible representation.

That’s not the best description, but that’s the fastest description.

Derek: So you have two separate structures. One that is exclusively for the visual side of things, then you have another that’s representing things for assistive technology users.

Shawn: They’re both coming from the same place, but the dom structure itself is used specifically just for the visual representation. We’re doing something completely different for screen reader support. Basically just using ARIA Live regions for reasons that they were not invented, which is as a text-to-speech engine.

Derek: That’s interesting. It does sound kind of complicated. And that’s okay, we’re all trying to do things with the web these days that are going beyond anything that anybody ever imagined when they started putting documents up on the web in the first place. Originally it was all about reading documents and not necessarily about creating documents with rich tools like Google Docs.

One of the things that just popped into my mind as we were talking about it; you mentioned specifically screen readers. One of the things that I’ve seen and heard in the past in terms of Google Docs accessibility in general is that it’s not accessible. It’s been pretty obvious to me that the teams at Google are working to continue to improve accessibility because it’s kind of an important feature, particularly for organizations that are mandated to be accessible and they need to have accessible technology. If you want to take on some of the people and corporations that are already in lots of organizations in terms of office productivity software, then you need to be accessible.

I guess what I’m wondering is can you give us a bit more insight into strategies in terms of what is considered accessible from a Google Docs perspective, whether we’re talking about documents, or spreadsheets, or presentations, or any of the different components? Particularly with respect to different types of screen reader support, I’m wondering are you looking at specific screen readers, do you try to make it so that it works with all screen readers? Would somebody on a Mac using VoiceOver be able to be successful with Google Docs?

Shawn: I’ll answer that in a few different pieces, because there’s a few different questions in there. The first question that I pulled out of that was, “What is considered accessible for Google Docs?”

From my perspective, basically things are accessible when everybody can use the application. It doesn’t matter if you use a screen reader, it doesn’t matter if you have some kind of motor impairment, if you can’t use a mouse or can’t use a keyboard, or whatever it is even if you just have a really old lousy monitor and the contrast is horrible. You need to be able to use the application no matter what the circumstances are. That’s my own measurement of accessibility.

With screen readers specifically, we do support four different screen readers. We try to make it so that it should work with any modern screen reader that supports ARIA and supports general modern web standards. Same with the browser support; anything that is modern we’re going to support. The ones that we have actively tested and support officially to world as, “hey, yes, we support these,” are JAWS, of course because it’s used all over the place, but the most recent version because going back there is some very broken support with ARIA. NVDA actually works quite well and VoiceOver works quite well. Of course, Chrome Vox, which is just a web based screen reader, works very well.

So we are actively trying to make it anything using modern standards will work. The biggest challenge that we’ve had is just in getting it so that it’s easy to get up and running with Docs. That’s one of the big challenges that I’m facing right now. While you can make things work and you can access it with VoiceOver in Safari or you can access it with NVDA in Firefox, if you don’t know how to set it up it just looks completely inaccessible. That’s something that I’m hoping to fix.

We just released a new Quick Start guide at CSUN at the end of February. Hopefully that helps, but I’m also working to make the application itself a little easier to get up and running.

Derek: Cool. Without going into too much detail, it sounds like when you say set up and get things up and running with Google Docs, is it configuration options and things like that or is it something else?

Shawn: There are a couple of pieces. You have to specifically enable screen reader support right now. There’s a major performance hit that happens when you enable it, but if you’re using a screen reader it goes from zero support to it works. User perception wise, it works quickly enough. But it is enough of a performance hit that it would hit everybody. I really want to fix that issue before we just enable it across the board by default.

It does save that as a user preference, so once you do enable it in documents, for example, it will be enabled in presentations, it will be enabled in spread sheets, and it will stay that way until you shut it back off.

The other piece is that specifically with JAWS there is some configuration that you have to do with JAWS itself to get it to let us do what we need to do on the application side, because it really wants to look at Docs as a form, it wants to have the virtual cursor there. All of these things basically make it so that we’re not getting the keyboard that we need to work and it’s not listening to the live region updates that we need to communicate changes back to you.

Derek: I think you mentioned off the top that you’re really targeting the most recent version of JAWS, so right now you’re basically targeting JAWS 14?

Shawn: Right.

Derek: Here’s a question. At some point JAWS 14 wasn’t the most recent version, so at some point JAWS 13 was the most recent version. Were the things that you were doing back then, or the type of work that you’re doing right now, was there any point in time when JAWS 13 was the most recent and it was working in that scenario, or has it been something that’s just sort of more recent with JAWS 14?

Shawn: It was working with JAWS 13, however there were inconsistencies in how it worked with live regions between 13 and 14. When 14 actually came out we had to update our end so that it would work with 14 because Docs would just stop working until we fixed that bug. Also, there were some inconsistencies with how it would get up and running, so it was incredibly to have a consistently good experience with JAWS 13.

Derek: Right. I think it’s difficult to have a good experience with JAWS in many cases in the first place, so that’s not necessarily something that’s completely unexpected.

Shawn: That’s very true.

Derek: I guess I’m sort of wondering at what point if things are working reasonably well now with JAWS 14 and they’re not compatible with JAWS 13, we’ve still got a group of people that are potentially left out because they can’t use their particular version of the screen reader because they haven’t an upgrade authorized yet or things like that.

I’m also thinking about what happens when JAWS 15 is the most up to date and most modern. Is that something where you’ll continue to support what you currently have in 14? Will it be that you’ll be supporting more than just the most current moving forward, or has that even been decided yet?

Shawn: We follow pretty much the same stance with browsers, so it will be the most recent couple of versions. When JAWS 15 comes out, that doesn’t mean that 14 will suddenly stop working. It’s the same with 13; it should still work fine, it’s just not going to be as smooth of an experience and it’s not going to be where the bulk of our attention is put.

Derek: Okay. So we get a baseline level of working, but it may not be as enhanced or as smooth as the most up to date version.

Shawn: Right. We also try to keep our documentation up to date, as far as how to get up and running with different screen readers. For Docs, as an example, we have a page that outlines exactly the different kinds of things that you need to do for each of the screen readers because the set up for JAWS obviously is not going to apply to the set up for VoiceOver. As new versions come out we try to keep that up to date so that if there are any changes in that process we want the users to know exactly how to get up and running.

Derek: That makes good sense. I know that’s something that we’ve tried to balance in the work that we’ve done. We’ve done quite a bit of work on some reasonably complex web apps as well, and one of the things that we always try to do is provide those orientation guides just as much as we provide help so that people know to go in and review this information before they try things instead of waiting until they’re getting stuck. I think that’s a pretty forward thinking way to approach it. It’s really good to hear that you’re doing that.

We’ve only talked about screen readers so far, and that’s really just one type of assistive technology. I’m curious to know if there are things that you’re looking at with other assistive technology. I know we see a lot of other assistive technology in our work when we’re working with people with disabilities and clients that have people with disabilities on staff that are using different pieces of software.

I’m curious to know how things work or if you’re at the point yet where you’re really focused on the screen reader side of it because that’s such a huge need. I’m wondering about things like Dragon Naturally Speaking and voice recognition software, and how people with different mobility or dexterity impairments would fare with using Google Docs with their assistive technology.

Shawn: There are a few different things that we’ve been looking at. I obviously can’t say, “We will support this in the future on this date,” or anything. Specific features and dates, I can’t really offer.

I do know and I can say that Braille displays, for example, you can technically use Braille displays with Docs. It’s not something that is completely supported right now, so the experience is definitely not ideal.

Screen magnifiers pretty much the same thing. Part of the issue there is that the blinking cursor that you see on the screen is not an actual cursor, it’s a div that’s going on and off, which screen magnifiers don’t really have much that they can hang onto at that point. We’re working on those challenges.

As far as speech recognition, that is something that we are working on. I’m not sure what the timeline is or exactly how that will work. I’m not working on that one specifically, but I do know that it is being actively worked on.

Derek: That’s good to hear. It’s something that we’re certainly seeing a lot more of. Given the massive amounts of time that everybody spends behind computers, there’s more and more cases of repetitive stress injuries and carpal tunnel syndrome and things like that.

I know I’ve made use of it myself in the past when I’ve had an injured wrist from doing too much gardening and things like that. Having access to be able to create a document with voice recognition technology is good, but also being able to command the menus and all the different functionality that’s on the screen with voice recognition software is of huge importance to the people that rely on it.

I know one of the things that we’ve seen in the past, I know we’ve looked at Google Docs and I know that in many cases we uses ARIA to create buttons and have buttons on the screen, even in Gmail the compose new message button isn’t actually a button, it’s usually a span or something that’s been styled to look like a button, and then in the proper way, given some button like properties by using things like ARIA’s role attribute.

One of the challenges that we face and something that I’m hoping you can take forward to the team, if they’re not already working on it, is just the use of plain old buttons. Only because the ARIA buttons right now, or a span or a div with the role of button, doesn’t really give any access to anybody other than screen reader users. A voice recognition user, if they say something like “click button,” the voice recognition software doesn’t actually recognize those fake ARIA style buttons as an actual button and it makes it much more difficult for them to use.

Hopefully that’s something that can be worked into the mix somewhere. I know that’s probably a point of contention that has been brought up before in the Google Docs and Google Apps world. I’m interested and hopefully we’ll see some progress there. I’m not sure if you’ll be able to talk about that during AccessU in your session or not, but that would be on the top of my mind.

Shawn: That was something that I was planning on bringing up, just because with the different toolkits that we use they do tend to like render things as divs, role button with spans in the middle, and have everything be fake but acting like it.

However, because it’s built into the toolkit itself that way, it’s a little more difficult to “change the world” as far as that goes. Changing the Docs world I can pretty much do from here, because that’s where I work. But changing the entire Google world takes a little more.

Something that I would like to see is the assistive technologies that don’t currently recognize ARIA having some better support in there.

Derek: Absolutely. I know that’s a limitation of voice recognition software right now. Unfortunately, it’s a limitation. I wish that it was something where they got on board and started implementing ARIA support for things.

Shawn: I could imagine that it would be very helpful also if you’re in Google Docs and you have the font dialogue open, say you’re adding some fonts to your document, once you’ve selected things being able to say, “close the dialogue,” and have it go, “Okay, you have a dialogue open so I’ll close that.”

Derek: I think we would all love that. I guess that’s where we sometimes see a conflict between technologies. Just as you said, it’s much more difficult to change the toolkits in the entire Google world, you really only have a domain of control. Exactly the same problem is faced with assistive technology vendors and convincing them and having them work on this type of stuff is probably just as big of a challenge as changing stuff at the toolkit level.

Shawn: Absolutely.

Derek: I love the way you phrased it, to be honest with you, that changing the world is much more difficult. I believe that that’s the kind of things we’re doing anyway, we’re trying to change the world here. I think that’s kind of the appropriate way to think about it. Nobody said that it was impossible, just that it was going to be hard. Let’s definitely both keep working on that front.

Shawn: Definitely.

Derek: Some questions about Austin, Texas. You were based in Austin for several years, correct?

Shawn: I was, yes. I lived in Austin a couple of times. I lived in Oakland in between. I was in northeast Austin for about five years.

Derek: Excellent, so you’re familiar with Austin.

Shawn: I am, yes.

Derek: One of the things that we’re trying to do is get people’s advice, because there are a lot of people that come to AccessU that are not from Austin, they’re from all over the country and in many cases all over the world, we have people fly in from overseas even. If you could pick one thing, what’s the one thing that you would recommend to people that they do or see while they’re in Austin? And don’t say the bats, because we’ve already had that one and we need some variety.

Shawn: I’m sure the bats and the barbecue have both already been mentioned. For myself, one of the nice places that I like to go to in Austin, which it’s hidden fairly well but once you find it The Elephant Room is very nice to check out. They have some great jazz going on down there and a nice little bar. It’s just tucked away downtown. You’re going through downtown Austin and you go down and there’s this just really nice environment to hang out and have a drink.

Aside from that, Veggie Heaven I highly recommend to anybody. It doesn’t matter if you’re a vegetarian or not, they have extraordinary good food.

Derek: That sounds fantastic. Are you planning on going to those places while you’re in town for AccessU?

Shawn: If I can swing it, yes. I’m hoping to.

Derek: Okay. I’m wondering should we give the addresses to people. But if we do, does that mean they’re going to be overrun and you won’t be able to get in at either of the places?

Shawn: Veggie Heaven tends to be fairly popular, so if we show up with a crowd of 20 that will be most of the restaurant, I have a feeling.

Derek: We’ll post links to both of those places – Veggie Heaven and The Elephant Room – in the show notes and in the transcript.

I wish I could be there at AccessU, it sounds like your session is going to be great.

I hope everybody else agrees. It’s definitely a complex problem and it sounds like you have some good people working on it. I love the way that you’re thinking about accessibility and your philosophy.

Thank you so much for taking the time with us today, I really appreciate it. Enjoy your time at AccessU in Austin.

Shawn: I appreciate it. Thank you.

Derek: Make sure you catch up with Shawn and all the other great speakers in a few weeks in Austin. Again, its AccessU — get all the details at knowbility.org
– that’s k n o w b i l i t y dot org.

[Outro Music]

Links from Shawn’s Interview and Helpful Resources for Google Docs

Veggie Heaven: http://veggieheavenaustin.com/Veggie_Heaven_Menu.php

The Elephant Room: http://www.elephantroom.com/

Google’s general support guide: Google Apps for Blind and Low-vision Users

Google Docs screen reader start guide: Use Google Docs with a Screen Reader

An Interview with Karl Groves

Feel free to download the podcast:

• Interview with Karl Groves, m4a format
• Interview with Karl Groves, mp3 format
• Interview with Karl Groves, .ogg format

Transcript

Interview Summary

Derek: What do Vikings, user testing, forms and BBQ have in common? Karl Groves. Listen in on this conversation with Karl and learn more about his upcoming workshops at AccessU.
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.

Here we go…

[Intro Music]

Derek: This is Derek Featherstone from Simply Accessible and I have the distinct pleasure of talking with Karl Groves, who is one of my coworkers here at Simply Accessible. We’re talking about getting ready for AccessU coming up in Austin, Texas, May 14^th, 15^th, and 16^th, put on by Knowbility. We wanted to take some time to talk with some of the speakers and help everybody out there that’s listening understand what the conference is about and why it’s one of the (if not the very) best accessibility conferences. If you’re brand new to accessibility or if you want to go deep into it, this is the place to be.

Karl, we’re going to talk for about 20 minutes and have a good time doing it. How are you doing today?

Karl: I’m doing excellent today. Thank you.

Derek: That is always good to hear. Karl and I work together, so we get to talk like this every day and Karl is always excellent, so today is no exception.

Karl, I know you pretty well, but there are some people out there listening that probably don’t know you even though they should. Can you give us a quick rundown of who you are and your approach to accessibility? Then we can take it from there and move into some of your talks that you’re going to be doing at AccessU.

Karl: I actually got into accessibility by way of being a web developer. I started my career in web development, somewhat ironically, in the DC area right around the time Section 508 started becoming enforced. It came out in 1998 and then they had a two year grace period. I think it was probably that two year grace period that everybody sort of had it out of their minds, and then all of a sudden here I am looking for a job when everybody did start caring about it. So I had a need to actually know this stuff because I was trying to get jobs in the DC area doing web development. That’s how I got into it.

Honestly, I knew literally nothing about it. At interviews they would say, “Is this stuff such-and-such compliant?” and I’d say, “Yes,” because I wanted the job. I really didn’t know much about it at the time and I needed to, so I found a whole bunch of resources out there. UseNet was still around, also the WebAIM list, which is the first time Derek and I actually interacted with each other, about a decade ago now.

That’s really how I got into it was because I had to. So I have a developer’s perspective for the most part with it and that’s where I really come from.

Derek: I know we’ve talked about this a little bit before. You also in some of the jobs that you’ve had previously, you said you had worked at an organization where your entire focus was on the user and you had a very user-centric view. You had that user experience flavor, probably before it was even called user experience. Can you tell us a bit about how that comes into your history and also how that influences your work now?

Karl: It’s funny, because I got a job as a web developer for a small usability consulting company and the reason was because the owner of the company was doing usability consulting but didn’t do much development, and he had lots of calls for people to say, “You’ve told us what’s wrong. Can you fix it for us?” He started realizing that there was some business value of being able to do that in-house as opposed to farming it out.

About the time that we were talking about my doing sign work for him, he got a very big contract with a sub-center, they had 16 centers within the National Cancer Institute and one of those centers had hired him to do this website, so I came on full time.

In that process, over a period of about five years, we did lots of usability work and usability studies. I would do lots of functional prototypes for revised designs and stuff like that. It really did get to a point where I was doing as much as usability work and IA work as the other non-developers on the team. It was really eye opening, because you realize that, yes, there is somebody on the other end of this.

That definitely helped shape my perspective as a developer that I do need to make this for people. The Section 508 compliance stuff stopped being so much about compliance and it started becoming more about usability for everybody.

Derek: That’s cool. I love that perspective, because I think a lot of us – I know when I first started as a developer – don’t naturally think about what the consequences are of some of the code that you create. Then when you actually start working with people that are using the designs and the prototypes and/or the full blown sites that are fully coded and production ready, it’s not until you actually work with some of those people trying to use things that your mind gets totally blown and you shift into this other mode where you start to think a little bit more about the ultimate consequences of what you do on how people can actually use things.

Karl: It’s funny you say that. I started out watching a lot of the usability studies that we were doing from the observation room and taking notes. That’s where I got to see real people, not geeks and developers like the rest of us. When you’re talking amongst your friends when you work in an industry like this, all your friends are probably power users – my own wife is a power user. It’s one thing to see somebody who knows a lot about computers work on something versus a person in the general populous who is probably actually going to use your site instead and seeing the difficulties that they can have. It was really eye opening for me, for sure.

Derek: It is, I think, for most people when they experience that.

You have a few sessions coming up at AccessU and I wanted to give everybody that’s listening a little heads up as to what’s coming and what they should expect from your sessions. One of your main conference sessions is called Viking Accessibility, the Warrior’s Approach to Hands-On Testing.

I think you’re probably really well known for your thoroughness and accuracy and everything that surrounds testing. I’m really kind of excited to see that you’re doing this. This is a hands-on lab type workshop scenario for that one, correct?

Karl: Yes. That’s going to be a hands-on testing session with a lab, so there’s going to be desktop computers there for everybody and we’re going to actually go through some specific scenarios of testing.

I think the whole Viking thing is sort of funny, especially because of the many misunderstandings about Vikings. Did you know that Vikings actually weren’t dirty like Hagar the Horrible, the cartoon character that we see in the comic strips? There’s an Arab scholar who wrote on the Vikings and did some historical work on the Vikings and they were actually well known for being clean. They used to carry clean clothes when they were on their excursions to go conquer. I thought that was really funny to hear.

We all know that the horned helmet thing is sort of a myth, because that’s just bad for fighting. But the cleanliness thing I thought was really funny.

Derek: I had no idea.

Karl: The thing that I like about the whole Viking persona is that I look at it more like preparedness. Like I said, they were well known for being dirty and monstrous and all that, but I don’t think that was really the case. But if you read through, there’s this air of preparedness. They were required, for instance, to carry a weapon with them at all times because you never know; they would have to be prepared.

They were also serious craftsman. If you’ve ever seen any of the ships that they built with the dragon’s head on the front of the ships, I think that was incredible. I think I’ll keep the whole Viking thing that Elle gave to me, because I think that we’ll see that in this lab too, this idea of being prepared to do a thorough job. And we’re going to provide tools and hints, and I’m actually going to provide an idea on an accessibility tool that people may not be well aware of that I think does a phenomenal job. It’s actually mostly in the hands of developers and not accessibility people.

Derek: That sounds cool. That’s one of the things that I know we’ve seen in our work is that a lot of accessibility issues tend to be process related and there are things that when the code is in the browser it’s already too late. We want to do as much as we can to move accessibility earlier in the process. So I’m interested in hearing a developer’s tool would actually help improve accessibility.

Is there anything in there, like a little teaser that you can give us in terms of what kinds of things that tool will help you to do earlier in the process that would be really powerful for a developer to use?

Karl: The thing about this is that it really couldn’t be simpler in terms of finding the problems along the way. That was one of the things that previously when I talked at AccessU – this is actually my fourth year – it was all me talking, me lecturing, me saying all this really thorough stuff that I think is great but that really went over people’s heads. Although, I always got great ratings from it, I never felt like people were walking away as prepared as I’d like them to be. That’s why I changed it this year.

The one thing I wanted people to be able to do is just to be able to do things that will let them find out firsthand exactly where the problems are in the most simplest and quickest of manner. Hopefully this can happen upstream with the developers before it even gets to QA.

Like you were saying, that’s really where we want it to be, because once the train has left the station on this code you’re not going to pull it back. If we can get everybody testing as simple as possible, as quickly as possible to get the really high level, high impact things discovered first, I think that’s going to be better from both a project perspective and from the user perspective.

Derek: That sounds like a really good overview in terms of the three hour workshop. You also have a full day workshop called From Stem to Stern, in terms of building and designing accessible forms. I think that’s a really interesting one because forms are so critical to pretty much every interaction online.

What’s the idea or what’s the goal behind the full day forms workshop? I want to dig a little bit deeper on this one. What’s the objective, what are people going to get out of it by the time they’re done that day with you?

Karl: There’s a whole bunch of things dealing with forms that you have to consider, not only when you’re designing them and producing them, but just the whole concept of what the form is going to do, what are the business requirements for it, all these things are really important considerations.

We’re going to be talking about creating the forms, how forms should be laid out, how we can allow users to fill out the forms more effectively. This is for all users, of course. More efficient, more effective, error resistant for lack of a better term, meaning we’re going to figure out ways to allow people to avoid errors in the first place, but also recover them from effectively.

We’re going to be talking about everything from simple approaches for layouts and labeling to much more advanced stuff like validation and feedback.

Derek: Literally from stem to stern everything that people need right from the design stage where we’re talking about layouts and different things that people need, all the way through to the actual building.

I’m not sure whether this will fit in your testing three hour workshop or in the full day, but are you going to work in a whole bunch of stuff on testing of forms?

Karl: Yes. We’re going to make sure that as we’re creating these things that they work properly for all users. There are lots of newer techniques that are out there for creating stuff, we want to make sure that they work in all the assistive technologies.

We’ll talk about some of the ways that certain features work well for assistive technologies, whereas they don’t work for others, and how to test for that and check to make sure that those things are working for all users.

Derek: Nice. I just want to clarify here. When you say different assistive technologies, what different technologies are you going to bring into the workshop?

Karl: We’ll actually be talking about screen readers. Obviously that’s what people think of when they think of assistive technologies. But also different types of screen readers, different versions, voice recognition, and screen magnification software as well. There’s going to be lots of implications for usability for all of these different populations depending upon how you can structure forms, what kind of markup you use, how you lay them out, and those sorts of things.

Derek: That’s cool. I know that’s one thing that we’ve seen in our work before is a significant difference in terms of things that work really well for one piece of assistive technology and don’t necessarily work for another. I guess you would say that more holistic approach where we’re taking into account much more than just screen readers is a critical piece to the big picture.

In that full day then they’ll have the opportunity to test forms, to go through all kinds of different concepts in terms of layout and design. I know one of the things that you and I have talked about before is when we get into that error state with a form we need the ability to easily use those error messages and validation messages to correct those errors.

One of the things that we’ve also talked about before is the entire concept that an ounce of prevention is worth a pound of cure. I’m thinking that you’re probably going to talk a little bit about that, just because I know you and I know you’re going to build some of that in. Do you want to talk about that for a few minutes?

Karl: We were talking about this recently with what we’re doing with a client that we’re working on now. There’s a form field that comes up within a modal dialogue, for instance, and there’s no skip navigation to this thing. You sort of get a picture that this is already sort of problematic, but then you actually get to the form and it’s only one field in this form.

You get to the labeling on this one field and there’s no label. You get there with the screen reader and it just says “edit text” on VoiceOver and JAWS. You get to it and you have no idea until you start using other commands to read adjacent text to find out what’s going on.

A country specific postal code is what they’re looking for and they’re requiring a certain amount of characters and spaces. If you do anything other than that then you’re not going to be able to submit the form. And then when you do submit the form it will allow you to submit it, but it won’t actually do anything for you. When you submit the form then an error message appears, but because the page itself posts to itself you actually have to go back through all of these links, and I think there’s somewhere on the order of 75 or so links just to get back to the form where you were to get to the error message. It’s really challenging.

That’s one of the things that a lot of people don’t realize when it comes to forms is that the first thing that we want to be able to do is make sure people don’t commit the error in the first place. We need to make sure there’s a good label, we need to make sure that any special formatting or any special requirements for each individual field would be disclosed to the user so they know what they’re doing so they don’t have to go through all this stuff to find their error and figure out what the problem was, they can type in the requisite information in the proper format, submit it and move on.

That is definitely a very big component to this workshop is just making sure that we’re allowing people to avoid the problems instead of how we’re validating and all that stuff. Allowing them to not even make the error in the first place is really important.

Derek: I think that’s exactly it. It needs to be that way and I think that’s something ultimately when you focus on that you’re not focusing on whether or not the form is technically coded correctly or you’re validation messages are coded correctly, you’re actually worried about whether or not they’re going to know everything that they need to know in order to be able to fill out the form in the first place and do it without error.

That’s really taking things to a different level. That’s not about compliance, that’s about how easy this thing is to use. I think that perspective is something that I’m always happy to hear more about, because too often it seems to me that people think that it’s all on the developers and it’s all about the code. In reality it’s much more than that.

Karl: And it’s not just an accessibility thing either. In this type of scenario that I was referring to, this is going to be the kind of thing that’s really helpful for mobile users. We know that mobile use is exploding and that people talk about what they refer to as situational disability, meaning that in a specific situation you’re experiencing something similar to what a disabled person would be experiencing.

On a mobile phone, for instance, you’re only getting a very tiny view of the screen, you may have problems with focus. I’ve been using phones for a long time, but I’m still probably the slower texter in the world. These are the kinds of things that are beneficial not just for persons with disabilities, but for all users.

Derek: I think that’s something that we’ve probably seen before and I think it’s a huge benefit for people that are looking to make accessibility a part of what they do. This is not an investment in what everybody seems to think of as a small population. It’s actually an investment in improving the user experience for everyone. Very cool.

Any other thoughts about the workshop or things that you want people to know about either one of your talks?

Karl: I think that both talks are going to be hugely beneficial for people who are just getting into accessibility. The accessible forms toolkit is going to have some geek-speak in it, but nothing that is going to be beyond basic HTML and CSS knowledge. We’ll talk conceptually about some javascript stuff, we’ll even show some of that sort of stuff. But it’s not going to be over many people’s heads.

The testing one is going to be hugely beneficial for developers and QA people. I would encourage anybody who is thinking about these sorts of topics. If your site has a lot of forms then you’re definitely going to want to make it to the workshop. If you have to do testing or validation or ID and V on your stuff, or stuff that’s delivered to your company or agency prior to acceptance, then I think that’s beneficial for people as well.

Derek: Excellent. So you’re going to be in Austin for a good three or four days. What is your must-do or must-have thing while you’re in Austin? There are a lot of people that aren’t from Austin and we want them to make their way to Austin from everywhere. What should they be looking for as they’re visiting?

Karl: I absolutely hate myself if I leave Austin and I haven’t been to The Salt Link.

I think of The Salt Lick as the Disneyland of barbecue. If you go to the original Salt Link there’s this huge parking lot and all of these cars. I always think maybe they should put up little signs, “You’re in the Scooby-Doo zone,” or whatever because it’s so big. Then you walk in there and the barbecue is just phenomenal.

Like I said, I’ve been to Memphis many times, I’ve been to St. Louis, I’m sort of a barbecue aficionado, and I think The Salt Lick’s ribs are the best ribs I’ve ever had. Of course, they do have the standard Texas barbecue stuff, lots of beef based stuff, brisket and all that. But I love their ribs, and they have both beef ribs and pork ribs.

The other one I like, last time I was there I also went to Iron Works, which is down by where they have SXSW. Iron Works is really good. Last time I was there, you can buy their ribs and bring them home to cook them or you can buy their rub, so I bought their rub and Jen made some ribs.

That’s the big thing for me.

One more. One of my favorite places, Jim Thatcher took to a place called Esther’s Follies. Have you ever been there?

Derek: I have not.

Karl: It’s in the downtown bar area. This place Esther’s Follies is really great; it’s a live stage comedy review. It’s not really like a standup thing, they have skits and stuff like that and they do a lot of political satire. It’s great because it’s non-partisan political satire. You can tell that they’re more liberal than conservative, but they make fun of everybody and it’s just hilarious.

Derek: That sounds awesome.

Karl: Those are my favorite Austin things.

Derek: Thank you very much, Karl, for taking the time. Have a great time at AccessU.

Karl: Thanks a lot.

Derek: There it is. Karl actually worked in a reference to Hagar the Horrible. Get yourself to Austin for some great BBQ and AccessU.
Get all the details at knowbility.org – that’s k n o w b i l i t y dot org.

[Outro Music]

Links for places mentioned in the podcast

The Salt Lick: http://www.saltlickbbq.com/

Iron Works: http://www.ironworksbbq.com/

Esther’s Follies: http://www.esthersfollies.com/

An Interview with Lainey Feingold

Feel free to download the podcast:

• Interview with Lainey Feingold, m4a format
• Interview with Lainey Feingold, mp3 format
• Interview with Lainey Feingold, .ogg format

Transcript

Interview Summary

Derek: In this episode, we talk accessibility with Lainey Feingold — a lawyer that specializes in accessibility related cases. We’re running an entire series of podcast interviews with a number of great speakers for the John Slatin AccessU conference. We talk with Lainey about her work, about structured negotiations and some of the details of her talk at the 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.

Let’s get to it.

[Intro Music]

Derek: This is Derek Featherstone with Simply Accessible and I have Lainey Feingold with me today. Lainey, how are you doing?

Lainey: I’m good. How are you?

Derek: I’m doing very well. Thanks. We all know that people are getting prepared for AccessU, coming up in May in Austin, Texas, run by Knowbility with lots of different partners, sponsors, and wonderful speakers. We wanted to take some time today to talk to you, as you’re one of those speakers; you’re a standby at AccessU.

You’ve been there and done that several times, and I know your talks are always really well received. I wanted to give the audience a little bit of a taste today of what they might get when they come to see you speak and talk about a few of the things that we see going on. The title of your talk is the Legal Update for 2013, correct?

Lainey: Yes.

Derek: What’s the high level overview of the session, for people that are listening and haven’t checked out the details on the site yet?

Lainey: I sort of see myself at AccessU (and also at CSUN) as sort of an ambassador from the legal world. Every year there’s more stuff going on legally with digital accessibility and I see my role as being able to put it in layperson’s terms and just let people know how the law is impacting this whole field of digital accessibility that we’re all so committed to.

Derek: That’s cool. I think that’s an important piece, because I know one of the questions that our clients always have is, “What legislations are there, what are the legal ramifications, what law even applies to the stuff that we’re doing?”

I know one of the things that we certainly feel, and we’re probably not the only ones that feel this, is that one of the responses that we often see when we see legal cases coming up in the news about web accessibility and one of the questions is always that the person that the defendant is usually trying to say in some way, shape, or form that that particular piece of legislation doesn’t apply to the web. My feeling is that they’re not saying, “we don’t want to be accessible,” they’re saying that the particular legislation that this action has been brought upon us using doesn’t actually apply to the web.

I think hearing things from a legal perspective is good. Is that accurate, is that a misconception, or can you maybe help us understand that a little bit better?

Lainey: Let me just give one piece of background about my work. I have been representing the blind community since 1996 on digital accessibility. I use a method we call structured negotiations. One of the reasons I like structured negotiations is basically it allows us to skip over the very issue that you’re talking about.

A good illustration of that is just what you were saying. The term for the person who sued is defendant. The idea of a court case is if you get sued you need to defend your practices. In structure negotiations if we have a claim against a company for an inaccessible website or mobile app, we want to approach it in such a way that the company will want to work collaboratively with me as a lawyer and our clients in the blind community rather than defend their practice.

The legal system is just rife with theories people can use to defend. “Oh, well there are no regulations yet from the Department of Justice,” or, “I am in California and not Boston, so a different law applies.” All those sorts of legal arguments are out there, but there are a lot of entities in the United States that are stepping up and doing the right thing, skipping over all those arguments available to them in litigation.

Derek: The way you describe it, it sounds like they’re choosing a path that is more collaborative than combative.

Lainey: Yes, that is the way I like to practice law. We say it takes two to tango. With our cases we offer the company, or whoever has the accessibility problem, the opportunity to work in collaboration. If the company doesn’t want to take it, there’s nothing we can do about it. That’s where you get into the litigation and the legal arguments, like “does the ADA apply,” or, “what’s the difference between bringing a case in Massachusetts and California.”

One of the problems in the field right now is that the Department of Justice has these pending regulations. I understand the company responses like, “We don’t know if these apply,” and, “It’s not final yet,” and, “What do we do?” In fact those regulations will be helpful, but the law already requires access for people with disabilities to services, programs, and information; and that’s really all the web is.

So I feel like the Justice Department is in some ways doing a disservice to the business community by delaying these regulations when in fact the requirements are already there.

Derek: Right. It sounds like that companies and other organizations are using it as a way of saying, “It’s still up in the air and therefore we’re going to wait until we’re actually told that we do have to comply.” Even though they already need to be accessible, they’re just using it as a means to potentially delay the inevitable it seems. That’s interesting.

Are there other differences in terms of structured negotiations versus litigation? Is it usually you attempt to go through structured negotiation and if that doesn’t work then the next step is litigation, or are there other key differences between them in terms of how they work from your perspective?

Lainey: The reason we came up with the name “structured negotiations,” which is not the most clever name, we’re trying to say that it’s a structure that’s an alternative to litigation. It’s not pre-litigation negotiations, which pretty much is standard now to try to resolve it. It’s an entirely different structure. Yes, if it fails then litigation is another structure.

I’m happy to say that since 1995 there has only been one company who said to us, “go jump in a lake, we don’t want to do structured negotiations.” In that case we did to go to an alternative system of litigation.

Derek: Did you actually go jump in a lake?

Lainey: We did not jump in a lake. We jumped into the court system.

Derek: That’s good then. I would hate for your team to go and jump in a lake just because somebody told you to, that just wouldn’t be right.

Lainey: So structured negotiations the end result is very similar. We have binding legal agreements, they’re enforceable in court, they require the company to meet a certain standard that we’ve agreed on. For the web cases we use WCAG 2.0 AA, there’s monitoring and there’s enforcement. The advantage of it is we skip all the fighting.

I think in the digital world that the only way we’re going to get accessibility into the DNA of a corporation is for them to have ownership of it. By being in negotiations and being collaborative it’s much more likely that the entity is going to come to see accessibility as just another business practice that they need and want to have, not something shoved down their throat by a third party, like a judge.

That’s why I particularly like it. I think it’s great for whatever kind of issue you’re dealing with, but particularly with web and mobile where things are changing so fast the law is really designed for a static resolution. Relationship is really important and litigation is not designed to foster relationship.

Derek: Right, it’s pretty much the opposite. It’s interesting because you mentioned a couple of things that I think are really close to what our team thinks of. We often talk about trying to help organizations create a scenario where accessibility becomes part of their culture and it’s something that just becomes part of what they do as a good business practice. I think that’s a key piece.

The other thing you mentioned, and I know Elle Waters on our team talks with a lot of businesses and clients and prospective clients, one of the key things that she is always trying to remind them is that accessibility is something you want to do on your terms and on your timeline rather than on somebody else’s.

I think that kind of fits with the way your approach is. It’s better to come up with a timeline and a structure and plan to move forward collaboratively than it is to have one forced upon you by the court systems. That sounds like a much more positive approach to it.

Lainey: Yes. We talked to advocates the same way. Yes, it sounds good that you go to court and you win, but you’re not always guaranteed to win if you go to court.

Derek: Right.

Lainey: What you just said reminds me of another difference between structured negotiations and litigation; the use of experts and the use of consultants. We really believe that it’s important for an entity to hire their own consultant that they feel good about. We recommend consultants and we have jointly agreed upon consultants, but in the typical litigation the plaintiffs have one set of experts and the defendants have another set of experts and they’re fighting with each other about the edges.

All consultants, as you know since you are consultants, all people have different styles. Some people’s style fits with one company versus the other. We think it’s really important that the companies have consultants that they feel good about and that work within their business environment, so that’s something that we try to pursue.

Derek: I think it’s much more of a team game, I think it needs to be that. I think one of our goals when we’re trying to work is that things don’t even ever need to get to a structured negotiation point, where all of this stuff is taken care of before it even gets that far. I think that’s probably an ideal world.

As things move forward, I can see that there are things that you take care of on your own because it’s the right thing to and you’re required to do it, and if we’re not doing that then we get to the structured negotiation stage, and if that doesn’t work or isn’t embraced then we end up seeing people face litigations. I think that kind of makes for a nice continuum there.

You mentioned that things are changing quickly in today’s internet, and you even mentioned mobile apps. I’m curious, are you seeing more clients and more people that are facing accessibility issues that they’re more interested in looking at some of these mobile apps versus the web, or is still a good mixture of both? Are you seeing any differences in numbers or anything like that?

Lainey: Certainly when we started. The first company that we worked with to make a commitment to web accessibility was Bank of America and they’ve been a great partner in structured negotiations. We signed our first agreement with them in 2000, I don’t even know if there were mobile apps in 2000. You guys might know that more than me.

Now that the iPhone is so accessible to people who are blind, there is an expectation that the content on the iPhone is going to be available to people who are blind. Android is getting more so. I don’t think it’s as widely by the disability community as Apple products, but I also think that is changing.

When we look at information accessibility we look across the spectrum, including print. In the cases that we work on, if there is print information – the American Cancer Society settlement that we did as a good example. We worked on that print information available to people in accessible formats; Braille, large print, audio, as well as the digital accessibility.

It’s all of a piece. Wherever information is being provided to the public, you need to think of the people in the public who can’t access it in the traditional format.

Derek: Right. I think that just makes good sense.

One of the other things that we’ve noticed, and this is just recently and I’m not sure if you saw these, there was a case brought forward against Marriott about the use of an internal system. Then there was a case within the U.S. federal government where there was a case of internal software where the internal software that was being used was coming from a third party and ultimately what ended up happening was people were not able to move up and to achieve a higher rank, status, or get a promotion within the organization because (I think in both cases) the people were actually blind and they couldn’t use the software that was going to be required to perform their job duties.

So we’re starting to look at that as well and we see more cases like that happening. Are those kinds of cases covered under the same legislation or is there different legislation that specifically applies to those internal systems where things are coming from a third party and the organization didn’t create it, they’re not in control of it, they just procured it?

Lainey: That’s a good question. As you said in the beginning, this is in preparation for the AccessU conference and I want people to know that I am in touch with the lawyers who are representing the blind worker on the Marriott case. It’s not me, but there are great attorneys handling that case. I’m going to have up to date information on what’s going on with Marriott and what the legal theories might be for that type of thing. I’m not going to share it right now.

Derek: Okay.

Lainey: I will say that there are lots of different laws that cover these kinds of things. In the federal government there is, of course, Section 508, which is the direct procurement statute. For federal employees there is absolutely a direct line to 508 to that kind of software.

Derek: For organizations that are purchasing software from a third party, it’s probably well within their rights now – and probably always has been – to start ensuring that they’re asking whether or not the software is accessible before they sign on the dotted line.

Lainey: Absolutely. It definitely should be part of all RFPs. The only legal question is, “What is the employer’s responsibility? What is the software provider’s responsibility? What does the contract between those two say? Who gets to enforce that contract?” Those are the kind of questions that come up in the employment setting.

Derek: Those are questions that I think I’m very happy that I don’t have to answer. I don’t think I would want to answer those, they sound like tough questions. We’ll leave that to the legal experts.

So you’ll talk about some of these things in your session. AccessU is May 14^th through the 16^th. Will you be there for the entire conference or just part of it?

Lainey: Somehow I’m scheduled at 8:00 in the morning in the breakfast session for the very first day, so I know I’ll be there at the beginning. I always learn so much there. A lot of the technical stuff is way over my head, but I’m a big believer that if you sit in the space something is going to get absorbed so I love to go and learn from the experts.

Derek: That’s good. Hopefully it works the other way, too. The way that you describe the technical stuff is kind of the way that I, and a lot of people, would feel about the legal stuff. Your ability to take those complicated concepts and break them down and make them something that’s digestible for people that aren’t legal subject matter experts, hopefully the way that you do that for everybody else, the other people that are speaking at AccessU will do for you and be able to explain those technical things in layperson’s terms as well.

So you’re 8:00 AM on the first day. That’s actually a good slot, because everybody will be eating and they won’t be in a food coma right after lunch and they’ll be energized because it’s the very first session. Certainly that’s an honor and I think that fits really well with the message that you have.

How about a quick question here. You’ve been Austin several times. What is your favorite thing to do in Austin? People are going to be coming here from out of town. What’s your favorite thing to do in Austin and what sort of things would you recommend people check out while they’re in town?

Lainey: I saw that you were going to ask me that question and I realized that this year I’m going to commit myself to seeing more of Austin, because my favorite thing about going is seeing my friends in this community. I don’t really get out too much. I don’t know if it’s in May, but I do want to see where they have a bridge where thousands of bats come flying out.

Derek: The bats, oh yes.

Lainey: I’m not much of a bat person, but I think from a safe distance it sounds like an amazing thing.

Derek: I think every year, and I’m almost sure that it happens nightly. I’m not from Austin, so I don’t really know, but I have been there a few times and I’ve walked several times down to that bridge to see those bats and I’ve seen five. I think I just missed it or I was at the wrong time. I’m sure there will be definitely be a group going, so that’s definitely something that you should check out at AccessU.

Lainey: They also have great food trucks. I did get to explore that a little bit.

Derek: Absolutely. That’s fantastic. Hopefully you and a number of other people will be able to check out those bats together, if you haven’t done that before. Of course, you’re around for the first session and you’ll be around for a little while.

People that are listening, if you’re heading to AccessU, it’s really a fantastic opportunity to learn from the experts in terms of the technical side of things, the policy side of things, the legal side of things, and any other aspect that you could possibly imagine. It’s one of the best, if not “the best,” accessibility specific conferences going. Definitely check it out and say hi to Lainey if you’re there and ask her some questions, and just be part of the conversation.

I think it will be a great time, I wish I was there. Have a fantastic time there, Lainey. Thank you so much for taking this time with us today.

Lainey: Thank you.

Derek: And, there we have it. You can catch Lainey, lots of other great speakers and the bats in Austin in May. Again, its AccessU. Get all the details at knowbility.org – that’s k n o w b i l i t y dot org.

[Outro Music]

Every year, Knowbility hosts a whirlwind two-day event, multiple tracks that each contain amazing content; truly, there are sessions and workshops for every web professional. Curating the best and most relevant topics each year, Knowbility offers pragmatic accessibility training in technology, design, policy, strategy, and innovation, all in a very intimate environment with the world’s brightest instructors. See real-world examples and learn from industry leaders in technology, accessibility, web standards, and user experience. Whether you come to participate in the classroom workshops, or you come to join in the lively discussions about the latest trends in digital inclusion, you will leave with new strategies and expertise on how to create and maintain more universally accessible web content.

Sound good?

View the details and Register Now

In the meantime, we want to bring a little bit of AccessU to you, so, the Simply Accessible team has invited some of this year’s most notable speakers to have a conversation with Derek Featherstone. In these podcast interviews, each guest tells us a little bit about his or her session, shares what kinds of things that we can expect to learn at AccessU, and even delivers their favourite insider tip on getting the most out of a visit to Austin, Texas.

Here’s the first one:

An Interview with Lainey Feingold

Every few days leading up to the conference, we’ll release another podcast interview for your listening and/or reading pleasure. Enjoy, and see you in Austin!

These are not the first instances where an employee has sued for workplace discrimination due to inaccessible ICT systems. While most publicity surrounding accessibility lawsuits tends to be oriented around publicly facing websites such as Southwest Airlines, Wells Fargo, and Netflix, there have been a number of notable lawsuits by employees such as those against Montgomery County, MD and the State of Texas.

Given the ubiquitous nature of the computer in the modern workplace, ADA compliance is concerned with far more than the physical access to facilities. Requirements for equivalent access also now include accessibility of the employee’s computer system, the software applications necessary to do their work, and any internal use systems like intranets, training, and Employee Self Service systems. Due to the importance of these systems in the workplace, it is critical to ensure all users have the ability to use them.

What should we do if we get a complaint?

Take the employee’s concerns seriously. As mentioned on SHRM’s We Know Next Blog, employees often refrain from disclosing disabilities and often only do so when they have an unavoidable need to disclose this information. An inability to do their job is definitely one of those times. This is because your employee wants to work and wants to be able to do so in the same way as the rest of the employees. Because employees with disabilities rarely complain about lack of accommodation in the workplace, it’s all the more reason to take such complaints very seriously and to find a solution quickly.

Include the employee in all relevant discussions of the system’s accessibility issues. Ask them to clearly detail their challenges with the system so that you may include this when working with your IT department or software vendor to address the problem.

Verify your IT department or vendor’s claims regarding the level of effort, cost, and timeline to make the system accessible. Developers, designers and managers who are unfamiliar with accessibility will often significantly over-estimate the level of effort to make the necessary improvements because it is truly unfamiliar territory.

Determine a mutually acceptable plan for bringing the system into a more accessible state. The plan should include goals with concrete milestones that all parties can be involved in developing, and all goals should be reinforced with measures of success that compel staff to follow through with them.

Resist attempting claims of Undue Hardship. Many companies, having heard of ADA exemptions due to Undue Hardship, decide that any expensive remediation or replacement effort will exempt them from having to comply. Guidance from the EEOC states clearly that “Generalized conclusions will not suffice to support a claim of undue hardship”. Claims of Undue Hardship must be supported with real data demonstrating a truly burdensome level of difficulty or expense. A number of factors come into play when making such claims and, for the most part, Undue Hardship is quite rare when it comes to ICT accessibility.

Keep in mind that the legal responsibility for compliance resides with the employer. Ultimately, you as the employer are accountable for ensuring that the software that you buy or develop for your employees is accessible. However, there are measures that you can take to impress upon vendors the need for accessible software. While you can’t legally require a vendor to fix a product for free, you can certainly inform them that the current state of their system puts you at risk for an ADA lawsuit, which will compel you to consider other vendors when deciding whether to renew your license or not.

Don’t wait—start now!

Title I of the Americans with Disabilities act tells us that an employer shall not discriminate against a qualified individual with a disability.

Take a look in the mirror. Look at your job application procedures, hiring, advancement and discharge of employees, workers’ compensation, job training, and other terms, conditions, and privileges of employment. Any ICT products and services used by employees in these and other areas must be accessible. If these systems aren’t currently accessible, we always recommend being proactive to work towards bringing those systems up to snuff. This allows you and your company to budget for this expense on an internal time line; having that time line dictated to you by judges and lawyers is always more costly and disruptive to business goals.

“Tell designers that accessibility is the responsibility of the developers and tell the developers that accessibility is the responsibility of the designers.”

Not only does this approach ensure that nobody is taking responsibility for accessibility, it’s actively a step further — saying “Not my job” is very different than saying “YOUR job.” When nobody takes responsibility for accessibility it ends up costing you down the road because you will need to change the design, retrofit, or otherwise compromise the accessibility of the work.

A lot of accessibility is straight up development

People almost ALWAYS feel that accessibility is something that is created programmatically, mostly in the domain of the web developer. And, in many cases, those pepole would be correct. There is a LOT that needs to be done programmatically to ensure that what you create is accessible to people with disabilities. BUT (and there’s a always a big BUT) – you can’t rely on programmatic accessibility alone.

Programmatic accessibility is what we need to provide for most screen reader users. But what about people that have low-vision? They rely on the visual aspects of a design to be able to perceive the design and make sense of the interface. What about people with cognitive difficulties, or language barriers? They need the visual aspects of a design to speak to them in a voice that they can connect with. There is a lot more to it than just programmatic accessibility.

And that’s where design comes in.

Accessibility is important in the design phase of a project too. We can usually predict areas of a design that will be a problem just by looking at wireframes, comps or even html-based prototypes. We look at the layouts, visual relationships between pieces of the design, information hierarchy, task flows and more. They give us insight into what is likely going to be a challenge for people with disabilities.

Ben Franklin supposedly quipped “An ounce of prevention is worth a pound of cure.” Truer words were never spoken when it comes to accessibility. Accessibility issues should be pointed out and addressed as early as possible in the design process. The longer you wait, the more costly it will be to change or fix later.

The bottom line is that a flawed design coded perfectly is just as bad as a brilliant design coded poorly. We need to have both for accessibility to succeed. For that to happen, you need to ensure that you’ve got accessibility taken care of as part of your process. As web pros, we follow a design and development cycle and hopefully we can integrate accessibility into several different phases: content planning, user research, wireframing, visual design, development and quality assurance. No matter what your process is, it is better to actually prevent accessibility issues from arising in the first place rather than trying to fix them later on.

This might sound like I’m saying “Design is more important than development!” but in reality, that’s the farthest thing from the truth.

It’s not about design OR development. It’s about both.

In order to be as accessible as possible, it has to be about BOTH. Design and Development need to come together to make for an accessible solution. They’re complementary. Like the Yin and Yang. Treating them as such helps ensure that we can build accessibility in to the process of creating whatever it is that we’re creating.

Recent Interviews

Over the past month I’ve been interviewed a couple of times. Some Yin and some Yang. Here they are — one is design centric, and the other is… (yes, you guessed it!) developer oriented. Give them each a listen. I think they’re worth it, but maybe I’m biased!

Accessibility as a Design Tool

Adam Churchill of User Interface Engineering (UIE) interviewed me for the UIE podcast Accessibility as a Design Tool. We talk about design, and accessibility and how we can use accessibility as to make designs better for everyone, as these improvements often lead to usability improvements to the interface for everyone.

ShopTalkShow #58

I was interviewed by Chris Coyier and Dave Rupert in their front-end developer oriented podcast (ShopTalkShow). In Episode 58 of ShopTalkShow we get into some nitty gritty details of ARIA, why we need to ensure that we have non-ARIA based solutions, and why using lists for navigation is important. We’ve also made the Transcript for Episode 58 of ShopTalkShow available.

What next?

Think about your own practice — have you been overly skewed towards the development side of accessibility or the design side? How could you improve your work by ensuring your process includes more of BOTH aspects of accessibility? Would love to hear your thoughts, so please share!

As Simply Accessible grows, we discover like-minded people out there on the Wild Web. What starts as a friendship sometimes blossoms into the type of partnership we all have here at the company: a sense of being a comrade-in-arms pursuing a vital mission to change the world, one user’s needs at a time.

And, so it was with Elle Waters. Active on the web since 1995, she has an extraordinary and unique background in accessibility program management, strategic planning, cross-functional team management, working for and with Fortune 100 companies, and even, she claims, “marketing bingo mastery.” (We’re afraid to ask what that means precisely, but it sounds awesome. So does her time served in Army counter-intelligence, and I’m not kidding. Believe me, I’m also not asking.)

She knows people inside-out. Yes, Linguistic Anthropology was a focus during college—along with majors in Rhetoric and New Media—but her years of evangelism and leading projects within virtual worlds, online communities, and social media channels were one ginormous lesson in how people think, behave, react, (and even dream of better lives).

She segued straight into a career as the web accessibility coordinator at a large Fortune 100 company—one of the giants—using her leadership skills and insights about people to work on the very dull-sounding but critically important “implementation strategies for design, development, and process teams across the enterprise.”

This is where companies grow with the times or begin their slow, sad death spiral, and she wanted to be at the heart of it. Working with teams to build a corporate program from the ground up, Elle built the business case and established accessibility as an integral part of both the design strategy and the software development lifecycle, institutionalizing the process and creating a framework for long-term success.

What’s she doing at Simply Accessible? Elle joined us to support our enterprise strategy and business development needs, as we deliver insightful and creative accessibility/UX design consulting to Fortune 500 corporations, educational institutions, public utilities, government agencies, and other private sector clients.

From the business end, what’s the point? She’s uber-practical, like the rest of us. We’re not here to drag you through governmental mandates, we’re here to make things better. She’s going to work directly with you to roadmap a plan to help you meet or exceed accessibility requirements and, while doing that, achieve so much more. Along with the Simply Accessible team, she’ll establish a program that is sustainable, that makes sense to everyone, that helps you succeed.

As Elle describes it:

I want to use technology to make life a little more human. Working on accessibility actually drives innovation in design, acting as a catalyst for amazing discoveries in user experience that wouldn’t be possible otherwise. Accessibility can standardize a company’s processes, including procurement, consumer experience, design, development, and testing. Where accessibility is placed first, a company wins in several areas across the organization. And, above all, I believe equal access is a civil right.

So, what’s with the goggles? Well, sometimes we beg her to wear them because she’s cooking up something so hot we’d hate to see her hurt herself. But, truth be told, Elle’s goggles symbolize her love for looking at things differently, for producing the unexpected, and then, joining the rest of the team, generating the transformative power that enables us to do things for companies that no one else has done before. She Gets. Things. Done. This isn’t just hot air we’re blowing here. Give us a ring and we’ll give you a peek at how real and vital our work is and how we can help your organization.

But ask Elle about the goggles and she’ll look up from her studies of zombie lore, video gaming, and virtual worlds, and say with a smile: “Goggles are cool. You know, like bow ties.”

Want to hear a lively, smart, and entertaining expert speak at your conference or company? Contact us to engage Elle or to learn what the team and I can do for you.

Jones looks at the idol, trying to guess its weight. He looks at a bag of sand in his other hand and takes a bit of sand out so that the bag (hopefully) weighs the same as the idol. With a swift hand, he removes the idol from the pressure switch and replaces it with the bag of sand. And nothing happens. No arrows. Nothing. He’s done it! He’s used the replacement principle! If you take something away, you need to replace it with something that does the same job.

Of course, Indy starts to turn to walk away, and we see that he miscalculated. The bag of sand wasn’t the correct weight. The pressure switch trips and Indy feels the pressure of the closing in walls, and is under attack from the flying arrows. He does make it — but not without all manner of chaos erupting first.

But what’s the lesson?

If you take something away from an interface and replace it with something new, it has to be a direct replacement. Approximation won’t do.

Here’s some examples to help illustrate:

Focus outline

Many web people like to take the focus outline away from a browser. Removing the outline happens in almost every reset stylesheet. This causes huge accessibility problems for sighted keyboard users — tab through the example and see for yourself. You can’t see where the focus is on the screen. Why? Because the focus outline was taken away, and it wasn’t replaced. Like in Raiders of the Lost Ark. And the arrows fly.

If you really must do something other the default focus outline in a site, please be sure you replace it with something as good or better.

Here’s a nav block that removes the default focus outline, but uses mouse :hover to show a nice little transition effect:

http://examples.simplyaccessible.com/css3/navigation-nofocus.html

And here’s a nav block that has no focus outline, but uses :focus to provide something just as functional and better looking.

http://examples.simplyaccessible.com/css3/navigation.html

Notice the second one? As you tab through the page – you see the SAME visual treatment as we see on the mouse version. No flying arrows

Custom controls

We are often “required” (and I use that term very loosely) to create custom controls for a site. Form controls are a candidate because they are notoriously tricky to style. So, instead of allowing browser defaults to be browser defaults, we think that web sites need to look the same in every browser. We create custom controls.

Here’s an example from the online billing portion of our mobile phone/cable provider:

This custom control is made up of a regular input that includes the readonly attribute, and a linked image beside it that triggers the dropdown. It “works” in the sense that when you click the down arrow, the account selector list becomes visible. You can even trigger it with a keyboard. But the similarities end there. Once it is open, you can’t use the keyboard to choose the account. We expect the down and up arrow keys to work. In a true select, we expect the ability to type in the first letter of the options in the select list. We expect a lot. And we don’t get it here. (We’ll show you how to fix these things in a future article!)

A screen reader user will not be able to change accounts very easily it all — in fact, it’d be almost impossible in its current state.

The walls close in, and the arrows fly.

What should you do?

If you feel you must take the focus outline away, replace with something just as good or better. If you’re implementing a custom control, you have to fully implement all of the functionality that the native control gives. In both cases, some people with disabilities may rely on it.

Conferences & Workshops

CSUN 2013
February 25 to March 1, 2013
San Diego, California
Karl Groves and Elle Waters will present 6 different sessions and run a “Doctor is in” session on Friday.

Accessibility for UX Designers
April 9, 2013 Ottawa, Canada
Led by Derek Featherstone.

Code PaLOUsa
April 25 to 27, 2013
Louisville, Kentucky
Elle Waters will present “Accessibility as Innovation: Life on Mars.”

John Slatin AccessU
May 14 to May 17, 2013
Austin, Texas.
Karl Groves and Elle Waters will teach several classes including a full-day workshop.

Mobilism
May 16-17, 2013
Amsterdam, Netherlands
Derek Featherstone will talk about Mobile and Responsive Accessibility.

WebVisions Portland
May 22 to May 24, 2013
Portland, Oregon
Derek will give a half day workshop on accessible design, as well as “Thinking Beyond the Device” in the main conference.

Interlink Conference
June 5 to June 6, 2013
Vancouver, Canada
Derek will talk about “The Fine Art of Accessibility” at this conference focussed on craftsmanship.

Virtual Seminars

We’ve got quite a few virtual seminars on deck for this year. Here’s the first two, and look for more where we cover multimedia, understanding low-vision, voice recognition software, ARIA and more.

Accessible Maps virtual seminar
March 19, 1013
online with Derek Featherstone

Designing and Building Accessible Forms virtual seminar
April 30, 2013
online with Derek Featherstone

Subscribe to our Calendar

We’ve also consolidated all of this into one highly-machine-consumable source:
Google Calendar of Simply Accessible Events.

Subscribe and you’ll always know what’s coming up. And, as always — if you’re looking for private training, we’d be more than happy to bring these training events to your organization. Get in touch and we’ll get the ball rolling.

In July 2011, I put up a blog post on my own site titled “My Challenge to the Accessibility Community: We Need an Accessibility Body of Knowledge” in which I argued that there’s an unfortunate lack of cohesive and unified information out there about accessibility. At the time, many agreed but ultimately the idea gained little traction. The conversation was revitalized by Olivier Nourry with his blog post “How we could build a Body of Knowledge for Web Accessibility“. The subsequent conversation on Twitter heated up enough that I decided to start a mailing list which would allow interested parties to discuss the concept in more than 140 character increments.

The best part of the mailing list discussions that followed was the wide variety of people who participated. We had people who worked in government, people from the private sector, and people from higher education. We had people from both large and small organizations and people with and without disabilities. We had people who were new to accessibility and people who weren’t so new and people with varying level of technical knowledge. Finally, we had people who agreed that a Body of Knowledge is needed and those who said we did not. To address this question of whether a Body of Knowledge is even necessary, we began by attempting a Gap Analysis to determine the delta between what already exists and what does not. The first step: Figure out what people need to know.

What people should know

To gather this information, I moderated a Delphi-like effort to gather participant’s opinions on what was needed. Each interested participant was asked to send over a list of topics that they thought should be included. After the first round, we collated the answers and redistributed the list for a 2nd round in which participants would refine the list. Unfortunately, this is where the conversation sort of waned and participation in the process essentially ended. Regardless, we did gather a good amount of information on what people in the accessibility community think others should know about accessibility. Below, I’ve listed the findings from that first Delphi round.

Technical Guidance

Accessibility is often regarded as nebulous by those without an intimate knowledge of the topic. Nowhere is this more true than in the case of the technical aspects of it. It is really no wonder, when you consider the complex dance between the operating system, browser, accessibility APIs and assistive technologies. Gaining a real understanding the technical aspects of accessibility requires a knowledge set that is both broad and deep. Therefore, accurate, relevant, and timely technical information would be vital in a Body of Knowledge. Here’s what participants in the Delphi said was needed:

• Techniques/ Failures and Best Practices – specifically, what does it look like to develop accessibly? What are the best ways to develop an accessible system? The WCAG working group has developed Techniques for WCAG 2.0 but I guess participants felt the information hard to absorb or that it didn’t cover enough.
• Usability/ Universal Design – Participants appeared to want information that extends beyond what people normally consider to be accessibility and more about universal design and its contribution toward a more equitable experience for all.
• Plain language – Plain language is clear, succinct writing designed to ensure the reader understands as quickly and completely as possible. Many consider plain language to be vital for universal access and therefore many Delphi participants listed it in their topics list.
• Platform support information – as mentioned above, the complex relationships between the operating system, browser, accessibility APIs and assistive technologies has a large role to play in accessibility. Participants felt that a Body of Knowledge should include detailed information on this topic.
• Product/ Platform/ Framework specific information – There was a strong desire among participants for a Body of Knowledge that contained specific information regarding the accessibility of products, platforms, and frameworks. In some cases the argument was to have this information for procurement guidance while other times, it was recommended for design & development guidance for teams working with that specific type of product.

Managing Accessibility

For organizations that are new to it, managing accessibility can be a challenge. Understanding how & where to spend time and money, who should be doing what and when contribute to the impression that accessibility is nebulous. Delphi participants shared a desire to have information on managing accessibility included in a Body of Knowledge. Specifically, they cited the following as things to be included:

• SDLC/ Project Management guidance – Participants felt it important to include information about how to include accessibility into the Software Development Life Cycle and common project management methodologies. They also mentioned including role-based guidance for project members.
• Business Case – When arguing internally for more accessibility in their organization, many accessibility advocates are asked to construct a business case. Delphi participants listed business case information and success stories as some things to include in a Body of Knowledge. They also included a need for methods of gathering metrics on the success of accessibility programs.
• Procurement – Finally, when it comes to management of accessibility, was the need for procurement guidance. Many procurement officials don’t know about accessibility, what to look for, and how to construct requirement language into solicitations for accessibility when buying ICT (Information and Communications Technology) products and services. Therefore, participants felt a need to include procurement information as well, including sample documents, market research, and Independent Verification & Validation (IV&V) guidance.

Accessibility Standards, Laws, Litigation

Related to the above is the need to understand the organizational compliance needs with respect to accessibility. The policy landscape for accessibility is a complex one to navigate, especially for multinational corporations. Many countries have laws and policies for accessibility, some of which also having their own specific technical standards. Some of these laws or policies may also have requirements for handling procurement of ICT products and services. In some countries, additional policies can also exist at the state/ province level. While there has been a lot of work done to harmonize standards, many disparities remain. Because of this, the Delphi participants felt a strong need for information on the various standards, laws, and policies, including mappings between each. They also expressed a desire to have information regarding past litigation regarding accessibility.

Accessibility Testing

Because accessibility isn’t binary (i.e. either you’re accessible or not), performing accessibility testing involves a fair amount of subjectivity. This makes it difficult for even skilled Quality Assurance analysts to understand the tools and techniques necessary for proper accessibility testing. Delphi participants felt that a Body of Knowledge should include detailed information on techniques, methodologies, and tools for testing accessibility.

Assistive Technologies

Without experiential knowledge of assistive technologies, understanding all their intricacies can be a bit of a challenge.

There are scores of different assistive technologies, each aimed at addressing a very specific need. Among software assistive technologies, there can be significant differences in quality and capabilities not only between different brands but also among different versions of the same assistive technology. As a consequence, the Delphi participants felt strongly that information – including tutorials – about assistive technologies was vital to a Body of Knowledge.

Disability Information

At its core, accessibility is about people. At Simply Accessible, we tend to focus primarily on designing for all users—some of whom have accessibility needs. Regardless of your personal approach, accessible and usable design means understanding the needs of the user. In fact, gaining that understanding is often the “a-ha moment” that gets designers and developers on board with accessibility. When we can get designers, developers, content creators, project managers, and executives to understand the challenges faced by persons with disabilities, they’ll be more prepared to begin addressing the accessibility of ICT systems they build or procure. Therefore, the Delphi participants felt that a Body of Knowledge should include information on disability, including detailed descriptions of how people are impacted when using ICT products and services.

What would you like to know about?

That’s a lot of detail, but it mostly came from people that are already accessibility advocates. And while this process did a good job of getting at the root of what accessibility advocates feel others must know, what we didn’t gather is what other people want to know. People that aren’t already accessibility specialists.

Perhaps it is the same. Perhaps it is different. Either way, we want to know what YOU want to know more about.

Let us know by commenting below. Are you a developer? Designer? Manager? Something else? Or, feel free to shoot us a message and we’ll include your comments in a follow-up post.

We don’t want to just “keep up with demand.” We love our clients but we want to keep reaching into new territory, bringing accessibility and smoothly designed experiences everywhere we can. We help people make things work for everyone and we’ve also got a big message to carry to the world: “Here’s how you ALL can make things work for everyone.”

Adding someone to a team is a delicate balancing act. We needed another person—a very smart person—who really and truly gives a damn about the same things we care about. It also helps immeasurably if the person you have in mind has an awesome reputation and the sort of personality you think will be a great fit.

So, I am incredibly happy to announce that earlier this month we hired Karl Groves to join the Simply Accessible team.

We knew we wanted a technical powerhouse. We were totally sold when we saw Karl wearing a Viking hat in his Twitter avatar. I mean, what could be more powerful than a Viking, except maybe a drunken Viking? Further research revealed that he brews his own beer, so that settled that. Toss the other resumes in the trash. He’s our man.

But, seriously, Karl’s been in the industry for almost a dozen years and he’s recognized as a leader for his work and thinking on accessibility. The articles on his blog are brilliant, as is what he does. His standards are rigorous. He’s methodical, analytical, meticulous. And, he’s relentless in his pursuit of excellence.

Karl’s previous work with tool vendors and as a consultant will be invaluable to us as we bring more of our services to enterprise-level clients.

Karl’s experience as a speaker and teacher and his technical background as a developer mean that when he’s training another developer or teaching a class or working with an in-house team, he can speak the same language as the people he’s training. He can relate to their burdens and what they’re puzzling out because he’s been there, staring into the face of the same daunting problems.

He represents an opportunity for us to make things just right for even more clients.

With Karl on our team, clients will sigh with contentment. Developers will dry their tears on their ironic t-shirts and we will, too. And at Simply Accessible, with our other new and upcoming team members and the mighty Karl Groves, our lives will be busy but blissful, flowing with unicorns and rainbows and animated gifs.

1. Be sure to save on hourly rate for your design and development work by choosing the lowest cost per hour. After that doesn’t work (you get what you pay for) you’ll have the opportunity to do all that work again and pay for it twice!
2. Make sure that everything that you do with respect to accessibility isn’t documented and cannot be repeated.
3. Tell designers that accessibility is the responsibility of the developers and tell the developers that accessibility is the responsibility of the designers. Likewise, tell managers that it’s the responsibility of the CIO or CTO and tell the CIO or CTO that it’s all on the managers.
4. Ensure you provide absolutely no training to your teams.
5. Wait until just before launch to seek accessibility help.
6. Don’t get your developers or Quality Assurance team to test anything with the keyboard.
7. Ensure that ALL your solutions rely on proprietary materials or software.
8. Be sure that you don’t put any accessibility requirements in your procurement documents/requirements/rating criteria.
9. Rely entirely on automated tools for testing.

What do you have?

Okay, that’s 9 quick ones off the top of my head. Please, add your own in the comments. This could be fun!

You gather your wallet and keys, head to the front door. Walk through the door, turn around and lock it. You walk down your front steps, get to the sidewalk and stop. You take a peek both ways for pedestrians, dog walkers, and skateboarders. You see that a few are about to walk in front of you, so you wait. Once they safely pass by, you head off to the store.

Once you arrive, you walk in the front door of the store and look to the back left corner of the store for the dairy aisle. It makes sense that you know where it is—you work at the store, after all. You used to stock the shelves, you’ve been a cashier, and now you’re part of the team that designs displays, determines where the food and other items should go, and co-ordinates purchasing of all your supplies of different varieties of produce and groceries for the store.

You can see all of the cashiers to the left as well—there are 3 open lanes. You’re ready to go. You reach into your pocket and have your $10 bill ready. You reach into your other pocket.

You pull out your blindfold and put it on.

You turn left, walk all the way along the main aisle to the dairy aisle—a trip you’ve made hundreds of times before. You turn right down the aisle and head towards the back where you find the milk. You kind of sneak a little peek at the bottom of your blindfold where it doesn’t quite touch your face just to be sure you’re in the milk section. You select a jug of milk from the bottom shelf. You know it is there—you told the staff to make sure there was milk there because you were going to be testing a purchase.

You grab the milk, turn around, and retrace your steps towards the front of the store. You near the cashier, joining the express line. When you get to the front of the queue, you give your milk to the cashier, who asks you for $5.49. You give him the $10 bill from your pocket, he gives you the change and your receipt and says “Have a great day!” You thank him. You take off your blindfold and put it back in your pocket, and you place your $4.51 change in your other pocket.

You have a huge smile on your face as you walk back home, proud that you were succesful—you completed your task! You were able to buy milk from the corner store while blindfolded without any assistance! You walk home, and report back in to work: “Yes, no problem. I tested it, and we can totally buy milk while blindfolded. We’re accessible.”

Sounds ridiculous, doesn’t it?

So why do you think you should do the same thing with a screen reader and a web application? Because really, that’s what you’re doing, whether you know it or not.

He was a great man (says he, with an air of confidence and respect that a grandson just has for his grandfather) and lived for another 25 years. He never regained all the movement in his left leg. He became “single-handed” — none of the nerves and muscle below his mid upper left arm ever came back. Effectively he had one hand. For 25 years, we all helped him. Helped him do all the day to day things that we all do as we go about our extraordinarily busy lives.

Not so easy.

We helped him navigate stairs. They were particularly tricky as he couldn’t really bend his left knee. Sitting down in the car to go anywhere was difficult — I can’t count the number of times he wasn’t quite aligned correctly and he’d hit his elbow on the car frame and instantly be bleeding and bruised. We helped him fold the newspaper to get to his crossword puzzle. That was tricky for him to do with one hand. And the number of times I programmed and reprogrammed his VCR was maddening. Oh, wait — that had absolutely nothing to do with his stroke!

I remember his leg brace, his cane, his special knife for cutting food with one hand — all of the tools that helped him do things that he just couldn’t do the same way he used to. I saw his postural changes as he adjusted to an ever stiffening left side of his body. Instead of being mostly rectangular-shaped, he became more like a parallelogram with the right side of his body elevated and the left side slouching. I remember the effect that his “angularity” had on something simple like his handwriting.

And I saw first hand just how many barriers there were to him being able to go places and see and do things. Curb cuts were great for him too — he was rarely in a wheelchair, but those curb cuts meant that he could step up on to the sidewalk from the parking lot without having to step up 8 inches at once. When that curb cut wasn’t there, he could make that step, but it was tough not being able to bend his knee. He fell quite a few times, catching his toe on the curb. Curb cuts were just safer for him.

I remember all of this.

Awareness

Now, I don’t know if my experiences with Grandpa are the reason that I’m in the accessibility field. There are other reasons too. But my experiences with him had a lasting effect on me. They made me notice things I hadn’t noticed before. Things that got in the way of my Grandpa being able to do the things that he wanted to do. Like be at our wedding. Our childrens’ baptism ceremonies. Celebrate family birthdays with us. Christmas. New Years. Even just simple meals out at a restaurant.

Global Accessibility Awareness Day is all about helping as many people out there as possible become more aware of things that are happening around them every day that they don’t even notice. Awareness is as much about breaking down existing barriers as it is about avoiding putting up new ones. It’s about helping people do a better job providing services that meet everyone’s needs.

I know that being close to my grandfather helped me see things I would have never seen otherwise. He helped me become very aware of the issues that he faced as a person with a disability.

It starts with awareness

On May 9th, 2012—the first Global Accessibility Awareness Day—we’re opening up our accessibility expertise to help raise awareness of web accessibility.

There are lots of ways to get involved.

• There’s a list of accessibility events happening around the world.
• Experience accessibility issues first-hand.
• Blog about it. Tell your colleagues about it. Help them be more aware.

We have setup a free 90 minute teleconference that anyone can join. We’ll take questions for 90 minutes – you can pre-submit them, or you can submit or ask them live on the call. You can ask any question you want, and we’ll try to get to as many answered as we can in 90 minutes.

They can be questions at any level – from newbie to advanced. Bring a friend with you to the call. Setup a speaker phone and join from a board room in your office — don’t just come by yourself.

Bring people that aren’t already drinking the accessibility kool-aid. We want new people exposed to accessibility concepts. We know you’re interested. We want to get other people interested. Get web designers and developers on board. Ask your UX team or your Information Architects to come to the call. Your manager that doesn’t know much about accessibility. Get them all to come.

If you can’t make the call live from 1:30pm to 3pm (Eastern Time – GMT -5) on May 9th then don’t worry. If you register for the call, you’ll get a copy of an audio recording of the call, as well as the transcript of that recording. Sometimes you don’t know what you don’t know, so even just listening the call and answers to other people’s questions will help you start to formulate your own.

There are two things left to do:

Register and help spread the word

1. Register for the call
2. Encourage other people to register too

Okay, maybe she didn’t ask it quite like that, but it’s how I want to remember it, so give me that, at least, okay?

We weren’t talking about getting started with the concepts and principles of accessibility. That’s pretty straightforward and from our conversation she had a decent grasp of those concepts and the need for accessibility. We’re talking about integrating accessibility into your own work, no matter what it is that you do.

As web craftspeople, we touch almost all aspects of a project. It can easily become overwhelming to think of everything that we need to take into account for accessibility. So much so, that it can become a complete bottleneck to actually making any progress with accessibility.

Start With One Thing

Thinking about it a bit more, I had to tell her that the most sane way to get more accessibility into your work is to start with one thing. Choose to do everything, and you may end up accomplishing nothing.

Many of us are soloists. Generalists. Others are specialists or one of many other -ists. You leave your mark on whatever it is that you do. It could be writing and content strategy, visual design, information architecture, mapping out process flows, or even just getting stuck in, up to the elbows in code.

Regardless of your role on a team, or—as a soloist—the particular hat you’re wearing at any given time, accessibility needs to be part of what you’re considering. Ultimately, if we consider accessibility everywhere, we’d be in an ideal scenario. We’d know that accessibility was taken into account at the content, design, implementation and strategic levels. I know that isn’t always feasible. Reality is that even if you can’t consider it everywhere, you can consider it in one place or on one task where you hadn’t before. Do so, and you’re doing better work, period.

What can you do?

If you’re working on content, do a jargon hunt and explain terms that need it. Look for directionality (“click the link to the left”) and content associations that are dependent on layout. Think about accessibility statements and accessibility help as part of the content.

If you’re wireframing or envisioning process flows, consider how you’re going to communicate the “state” of the system to someone that can’t see. What are the requirements for people that can’t hear for that tutorial video you’re thinking of adding?

If you’re coding, think of how someone that exclusively uses the keyboard will activate that über widget you’re building. What about someone that is filling out that form and can only type 1 keystroke every 3 or 4 seconds because they’re using a mouth wand?

If you’re designing a visual, think about what your intent is. What are you trying to communicate with that visual, and sort out in your head how you’ll express that someone that can’t see the visual—even if it is something as simple as a navigation state.

No, this is not an exhaustive list. But if you consider just one more accessibility angle than you did before, you’re moving in the right direction. That’s what I told Andrea when we met on Monday. It’s what I’d tell you, too.

Ask yourself: Which one step can I take to add more accessibility into the work I’m already doing?

If not, they are denial, anger, bargaining, depression and acceptance.

If the names of those phases aren’t a fit for what happens in the accessibility world, I don’t know what is. We all progress in our understanding of accessibility—both at a personal level and at higher level within our organizations (at least, we hope so!)

Have you seen these stages of Accessibility in your organization? How do you know which stage you’re at? Here’s some famous quotes we’ve heard over the years that might help you figure out where you are.

Denial

• “This is a web ‘application‘ so those rules don’t apply to us”
• “We’re not the government so we don’t have to make this accessible”
• “People with disabilities don’t come to my site… they just aren’t my customers”

Anger

• “I can’t believe they’re making us do this!”
• “Why don’t our team members know how to do this already!?!”
• “This is just going to cost us money that we’ll never make back!”
• “This is so unfair!”

Bargaining

• “What about making it just level A compliant instead of AA?”
• “Can we just leave that part for later?”
• “I know we have three web sites, but can’t we just make one of them accessible?”
• “The mobile site doesn’t need to be accessible because our main site is.”

Depression

• “Sigh. We’ve done all this work, and its made no difference, and that consultant still told us we did it wrong…”
• “This is really hard, and there’s so much to think about”
• “What’s the point? No matter what we do it won’t be good enough”

Acceptance

• “Lets make things as accessible as we can, in a way that doesn’t compromise our business goals, or the aesthetic quality of our site. And, if we need to make changes later to make it more accessible, then we’ll do that too.”
• “We can do this!”

Where are you?

So, where are you? It would be great if we were all at the acceptance stage, but that might not be realistic. In which stage is your organization? Have any quotes you’ve heard over the years that you can share from inside your organization or from your clients? If so, please do share (anonymously, if you like!)

onclick="this.value=''"

OR 

onfocus="this.value=''"

What does this code do when it’s used in a form field? Why is it there in the first place?

It is mostly used to clear out “default input” that is already in a form field.

Here is an example: Click or Tab to place the cursor in the field. Then type something into it. Then Tab away from the field to the Go button. Then Shift+Tab back to the field.

What’s wrong with this picture?

Yes, I know. It is just bad code. You can get around this partially by improving the JavaScript. Something like:

onclick="if (this.value==this.defaultValue) this.value=''"

That way the JavaScript only clears the field if the defaultValue is in the field still. You could also use HTML5′s placeholder attribute, with some fallbacks for those browsers that don’t support @placeholder yet.

And, yes, I know that if you’re reading this, you’d never use code that indiscriminately removes whatever input is in the field. But someone out there did and does, because we see it in apps we’re testing all the time.

Why do we build things like this?

I can’t say for certain that this is always the case, but I think part of the reason we see it often is because people consider only two cases when they’re coding, or unit testing or doing Quality Assurance testing on a web site or application. Or it was done in a hurry. Or it was copied and pasted in haste from a bad tutorial site somewhere and nobody caught it when testing. The problem here is that this code indiscriminately clears the data out of the field, even in cases when you don’t want it to. It assumes that if there is *any* data in the field at all, that it should be cleared out.

How this relates to testing

There are two basic cases most people would test for (in acceptance or Quality Assurance testing, for example). The correct case and incorrect case.

The correct case: with a default value in the field, the user would place the focus in the field, the default would disappear and they’d enter some correct data in a field and submit the form.

The incorrect case: with a default value in the field, the user would place the focus in the field, enter some incorrect data in the field and submit the form.

A QA tester would look at the results of the form submission and determine that the system responded appropriately or not. Tests complete. They might even test that the form has a label.

But user experience, and certainly accessibility, need to take into account many different scenarios. Not just a simple “the user entered information correctly” or “the user entered information incorrectly.” To understand the full impact of this code faux pas on user experience, we have to understand a bit more about how people with disabilities use the web, and we need to look not just at the “correct” or “incorrect” case, but the “correction” case where the user enters incorrect information, realizes they’ve made a mistake, or needs to check to see if they made a mistake before they submit the form. Here are a few scenarios:

Typing Difficulties

Javed enters a phone number with the correct number of digits, but mistypes. He needs to correct only the second last digit of the phone number as the rest of the digits are right.

A person that has difficulty typing—whether they’re using their hands, a mouth or head wand or some other device—might take a significant amount of time to enter a phone number into a field. How frustrated do you think Javed might feel when he encounters this type of script? Picture this: it takes Javed 30 seconds to type a phone number—something that you might type in less than 2 seconds. 

And when he tabs or clicks into the field to fix that one digit, that JavaScript takes away all the digits that it took him 30 seconds to type. Now, he needs to start over.

Voice Recognition Software

Susanna’s browser auto-filled her phone number correctly but in the wrong field. It auto-filled her mobile phone number into the work phone field, and her work phone number into the mobile field. She needs to swap the numbers, even though both numbers meet the required pattern for phone numbers.

She tells her voice recognition software to focus on the phone number field for her mobile phone number and intends to tell her software to “select that” and “cut that” so she can move to the work phone number field and paste the phone number in there. And what happens when she uses the software to focus on the field? Her data disappears and she has to enter it again using her auto-fill which is may get it wrong again, or she has to dictate it—more work than she would have had to do with a simple cut and paste.

Using a Screen Reader

Latosha types her phone number into the field, but she doesn’t know if it is correct or incorrect until she double checks with her screen reader.

Think about Latosha. She types her phone number into the field, leaves the field to fill out more of the form, and then comes back to the phone number field to double check and suddenly her data is gone. Latosha can type quickly, but now she’s confused. A form field she thought she had filled in is now blank. What does that mean? Is there another phone number field to be filled in that she missed the first time around? Is this a different form on the same page? Is this even the same page?

Transitional Cases

Let’s be clear: every single one of these issues is a usability issue that would affect all of us. But, they are issues that have a much more significant impact on people with disabilities than they would on people without.

These are all “transitional cases” that need to be tested and accounted for in an application’s design. You can’t simply design or test for the correct case (“the user entered information in the right format”) and the incorrect (“the user entered incorrect data”) case and be done with it. You must test for the transition from the incorrect state to the correct state.

We’ve only described three cases where we don’t want to automatically clear out data that is in the field. There are countless others.

But you don’t need to count them. You just need to know that you almost never, ever want to use this line of code in your app:

onfocus="this.value=''"

And if you test for the ability to check your work, or make corrections with Javed, Susanna and Latosha in mind you’ll catch it.

Next Actions

• Examine your apps for code that removes data from fields. If you find it, it’s time to have that difficult conversation with your manager, or colleagues. You need to revisit this with them.
• The next time you’re wireframing, designing, creating user stories or test cases, use these descriptions above to make sure that you’re not creating something that is less usable than it should be.
• Make sure that when you’re testing your applications you’re not just testing to see if the application recognizes correct and incorrect input. Test to see how easy or difficult it is to move from the incorrect state to the correct state.

We talked about several topics in the interview, but there is one that I simply must discuss a little further: Audio transcription. It was the topic of about the first 15 minutes or so of the interview. You can hear the podcast on the Boagworld site: Boagworld Podcast Season 2, episode 6.

We’ve also provided a well-formatted and cleaned up version of the transcript of the podcast that tracks speaker names so that you can follow the conversation a bit better.

Let me highlight a few key components of my discussion with Paul regarding audio transcription.

Format

We often think of a text transcript of an audio file as an alternative format. Please remember that for someone that can’t hear, the text transcript is the primary format. We simply can’t forget that. People rely on the transcripts of our audio content as it’s the only way they can consume it.

Who decides?

In the interview Paul says that he normally posts an accompanying blog post that doesn’t include all the back and forth between he and Marcus, the other host of the podcast, and that the blog post is actually “better” than a transcript. In the interview, I suggested to Paul that the back and forth banter helps show what the relationship between Paul and Marcus is like. Someone that can’t hear, might be interested in that too. They also might not be. (You could actually argue that maybe nobody is interested in that and it should be edited out of the audio version, too, but the Boagworld audience has been split roughly 50-50 on whether or not the banter should be part of the podcast).

The question is, who gets to decide what’s important to the person that is reading instead of listening? That should be the user that decides. If you publish it for someone in audio format, publish the same thing in text format.

Scheduling

Paul suggests that if you record audio and wait to get it transcribed before you publish then it causes scheduling delays. There’s only a delay if you’re always running to catch up and things aren’t scheduled ahead of time. If you have a calendar, you can schedule release dates where the audio and transcript are released together. Schedule it ahead of time; it’s your job.

Finally, Pragmatism

Paul and Marcus mention a few times that you have to be pragmatic about accessibility. “How far do you go?” they ask. Paul says at one point in his discussion that “Derek was pushing me to do better than I was already doing.” Yes, yes I was. I’ll keep doing it, too, to anyone that I meet that is in this industry. To anyone that attends my conference talks and accessibility workshops.

How far do you go? “Pretty far” would be my response. We have to aim for the stars and set a very high standard.

While people may argue that pragmatism is about deciding what is “good enough” what they usually mean is that what they’ve done is “better than nothing.” There is a place for compromise. We do it all the time in our work. But it’s usually a compromise that means “less than optimal access” to the information that’s there, not “no access” at all.

Pragmatism includes planning. It includes budget. And it includes people with disabilities… as many as we can.

I started teaching people about ARIA in 2006 at Web Directions South in Sydney Australia. I was delivering a full day workshop on building accessible web apps, and showed an example that essentially boiled down to this:

<span x2:role="role:checkbox" aaa:checked="true">
	Include decorative fruit basket
</span>

That’s a simplified version of a W3C example that used namespacing (that’s what the x2: and the aaa: are before the role and checked attributes). The syntax for ARIA has changed since then so that we no longer require namespacing. Today we’d end up with something a bit simpler like:

<span role=”checkbox” aria-checked="true">
       Include decorative fruit basket
</span>

I still use this example in my workshops today because it illustrates a number of great points—like, if you’re using role=”checkbox” instead of a native checkbox, you’d better have a really good reason.

From the very first time I used that example, I had people saying to me: “but that won’t validate.”

What about validation?

They were right, you know. We should all be writing valid code. I suggested to them that they could break the rules for validation anyway.

“We require our code to be valid” they said.

Fantastic! This is exactly where we should be aiming.

I’m not exaggerating when I tell you that I had this very conversation with someone just last month in a full-day training session. I told them flat out, break the rules.

We’re not talking about throwing out all the rules here. I’m specifically talking about ARIA. ARIA adds programmatic accessibility where it just didn’t exist before. It allows us to programmatically specify what an interface component is beyond the collection of markup and CSS that it is comprised of. We can say “This is a slider” or “this is a tree” or this is a set of tabs (even though each them might be just a collection of <div> and <span> elements). If you want more of a primer on ARIA, I wrote a brief primer in my article on A List Apart: ARIA and Progressive Enhancement.

Now then, you can add ARIA to HTML5 and you can even validate with some of the newer validation services. validator.nu and even the w3c’s validator have support for validation for HTML5 + ARIA (just remember, HTML5 and ARIA still aren’t completely specified and implemented yet, so there are quite likely some issues that may crop up when you’re validating).

But what if you’re not using HTML5 and your web app is HTML 4.01? or XHTML 1.0? Then what?

You can switch your DOCTYPE to HTML5 so that your app/documents are recognized as such, and would therefore allow ARIA’s role and other attributes to be valid.

Or—and this is where I get a bit crazy—you can just leave your DOCTYPE alone. Leave it as HTML 4.01. Leave it as XHTML 1.0. Add ARIA anyway. Break the rules.

Adding ARIA adds accessibility

Because the potential good that you’re creating by adding in accessibility like this outweighs the problems that are created by not having valid code because you added ARIA. What problems are created by adding ARIA’s role and other attributes to HTML 4.01 or XHTML 1.0 documents? Precisely none. Why not?

If a browser doesn’t understand an element or an attribute, it just ignores it.

The browsers ignore role and other ARIA attributes. Assistive technology such as screen readers that run on top of those browsers, use the ARIA attributes for good, not evil. It doesn’t matter if they’re using it with HTML5, HTML 4.01 or XHTML 1.0.

Use ARIA with whatever version of (X)HTML you’re using. Even if it doesn’t validate.

If breaking a rule like validation by adding ARIA means that your interface becomes more accessible then do it.

Yep, I’m a rebel.

Here’s an example from the page showing our upcoming tour of workshops to Australia:

<a href="http://feathermelbourne.eventbrite.com/">
<h3 class="summary">Melbourne</h3>
	<span><em>Supported by WIPA</em></span>
	<span>July 25, 2011</span>
	<span class="button">Purchase Tickets</span>

	<img src="star.png" title="Melbourne" alt="" />
</a>

The block link makes the entire block of content clickable without using multiple links. We just couldn’t do that in (X)HTML. Traditionally we would have made the heading clickable with a link inside the <h3> and then another link around the rest of the content to make it clickable, and then we might add JavaScript to deal with the clicks that happen in the spaces around and between the links and some CSS to create :hover to create the invitation to click anywhere on the block.

Block links are the perfect solution for this because:

• they don’t rely on or require any JavaScript
• they create fewer “tab stops” on the page, making it easier for keyboard users to navigate
• they automatically create a large, block clickable area, making it easier for everyone to click

It is completely invalid (X)HTML though, isn’t it?

And because of the ways these types of validation/nesting errors are corrected in browsers, assistive technologies react to these in different ways.

Testing, Testing, 1, 2, 3.

Lets take a look at what actually happens when we put block links to the test with a couple of pieces of assistive technology.

With a screen reader, the behaviour depends on the mode you’re using to interact with the links (via tabbing through the interface, listening to a summary of the page, reading a links list, or listening to the entire page with “say all” mode).

With the Jaws screen reader, when navigating using the tab key, the only part of the block link that gets read is the first content in the link. In this case, the heading “Melbourne” or the other city names. When navigating using the arrow keys, though, the heading is identified as a link, as is the rest of the content that is contained in the block link, effectively creating two links. When using the links list dialog in Jaws, the block link is identified as one link.

With Voiceover on the Mac, the link text is repeated when it is read out when navigating using the tab key but is only seen as one link:

To summarize, sometimes the link will be recognized as one link and other times as two, sometimes the content is repeated and sometimes portions of the content are not read out at all.

The behaviour depends on the combination of screen reader, browser and navigation mode.

We don’t want it announced twice, though that is definitely better than the link contents not being announced at all.

We tested the same block links with Dragon Naturally Speaking (voice recognition software) and were pleased to find that it recognized each block link as just one link.

So, what are we to do?

We decided to forge ahead with block links. Yes, the content gets read out twice in certain situations, but it is better to be read out twice than not at all.

In fact that was one of our biggest concerns: portions of the link not being read out. However, in this case, we’ve front loaded the most important part of the link (the name of the city) so it’ll be the first thing read out. And even though the date is not read out in certain scenarios, it is one of the very first pieces of content on the Event Brite registration pages. So, while it isn’t perfect, it is a compromise we’re willing to make. We may also look at changing the markup so that it is read out as part of that first block.

And remember: these issues will eventually go away as browsers and assistive technologies fully implement HTML5 compatibility. This isn’t even an issue that is “HTML5′s fault” so to speak. It’s just based on the way browsers recover from markup that they consider to be invalid.

For now, we’ll keep experimenting with block links and other HTML5 constructs in different scenarios and examine each situation on a case by case basis. This is only the tip of the iceberg when it comes to HTML5 and accessibility so we’ve got to keep moving forward with these solutions and dig deep into the accessibility implications and make smart decisions about what we implement and how we do it in the best possible way.

• Blind people that use a keyboard because they can’t use a mouse

• People with low-vision that use a keyboard some of the time
• People with mobility or dexterity impairments that simply prevent them from using a mouse.

Generally, we’re talking about both sighted and non-sighted keyboard users.

It is now, and always has been, a fundamental for accessibility, period. It is one of the first things we check for when testing a site or application for accessibility and usability issues (Yes, I did say usability issues — proper keyboard accessibility makes it easier for everyone to use, disability or not.)

Problems with content

When working with straight up HTML based content, your keyboard accessibility issues are non-existent. With HTML, things like form fields, buttons and links just work, because keyboard accessibility is built in to the browser.

But start mixing content and you get… well, mixed results. Here we look at one example — YouTube videos embedded in a page.

As soon as you have mixed content embedded in a page, we encounter issues with what I refer to as “keyboard scope.”

As an example, open up FireFox and try to tab to the video controls on the page for our screencast Images in Context.

In order to control the movie with the keyboard, you need to click on the Flash movie to give it the focus first. Read that again. You need to use the mouse to click on the movie first in order to use the keyboard.

How we “solve” the problem

When we embed YouTube videos in our pages, we always include an external set of controls that control the key functions: play/pause and mute/unmute. These are added to the page with JavaScript (they only function with JavaScript on, so there is little point in having them on the page when JavaScript is off or unavailable) and utilize the YouTube API to control the movie.

We add two simple, natively accessible <button> elements to the page. Here’s the Play/Pause button:

$.fn.youtube_controller = function() {
    var player = $(this);
        
    var playButton = $('<button />', {
        text: 'Pause',
        id: 'playBtn',
        click: function(e){
            e.preventDefault();
            var ytplayer = document.getElementById('video-player');
            if (ytplayer) {
                playerState = ytplayer.getPlayerState();
                if (playerState == 2 || playerState == -1) {
                    ytplayer.playVideo();
                    $(this).text = 'Pause';
                } else if (ytplayer.getPlayerState() == 1) {
                    ytplayer.pauseVideo();
                    $(this).text('Play');
                }
            }
        }
    }); 
    $(player).append(playButton);

Then we style them to make them appear just like the regular Flash YouTube controls. They’re positioned over top of the embedded YouTube movie so that the buttons are in exactly the same place as YouTube’s controls. We style them to look the same, including the :focus states, and then position them over the movie:

#watch-player button {
-webkit-border-radius: 0;
-moz-border-radius: 0;
border-radius: 0;
background: transparent;
position: absolute;
bottom: 6px;
text-indent: -9999em;
margin: 0;
padding: 0;
width: 30px;
height: 26px;
}

.main #watch-player button:focus {
    border: 3px solid yellow;
    outline: none;
}

#playBtn { left: 0; }

#muteBtn { left: 30px; }

Now, go use the keyboard to tab to the “Play/Pause” button on the embedded version of Images in Context

See how it works? The controls are actually living outside the movie and that provides easy keyboard access to everyone.

Not Perfect

Now, this solution isn’t 100% perfect. Sometimes I think we should actually leave the buttons outside the movie and NOT style them to be positioned over top of the YouTube movie so that the buttons are more obviously available to everyone.

I also feel that we need to include some of the other controls that are in the movie — a volume slider, a timeline scrubber, and a fullscreen control.

We could conditionally execute the JavaScript so that it doesn’t create duplicate controls where the tab focus issues have been resolved (IE9 and FireFox 4 both seem to have solved the tab focus problem; unfortunately we know how long it takes to get browsers upgraded in some environments.) Having a duplicate set of controls is certainly the lesser of two evils though — much better than not being able to control the movie with the keyboard at all.

• View the transcript for this video
• View this video on YouTube

If you use display:none, then screen readers don’t get that content. It is better for accessibility to use off-left positioning instead of display:none

The next thing you know, someone has it in their head that this is a binary situation: display:none is bad for accessibility and off-left positioning is good for accessibility.

Here’s the thing, though–sometimes you WANT to use display:none. Sometimes you want to use off-left positioning.

I actually saw an example recently that used off-left positioning and they said right in the comments:

/* keep this off-screen because it is more accessible than display:none */

Off-left positioning is a technique that is often used in image-replacement that allows you to essentially create a text alternative for CSS background images that are used in your designs. It has also been used for other things like hiding menus and other content off the screen–often in the name of accessibility.

The case I saw the other day was using off-left positioning for creating a CSS only hierarchical menu.

Here’s an example of how it was done:

http://simplyaccessible.com/examples/css-menu/

There are 4 menu items that have sub-items that show when you use the mouse to hover over the items.

Now, start to tab through that page with your keyboard. What happens when you tab from the “About” link? Let me highlight this for you:

The keyboard focus is placed on the next link (“The Company”) that is still hidden from view because it is hidden using off-left positioning.

The keyboard focus is now invisible to someone that is a sighted keyboard user (remember, screen reader users aren’t the only people that use a keyboard for navigation!). The focus disappears until “Services” gets the focus and then disappears again and again after each main navigational item as the off-left sub-menus have the focus.

Fixing the problem

There are several ways to solve the problem, each of which take into account two key considerations:

1. Keyboard access to all content for everyone.
2. Elements that aren’t visible on the screen shouldn’t (generally) be able to receive the focus.

Here are a few options that we’ve cooked up for you to look at. And please, while you’re looking at these examples, go through them with a keyboard (both forwards and backwards) to see the kind of keyboard access they provide compared to the original.

Option 1: use display:none instead of off-left positioning and set the menu such that :focus doesn’t turn it to be display:block. This would require the “landing pages” for each of the top level menu items to have the equivalent sub menu items readily available on the page. http://simplyaccessible.com/examples/css-menu/option-1

Option 2: use display:none and have a :focus state to match :hover that makes it display:block and brings the sub menu items onto the page, allowing them to receive the focus, but only while they are on the screen. http://simplyaccessible.com/examples/css-menu/option-2

Option 3: use off-left positioning but use :focus to bring it back on the screen. Again, this would bring the sub menu items onto the page and allow them to receive focus, but only while they are on the screen. http://simplyaccessible.com/examples/css-menu/option-3

Note: We aren’t going to include an ARIA example here. That’s for another article

The Real Problem

The problem isn’t so much that off-left positioning was used. The problem is that it wasn’t used appropriately combined with the faulty assumption that we need to use off-left positioning because it is more accessible than display:none. Someone came to understand through their own experimentation or hearing or reading that display:none isn’t good for accessibility and THEN implemented a solution without thoroughly testing for full keyboard access.

If you’re developing anything for the web make sure that you have efficient keyboard access to everything, and that you’re not allowing the focus to go off the screen to elements that are hidden off-left.

Now that would be better for accessibility.

Even the simplest of things aren’t as straightforward as we’d like them to be.

Take a look at noting required fields for a form. You’ve likely seen hundreds of ways to tell a person that certain fields are required over the years. Just yesterday, I saw this example:

Here’s the code that is used to show that this is a required field:

<div class="requiredField"></div>

div.requiredField {
	background-color: #DC2222;
	width: 3px;
}

There is nothing in the HTML — no information at all — that indicates required fields. It is all being done entirely with an empty, semantically meaningless div and some CSS properties. This means that it is a completely visual solution, and has nothing available for a screen reader or other assistive technology to read.

So what are you to do?

Simple.

Content (HTML) is your most reliable way of showing people what fields are required.

• It can be the word “required” in your form label.
• It could be an asterisk, or even an image of an asterisk.
• It could simply be a statement that “all fields are required” before the form.

In the future, that may change to include other techniques like adding HTML5′s “required” attribute or even ARIA’s “aria-required” attribute.

For now, it needs to be in your content, not your CSS.

The Future

We study form interaction a lot — it is usually tops on the list for our clients when we’re looking at their web apps. If you’re interested in a deep look at more modern methods, go read our article over at A List Apart:

ARIA and Progressive Enhancement

The meatiest part of the article is a detailed look at modern techniques for denoting required fields.

Take a look at the Going a bit deeper section. It may overwhelm you, but you’ll see the details of testing several different scenarios for noting required fields. We test methods for showing required fields like HTML5′s required attribute and ARIA’s “aria-required” attribute. At the end of the day, we always come back to our standard method of including appropriate content in the form label. We started using that method in 2005 and have been using it ever since.

If you need to make your forms accessible, please take a look at our Virtual Seminar In Top Form: Designing and Building Accessible Forms. As a bonus, we’re giving everyone that registers a copy of Luke Wroblewski’s Web Form Design book (a $22 value). Sign up now

I managed to take advantage of the beautiful weather, blowing and vacuuming up the leaves and mulching them into a fine dust, and loading them all up into recyclable bags. 12 bags in all, 6 hours of work.

The next morning my right wrist was swollen up to be about the size of the roundness of a small apple. I’m having a really tough time flexing my hand, I can’t bend my wrist and holding onto anything is proving to be quite a challenge. When I do flex my hand I can hear a creaking noise that sounds like rubber tubing rubbing up against a ball of cellophane.

I can’t use my hand right now and it is slowing me down. I composed this entire blog post using Dragon dictate for the Mac. It’s quite accurate and I didn’t need to complete much training. Hopefully this won’t last long but I’m very thankful that I have been exposed to voice recognition software over the years in our accessibility work, so I know how to use it reasonably well. Even with that, the dictation part was the easiest. Actually posting proved to be a bit more challenging and is likely to become a series of posts on using Dragon Dictate on the Mac.

At some point in your life you may break down. You may get injured. Your abilities to do the things that you do now may decrease. Vision, hearing, dexterity, mobility, cognitive abilities — any or all of them may change in your future.

Right now you might be focusing on building accessible websites for other people. Someday you may be hoping that others are building them properly for you.

This fits very well with the way that I’ve always tried to approach accessibility:

I don’t care what technology you use, as long as you use the accessibility features of that technology properly.

I know it isn’t quite that simple, and I generally advocate using HTML-based solutions over others, but in reality, at the end of the day, if you can support accessibility with what you build with Technology X, then do it.

I was very very happy to see that the W3C recently published an update to the Techniques for meeting WCAG 2.0 that included a huge number of Flash specific techniques for WCAG 2.0. Even if I don’t always agree with the choice to use Flash, that isn’t my battle. My battle is making sure that if and when you do choose Flash, you implement accessibility. People are going to continue to use Flash and they need to have the tools and techniques to ensure they are creating accessible content.

What about non-web content?

I’ve seen and heard this a few times in the last while — someone will post a message to a mailing list asking “We’re building an application for iPad/iPhone. Is anyone else doing that with a focus on accessibility and if so, are you following WCAG 2.0?”

People inevitably point to Apple’s Accessibility Programming Guide for iOS to provide guidance for making accessible iPhone apps. That is excellent advice — it is comprehensive and has a lot of valuable information.

Other responses flatly dismiss WCAG 2.0 for this scenario — “WCAG 2.0 is meant for web content only.”

My take? Just because something isn’t web content, per se, doesn’t mean that we can’t still take the core principles of WCAG 2.0 and apply it to an iPhone app. WCAG 2.0 is based on user needs. Your content and functionality, whether part of an app or delivered via browser, needs to be:

• Perceivable.
• Operable.
• Understandable.
• Robust.

Nothing precludes you from using WCAG 2.0 as a framework for assessing an iPhone app. Your app’s functionality and content needs to be perceivable, operable, understandable and robust, doesn’t it?

The implementation details are different than with HTML. Even so, we’ve used WCAG 2.0 as a framework for assessing iPhone apps, Flex/Flash applications, and even Java and other desktop apps as part of our accessibility consulting.

Even if it isn’t “web content” per se, core user needs remain.

Have you used WCAG 2.0 as a framework for other types of content? I know all the guidelines don’t necessarily apply in a non-web context, but what other challenges did you run in to? If so, we’d love to hear about it… please do share!

I love user styles because they allow us, the users, to customize the way we want things to look. We can modify and override what the author suggests in their style sheets so that our preferences take priority over the author’s. My browser, my fonts, size, colours and layout.

Most browsers, including Internet Explorer, FireFox, Chrome, Opera, and Safari (see Safari 5 User Styles) all have mechanisms built into the browser that allow us to apply a user style sheet. This may be done at the browser level or through an extension mechanism, but ultimately this lets the end user control how a web page looks. This could be something simple like choosing a different background colour and text colour to be applied to every web site they view to something more complex where styles are reset and then set for every element possible in a web page.

The beauty of this mechanism is that it allows for much more customization of:

• font size
• background and foreground colour combinations
• displaying of hidden content
• arrangement of elements on the page
• size and colour of form controls

The user style sheet gives you full control over how pages appear in your browser.

Unfortunately, we don’t have that ability on the iPhone or the iPad.

Actually, we do, but it isn’t as convenient as setting up a user style sheet.

Here’s an example:

1. I borrowed my friend Wayne Dick’s user stylesheet and uploaded it to: http://examples.furtherahead.com/userstyles/waynedick.css
2. I edited Gez Lemon’s Accessible Style Sheet Bookmarklet so that it includes that URL: Wayne’s Styles (feel free to click it now if you like and you’ll see it in action)
3. bookmark it in Safari, and sync to iPhone or iPad.

Launch that bookmarklet in mobile Safari and you should see something like this:

Limitations

Of course, there are limitations. Here’s what I see as the two most significant:

Persistence. You need to apply this bookmarklet every time a page loads. That’s a limitation you could live with though if you need to be able to read the content with your preferred fonts, colours, sizes, and layout.

Technical savviness. In order to employ this technique, you need to be able to author a user style sheet, upload to a server, edit the bookmarklet, save and sync the bookmarklet. Many end users that need this functionality may not have the chops to do this.

Here’s a helpful thought though – if you are reading this article, the odds are that you DO have the chops. If you know someone that could use some support with things like this, help them out. We’re all in this together, and all that.

To add your own user style go to Preferences > Advanced > Style Sheet and select a CSS file (locally stored or on the network) to use that style sheet.

If you’re unfamiliar with user styles, here is the scoop:

• You have specific text and background colour combinations that work best for you.
• You have a particular font and font-size that work best for you.
• You choose not to display images by default.
• You decide that you want all your form fields to be twice as big as they are normally.
• You want a certain outline around each paragraph so that you can more easily digest a page chunk by chunk.

Whatever the reason, you create a set of styles that make things look the way you want them to. Through the browser itself, or through a browser extension, you tell the browser to use your new stylesheet, and it overrides what the author suggested.

Make sense? This use of technology is exactly why we use progressive enhancement and why we must always remember that other people may not see a web page the same way we do.

Right around that time I was in Phoenix for the 2010 IA Summit, and on Wednesday in my Real World Accessibility for Ajax and Web Apps workshop, an attendee asked about the issues of speed. At his company they’ve been focussed on speed of service delivery for their web site. To the point where they’ve changed the markup to be leaner. For a navigation menu, instead of using an ordered list, they were using simple links without any other markup.

<ul>
	<li><a href="page1.html">Page 1</a></li>
	<li><a href="page2.html">Page 2</a></li>
	<li><a href="page3.html">Page 3</a></li>
	<li><a href="page4.html">Page 4</a></li>
</ul>

178 bytes

versus

<a href="page1.html">Page 1</a> <a href="page2.html">Page 2</a> <a href="page3.html">Page 3</a> <a href="page4.html">Page 4</a>

129 bytes

For that component alone, that’s roughly a 30% reduction in code. It is faster.

Add in style rules to make the list items display:inline, and include any DOM manipulation or traversal and these differences can add up.

I think most people would agree that the first example with the unordered list is more accessible, and provides more semantic markup. We’ve been coding navigation menus as lists of links for years and you likely have been too, for good reasons:

• a list of links provides more context (we’re on item 2 of 4)
• coding it as a list allows a typical screen reader user to jump from one nav block to the next
• we often use nested lists to denote hierarchy in our navigation (though this example doesn’t)

So, where does this leave us, then?

It seems that at a micro level, speed and basic accessibility (and semantics) are at odds with one another.

I sincerely hope the weight given to site speed isn’t something that overpowers other factors like accessibility. Why? Because site speed is about to be the new big thing that companies focus on in order to try to get to the top of the search results. Thankfully they state: “While site speed is a new signal, it doesn’t carry as much weight as the relevance of a page”

Relevance will always be the most important factor (or at least, it better be). Accessibility and speed are important too, so to me, the best way to approach it will be:

1. write/create hightly relevant content
2. use semantic markup and ensure your site is as accessible as it can be
3. use every means to speed up and optimize after you’ve done everything else.

It doesn’t have to be speed versus accessibility, does it?

In this case, the error message is emphasized within the label for the form field. Semantically this makes sense – we highlight error messages with colour, different text weight or other visual means in order to emphasize them anyway. Using a <label>... <em></em></label> not only provides us the elements for styling but also makes sense – the label (and therefore the error message) is specifically associated with the form field using the for attribute.

This technique is essentially an extension of the one used for denoting required fields. The exception is the HTML:

<div>
<label for="uname">Username
<em>must not contain spaces</em>
</label>
<input id="uname" type="text" name="uname" value="" />
</div>

Placing the error message to the right of the field for easy scanning is useful, and the fact that it is still part of the label, and found before the text box in source order allows it to be read out by screen readers. This is a case where a zoom layout could also be used to provide a version to low vision users.

View the Error Messages Example

With the asterisk rendered after the field itself, it is not always read aloud by a screen reader, nor seen by a person with low vision using a magnifier. While it is also the user’s responsibility to understand what fields are and aren’t required, we, as developers and designers, certainly can make it easier for people to discover which fields are required.

A typical strategy is to change the form layout so that the label and its asterisk are listed above the form control itself, making it easier for screen reader users and low vision users to determine which ones are required. As a fully sighted user, I find this type of layout a bit more difficult to use, as I can’t scan quickly to determine the required fields – for me, the layout with the asterisk to the right of the form field is much more usable. So, how do we balance the needs of multiple groups?

Here are two possible strategies that are useful:

1. Very simply, place all required fields in a “Required” fieldset and other information in an “Optional” fieldset. This has the benefit of semantically grouping the fields together, and that the legend is (generally speaking) read out before each of the fields depending on the verbosity settings of the screen reading software. View fieldset example.
2. You could also use semantic XHTML to provide some emphasis to the asterisk and use CSS to place the asterisk part of the label visually after the input control. This relies on absolute positioning within a relatively positioned parent as shown in this illustration:

   

   Here is the relevant HTML for this example:

   <div>
      <label for="uname">Username<em>*</em></label>
      <input id="uname" type="text" name="uname" value="" />
   </div>
   

   The CSS for this technique is fairly straightforward: first, the containing <div></div> is positioned relatively and given an appropriate width:

   form fieldset div {
     position: relative;
     width: 60em;
   }
   

   Next, the label and input are styled:

   label {
     width: 15em;
   }
   input {
     width: 15em;
   }
   

   Finally, we use CSS to place the <em>*</em> to the right of the input:

   label em {
     position: absolute;
     left: 35em;
   }
   

   This provides a benefit to sighted users, and those using screen readers. It doesn’t help low vision users in particular, but a zoom layout would be appropriate for use in this case.

   View label example

The HTML for this example might be:

<div>
<label for="searchtxt">
Search Terms:
</label>
<input id="searchtxt".../>
<input type="submit" value="Search" />
</div> 
<div class="group">
<div>radio buttons</div>
</div>

This is a fairly natural way to code the form when using a CSS based form layout – visually the first “row” of the form includes a label, a text box and a search button, and the second “row” includes the optional radio buttons that help refine the search.

View the Search Form Example

Based on what we know about source order, this presents a minor obstacle to a screen reader user as they will encounter the text field, then the search button, and then the radio buttons. They may not realize that the radio buttons exist – the natural tendency is to submit the form once the submit button is reached.

This form layout also causes a minor inconvenience to a keyboard user – to choose the optional radio buttons they must tab past the submit button, and then navigate backwards (often using Shift + Tab) to submit the form.

This problem can be solved by improving the source order and using CSS to absolutely position the Search button as follows:

First, we modify the HTML source:

<div>
<label for="searchtxt">
Search Terms:
</label>
<input id="searchtxt".../>

<div class="group">
<div>radio buttons</div>
</div>

<input id="submitbtn" value="Search" />
</div>

Then we apply the following CSS to visually place the Search button at the top right of the form, much as in the previous examples:

input#submitbtn {
position: absolute;
left: 31em;
}

The result is that we have a form that visually shows the Search button beside the text box, but has a better source order for keyboard and screen reader users. It may also be useful to not position the Search button at all for a Zoom layout, allowing the Search button to fall vertically at the end of the form (while I have implemented the zoom layout in the example, note that it has not been tested with low vision users)

View the Search Form with source ordering Example

• the user doesn’t have to go “back” to search again or refine their search
• the programmer gets to keep their code modularized and reuse the same bit of code over again by maintaining one page instead of two.

However, this does cause some problems for visually impaired users, and (I’ll freely admit) sometimes throws me off for a number of reasons:

• the search form is presented first and, depending on its complexity, pushes the search results below the fold
• there is often no indication that anything has changed – a screen reader user or screen magnifier user are presented with what looks like the same page. On several occasions I’ve been asked in user testing “didn’t I just fill that form out?”
• a keyboard user is required to go through the entire page and search form before getting to the results.

View a typical search and results page that demonstrate these problems.

Fortunately there are a number of things that can be done to improve this functionality.

First, we can change the action of the form to include a fragment identifier/named anchor for the results page.

<form method="post"action="whatever-page.php#results">
... form elements here …
</form>

Next, we create that element within the results page, and use that element to do two things: 1) provide a statement about how many results were found, and 2) link that statement to another node within the page.

Found 25 results for keyword

This accomplishes two things:

1. including the statement itself lets any user know right away that something has changed on the page
2. posting directly to that node places the focus where it is most relevant
3. linking the statement is very clear, and acts as a very precise link that “skips over the form” without actually being called a skip link.

In my final example, I’ve also included a link after the search results that submits back to the form itself to make it easier to “Search again.”

View the improved search and results page

Other considerations

You might also consider it useful to change the page’s <title>...</title> to indicate that you are viewing the results page as well as the number of results found, or which ones you are displaying.

It may be useful when this is implemented within a template to actually submit to a named anchor or ID that is just above the desired target so that the target isn’t right at the very top of the viewport.

Providing some other visual cue to draw attention that particular node/link would likely provide benefit as well.

This technique could be applied to any form on a page that submits to itself.