A Web for Everyone Blog

Accessibility is often focused on how to design and build digital products or physical spaces. But understanding the people with disabilities who will use those products is just as important. Enter ethnography and the importance of research that goes “face to face” with real people in the real world.

Frances Harris is a medical anthropologist who works with people with disabilities to explore the social, economic, and political contexts of their lives. Her projects look at how to make people’s lives and working situations easier and more accessible.

Transcript available.   Download file (mp3).   Duration: 32:52 (13.5MB)

Frances joins Whitney Quesenbery for this episode of A Podcast for Everyone to talk about ways to understand the lives and how to design for people with disabilities. They talked about:

• Conducting ethnographic research with people with disabilities
• Understanding the complexity of people’s lives
• The intersection of the outside observer and the inside perceptions
• Privacy and independence and how they are perceived
• Barriers to voting for people with disabilities

Frances Harris is a medical anthropologist at Center for Assistive Technology and Environmental Access (CATEA). Her current work investigates how better assistive technology and workplace accommodations can affect health, activity and participation in social and work activities. She received her PhD from the New School for Social Research.

Resources mentioned in this podcast

• Center for Assistive Technology and Environmental Access at Georgia Tech (CATEA)
• “Understanding Voting Experience of People with Disabilities” by Jon Sanford, Frances Harris and others
• Training course for poll workers

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes  –   Follow @awebforeveryone   –   Podcast RSS feed (xml)

Transcript

Whitney Quesenbery: Hi, I’m Whitney Quesenbery, I’m co-author with Sarah Horton of “A Web For Everyone.” Today, I’m talking to Frances Harris. She’s a medical anthropologist, whose research focuses on people with disabilities. She’s part of an amazing team at CATEA. That’s the Center for Assistive Technology and Environmental Access at Georgia Tech.

Hey, Frances, thanks so much for joining us.

Frances Harris: Hi! It’s my pleasure.

Whitney: Lovely to talk to you. We have so much to talk about, but I want to start by asking you about what it means to be someone with anthropological training in the work you do.

Frances: Unlike traditional anthropologists, whose methodology has historically relied on participant observation, I work more as a qualitative researcher, which is a term that was coined, I think, back in the ’80s to distinguish researchers from quantitative researchers. It differs from anthropology, which is more grounded in theory and history.

Qualitative research borrows research techniques from a variety of social sciences, including anthropology.

As an anthropologist, working in disability, I do mostly semi-structured and open-ended interviews. The research questions of a particular project tend to guide the development of an interview script. The anthropology side of my research is in my interest in context — the social context, the economic and political.

I don’t always get to use that data during an analysis, especially when I’m involved in a quantitative study, but it can set the stage for thinking about meaning. For example, what voting or disability has for different people. How they live their experiences as a person with disability, or as a voter, in the context of family, social relationships, work, politics, et cetera.

Whitney: Do you think that it makes a difference when you’re interviewing someone that you’re in their context?

Frances: Do you mean in person interviewing? Oh, yes!

Whitney: Not just in person. Do you think it makes a difference when you’re interviewing someone, not just that you’re talking to them face-to-face, but that you’re actually going places to where they live or work?

Frances: Oh, yes. That is closer to a traditional methodology of anthropologists, called “participant observation.” When you’re doing interviews and you’re getting to know somebody, the quality of the data you get is really only as good as your ability to establish a relationship with them. That’s much easier if you’re face-to-face, or if you’re actually in the place where they are. Observing and talking to them in the context of the activities of their daily life, or the activities that you actually want to examine.

Whitney: So you’re getting more information than just what they say?

Frances: Yes. One of the great things about participant observation is you can observe the differences between what people say they do, and what they in fact can be observed doing. I don’t mean to say that there’s some dissemblance or deceptiveness going on, but people’s meanings change. There can be a discrepancy between verbal reports and observed behavior for a lot of reasons.

People may be a little fearful because of social or legal consequences. Memory is selective. People can repress certain aspects of their behavior that they may be embarrassed or reluctant to talk about.

Whitney: I had a really good example of that recently. We were working with people who use screen readers, and watching them try to use a website. There were people who were very experienced with their tools and people who were new to their tools. One of the women…It was a little painful watching her work, because she really was still learning the tool, and she had to work very slowly.

At the end of it, we were all like, “Oh!” I felt like I’d been mean to her by making her do all this work. She said, “Isn’t it wonderful that I can do this myself?” Because her vision was going. She could see the navigator on the screen, but not see well enough to read. She had this mix of navigating with the mouse, but also using the screen reader to read to her.

To her, she had been a professional. She was losing her ability to read the screen. She thought her days of computing were over, and so her attitude was completely different than ours watching her.

Frances: [laughs] It’s very interesting to see the complexity of people’s social lives. It’s difficult to envision, let alone to articulate what those complexities are, so the observer will see one thing and the person may be experiencing quite a different thing. That meaning is so important. It’s sort of the heart of anthropology and most social science research.

Whitney: The meaning is in the intersection of this outside observer and the inside perceptions?

Frances: Yes. In one sense it is, yes.

Whitney: How did you get involved in working with people with disabilities as part of your study?

Frances: [laughs] Actually, it’s kind of weird. I was an English major in college, for most of my college life. I took a survey course in anthropology and was instantly smitten, and changed my major on the spot. I got my PhD pretty late in life, and I wasn’t sure what to do with it. I read an ad in a paper that said, “We’re looking for a research assistant to work with people who use assistive technologies,” at an acute rehab hospital here in New York.

I didn’t even know what assistive technology was, and I knew very little about disability, which was very undeveloped in anthropology at that time. They hired an anthropologist to work on a quantitative study. I had never taken statistics before, and knew very little about it.

While I was doing the study, they were intrigued by the idea of an anthropologist and I was allowed to do some interviews. Those actually helped the quantitative part of the study. From then on, I just couldn’t stop reading about disability.

Whitney: Tell me about some of the projects you work on at CATEA these days?

Frances: One of the projects that we’re working on, or that I have worked on and still am, is looking at how people who use wheelchairs part time and use other mobility devices. How they integrate them into their everyday lives. Clinicians very often have to prescribe multiple technologies. Sometimes they don’t use their wheelchairs, and one of the reasons…They wanted to explore what those reasons were.

I’ve been interviewing people at the VA in North Carolina, who live in very different kinds of circumstances. How they will use a walker, when and why, and switch to a cane. Then when do they use their wheelchair. This information is designed for clinicians, basically, to help them prescribe mobility devices with greater accuracy and give them the best care they can.

I’m also working on a project that is looking at the universal design practices in workplaces. We’re developing two surveys. One for people with employees, to look at their sense of inclusion and participation in the workplace.

Another survey is being developed for the employers or supervisors. We’re trying to look at the relation between accommodations, providing accommodations to a person with a disability, which is the more traditional way of addressing disability in the workplace, and the usefulness of universal design principles.

Whitney: Let me unpick this a little bit. Give me an example of an accommodation?

Frances: An accommodation might be a screen reader. It could be a voice-activated computer device that would help somebody who didn’t have the use of their hands. It could be an adjustable table that would allow a wheelchair to scoot underneath it. It’s usually in the form of a device, but it can also be an adjusted work schedule.

It can be allowing someone to do telework from home on certain days. What it is, it’s an individual accommodation instead of creating an environment where everybody can work.

Whitney: This is something that’s done specially for one person, as opposed to something that benefits everyone?

Frances: Yes.

Whitney: Give me an example of how one of those might be changed into a universal design approach.

Frances: For example, for wheelchair users, hallways could be wide enough, desks could be at adjustable heights, doorways can be wide enough. Accessibility into a workplace, parking areas, and being able to maneuver into a building can be done so that they can enter the building with every other employee.

The idea is to create a seamless environment, so that there’s little distinction between people with disabilities and people without disabilities.

Whitney: If you have an adjustable height desk, that’s fine at your desk, but it means you can’t work at the conference table.

Frances: Exactly.

Whitney: I met you a few years ago. We’re going to indulge a little bit of my obsession with elections. I met you a few years ago when you did this really great study of the voting experience for people with disabilities. Full disclosure, I actually was the coordinator for this grant from the Elections Assistance Commission.

One of the reasons I was so excited about this project was that most of the work trying to understand the voting experience of people with disabilities has been in quantitatively, through surveys and looking at census, and actually data. Your study was one of the few that really looked more deeply at the actual experience.

Voting is such a private activity. How did you do the study?

Frances: We recruited people from a number of places. We wanted to get a very wide range of voters with disabilities. All different disability types, from mobility to vision to hearing. We started recruiting from the CATEA consumer network at CATEA, which is a listserv, or a roster, of about a thousand people with disabilities who would like to participate in research.

We also posted invitations to participate on community and disability listservs, also in dependent living centers. We used both interviews and observations. That was an especially fun study to do, because we did get to observe as well as to interview. We did those during the 2011 and 2012 elections.

Whitney: What did you do? Go to the polling place with people?

Frances: Yes. A researcher would either meet a subject, a voter, at the polling place, or they would travel with them. The voter would vote. The researcher was not allowed to assist, but they observed the voter’s interaction with voting machines, with poll workers, with the entire election polling place process. Then directly afterwards, they were interviewed about their experiences, which was very helpful.

Whitney: What did you learn?

Frances: [laughs] We learned a great deal. We interviewed about 50 people. When we looked at the data, we acquired a tremendous amount of data. We found three basic categories that people were concerned about and address in the interviews and in the observation of interviews.

What was the social environment of polling places and that was dominated chiefly by co-workers. We look at the facilitators and barriers. What made it easier for people to participate in the voting process and what hindered them?

Sometimes, the facilitators and the barriers were the same. For example, friendliness and courtesy was considered to be a great facilitator. A knowledge about voting procedures and technology was also considered to be a great facilitator. At the same time, the lack of knowledge about voting procedures of technologies was also cited as a chief barrier.

A second thing that emerged was pre-election information about valid issues or location of polling sites, registration procedures, and how to use the voting machines.

The primary barriers included to help you find information of candidates, the accessibility of the precincts and the voting machines, and inconsistent information where you get information from one source and from another source.

The importance of the pre-election information was one of the things that made some voters want to vote absentee as opposed to go into the voting place.

A third barrier that emerged was the physical environment of the polling places. This has been address probably more often in the literature. People look at the architectural and community factors. The accessibility of the polling place, its location compare to their home, was there sufficient space inside the polling place.

Adequate signage and posters? Were voting booths set at the right position for somebody with the wheelchair? Those kinds of things.

The level of detail about the physical environment was a very detailed list of things that could act everything from audio output to adequate and adjustable fact size. As I said, the physical environment was not just people’s mobility, disabilities but vision hearing, cognitive, manipulation.

When we also analyse the data, it’s very interesting. We found four major things that emerge from the interviews and observation. One was the importance of sense of inclusion in the voting process. Most of the people that we interviewed tell a strong civic responsibility to vote and they also viewed it as one way for their voice to be heard and to change some of the political attitude towards people with disabilities.

The other few things privacy, and independence and all of this are interconnected. Privacy, independence and stigma with the last three needs.

Whitney: One of the questions I was wondering about and I love to ask you is, how does what you learn by deep diving into something like voting give you insights into broader daily experiences that we could use for other kinds of products we’re working on?

Frances: I think elections are extension of many of the challenges of daily life for people with disabilities. To my knowledge, there’s been a little anthropological attention paid to them. Just like every other aspect whether it’s people’s workloads or family life, elections and daily activities reflect people’s attitudes and vice versa.

This is how the meaning is created. Privacy can have very different and sometimes contested meanings in voting, for example. The location of voting votes was so much conscientious and interpreted differently.

One voter like it when voting machines were segregated from voting machines for people without disabilities because it gave her quiet and that sense of isolation, gave her more time and more quiet and peaceful environment to voting.

Somebody else felt that she was being segregated from other voters and that she was being excluded. She was concerned that her vote would not be counted. The same commendations to a person with disability can play out very different. Their meanings and interpretations, and their attitudes can vary.

Whitney: One of the things I’m hearing is that we should be very careful not to treat people disabilities as though they’re one big user group that has all the same attitudes?

Frances: Exactly. Privacy and independence are all very important things that they can be interpreted quite differently.

Whitney: The other thing that I notice is talking to someone about a project who’d work on making bank machines accessible and they said one of the things that’s interesting is that it’s not like people with disabilities didn’t have cash before. They have a way to get cash and it takes awhile for them to transition to using a new solution because they need time to check it out.

Trust that it’s going to be better than what they’ve been doing before so it’s not just making an accessible all. It’s making it a better experience than what you have before.

Whitney: I want to turn to some practical questions because I know that the whole question of doing more ethnographic research really hot topic that you actually place, but often people don’t know how to get started. I want you to start by picking up on something you said about the voting project, which was you talk to 50 people. That’s a huge number of people.

Frances: Yes. We have a staff of six. It wasn’t just me.

Whitney: So you split that up in a number of people because one of the assumptions about ethnographic work is that it’s very small numbers. What I’m hearing is that it doesn’t have to be.

Frances: No. If you have a large research staff, you can follow and interview and observe many, many more people. If it’s over a period of time, if you have a year to spend with people you can observe many more people. When people go into the field to do participant observation in the city or on a reservation, you’re usually observing and interviewing many, many people over that period of time.

Whitney: Is this something that…Let’s say you run a UX department for a big product, is this something that you could do a little bit of the time over a longer period of time and just wrapped it into all your other work?

Frances: That’s interesting. Yes, I think that would be possible. There needs to be certain continuity, that continuity that doesn’t have to be in terms of everyday. If you’re in a place, in a business place, where it’s a large population and you have other things to do, yes, you can integrate it. But you would still need to focus on those questions specific to that project.

Whitney: If UX researchers want to include people with disabilities in their research, one of the things that everybody worries about is, “How do you get started?” Do you have practical advice, tips about recruiting or effective working styles that you can help people with?

Frances: First of all, recruit from as many places as you can — disability organizations, hospitals, independent living centers, colleges. You can also use a technique called snowball sampling, which is you ask the people you got your interviewing or doing research with if they know somebody else who might be willing to talk.

One of the reasons you want to do this is that many people who volunteer for research projects have a heighten consciousness and want to do something to improve their lives and the lives of others with disabilities.

This is great, but you also need to find people who are more isolated and hidden, hard to find. They provide a greater range of information and insights than people who have a more heightened consciousness. Another reason you want to have a very wide range of subjects, as wide a range as you possibly can, is to establish a working relationship with the subjects.

As a matter of fact, the word “subjects” is slightly contentions right now. I use them. I use that term in quantitative research. But in qualitative research, it’s not such a great term to use. Subjects reflect an inherently passive role in a research project. Researchers administer questionnaires that are designed by the research. They analyze results.

They do lots of things that confirm the expertise of the researcher. But, in reality, subjects are the experts. They have the knowledge that we want to understand and use. The question that researchers and designers need to ask themselves is, “How do we find out what they know?” It’s as much an attitude towards research and people. It has implications for how we define our research goals.

Whitney: I was about to say it sounds like a big shift in your attitude about your research. It shifts from the, “I am the person in the white coat studying things” to “I’m engaging with people as I work with them.”

Frances: Exactly. There is something called — I don’t know how familiar people are — participatory action research, which is a research approach that became increasingly popular within disability studies. It looks at the researcher-subject relationship.

Unlike the traditional research model, which pretty much renders a subject as a passive object of study, participatory action research proposes a collaborative relationship between the researcher and the subject. When it’s applied as a strategy, it really challenges researchers to adapt and incorporate subjects’ voices into their study design and methods.

When you’re looking at, for example, designing ANDI user or research products, it’s useful to incorporate people with disabilities, their views, their identification of research questions, and problems, and goals right from the beginning. The research should be collaborative and iterative throughout the entire process.

They can be included in developing the methods. You could do [inaudible 21:35] focus groups through interviewing and in project meetings so that their voices are consistently being heard throughout the process.

Whitney: What you’re saying is that it’s not just that you sit back in your office, you think of a research question, and you think about how you are going to do it, but you actually build the research question through research?

Frances: Right. That requires a working relationship with the people that supposedly you want to study or develop something for.

Whitney: I’m sitting here looking at a sign in my office, a poster that says, “Design with, not for.” It comes out of the civic design movement. But I know one of the early mantras of the disability rights movement was “Nothing About Us Without Us.”

Frances: Absolutely. People with disabilities had been studied by medical and health care workers for many, many years. The field of rehabilitation looks at disability primarily as a health, and medical, and functional problem. But disability is also defined socially.

Whitney: Let me do this analogy. If I was working on a mobile device, a mobile app for instance, I might be interested in how someone manipulates the device, what do they click on, what do they tap on, how do they use it.

But I also might be interested in when, where, and why they use it. That’s much harder to do by hauling someone into a research room and asking them questions. You get a much richer picture if you actually watch them using it. You’re hanging out with them at the mall and you see when they pull their phone out to do something.

Frances: I think that there were some early studies on how people used computers. Observers went into the home and found out that computers were not being used just by individuals but by families, and all at once. That changed how computers were marketed, from what I understand, since early on.

Whitney: One of the things that we’ve said a lot is that we need to build relationships. I know that a lot of UX research is done by recruiting through ads in newspapers or mailing lists and so on.

But I’m hearing you say that, in order to do this deeper research, you need to get a little deeper, that is, you need to actually find the independent living center, and maybe go down and meet them, and put in a little groundwork upfront to build a relationship with a community.

Frances: Yes. That’s absolutely essential, both from just pure social science research, but also for designing. Watching people work or do something in the context of their everyday activities is critical to understanding what they really want, what they’re really using it for, and what they need, how to make it better.

Whitney: Is there a middle ground? One of the suggestions that I’ve heard is that, instead of bringing people to your office or to your research lab, you could go someplace. You could go to the LightHouse for the Blind, which has social centers, or you could go to an independent living center.

You’re still not quite in their home environment, but you’re in an environment where they’re comfortable. Does that make a difference?

Frances: Completely. As I said, you need to establish a relationship with people, and part of that is making them comfortable. As a researcher, you’re not going to be able to establish a great relationship with everybody.

But one of the things you can do is to take them out for a cup of coffee or offer to meet them in a place that they’re the most comfortable in, and allow them, also, to guide the conversation to a degree.

You’re coming in as a researcher desiring certain goals. But they have things they want to tell you. One of the most important things about establishing that relationship is learning how to listen.

For example, in the voting project, when I was interviewing home workers at one time, they would say, “Oh, we don’t have any people with disabilities come to our polling place.” That’s because they were thinking of disability as a wheelchair, just somebody in a wheelchair, or somebody with a white cane.

But then you would get them talking, and you would find out there was somebody there with a hearing aid or somebody who had recently come back from Afghanistan who was jumpy. These are the kinds of issues that you’ll get when you establish a relationship and get people talking.

Whitney: One of the things that scares a lot of people about working with people with disabilities in their research is that they’re afraid they’ll say something wrong, or insult somebody, or just be hapless. Any tips?

Frances: First of all, there is a disability etiquette. There’s plenty of information about that on the Internet, but I wouldn’t worry about that.

People with disabilities value, from what they’ve told me, the effort to be courteous that they may make a mistake. But I think they’ve seen it all, and they’ve done it all. They appreciate the effort to be kind and courteous even if they make a specific mistake.

Whitney: So be human?

Frances: Yes, be human, be kind, offer help just as you would to anybody. Don’t be afraid of making a mistake.

Whitney: Does it get easier?

Frances: To not make a mistake? [laughs] Yes, because people will tell you. I think intuitively, when I first started talking to people who used wheelchairs all the time, I would sit down. I later found out that that was considered something courteous.

But then I would watch people occasionally touch somebody’s wheelchair. You could see that it was as if somebody had touched their head or some part of their body. You realized that was a no-no, after a while.

Whitney: You can think about what reactions you get and build on those?

Frances: Yes.

Whitney: You talked about how many different kinds of disability there are and how many different kinds of people with disabilities you’ve worked with. Do you have to adjust your research plan or how you actually conduct the research to accommodate different kinds of disability? How do we factor that in?

Frances: I did a research project looking at how teleconferencing equipment was used for business meetings by people with cognitive disabilities. What was interesting is that we used teleconferencing as the basis for how we conducted the focus group.

You were able to have people articulate why, their reactions, and the problems they were having using the equipment as you were actually asking them about what context they use, teleconferencing, and why they liked it and disliked it.

I’ve worked mostly with people with mobility impairments. I have not worked with anybody with a vision or hearing impairments, but I have worked with mobility and cognitive. There is an overlap.

With people with cognitive disabilities, there’s patience giving people time to process information in different ways. Yes, there are different ways of approaching, I would say, research with different types of disabilities.

Whitney: So just as you need to approach each participant as a person, you need to adjust your own personal style to meet them?

Frances: Yes, absolutely. Cognitive disabilities, for example, is a huge category. It can cover everything from autism to how people process knowledge, dyslexia. It’s useful if you have a sense about what their issues are. But otherwise, again, it’s just a matter of being patient, and giving people time, and asking them what they need.

That’s another thing. We shouldn’t be afraid to ask people what they want, or, “What’s the best way to approach this research?” or, “This is what you want to do?”

Whitney: After all, you’re hauling them in there to ask them a whole bunch of questions anyway.

Frances: Exactly. [laughs] What makes them the most comfortable.

Whitney: We’ve been talking a lot about how you do your work and why an anthropological approach or an ethnographic approach is so useful. Can you give me an example of how a designer might take all this information and where it might lead them in their design process?

Frances: It allows the designer of research to see the unintended impact a meeting, a device, or a behavior, or a product may have in different context. You can observe how an idea can change or morph into an unintended use.

There’s an expression that’s always been important to me. It was coined by William Gibson, who was sort of the elder statesman of cyberpunk. He wrote, “The street has its own uses for things.” One of the most obvious examples is the Internet itself.

The Internet was originally conceived as the network for researchers to exchange scientific information. Instead, it’s become this rapid communications medium and a means of establishing non-geographical communities. It contained a lot of exploitable niches that are still being developed, but which were unintended by its original developers.

Whitney: You can see hints of that. You can look at how somebody has done something just for themselves and think, “Wow, this something that could be a broader product.”

Frances: Exactly. The point is when you’re observing a person’s behavior or interviewing them, you need to anticipate myriad ways in which an activity or device can be made useful or meaningful to a person.

Whitney: That is a great way to end. Thank you so much for joining us, Frances. This was a wonderful conversation.

Frances: It was my pleasure. Thank you.

Whitney: To our listeners, we’ll be posting links to any of the projects or resources that we’ve discussed today. You can find them on the A Podcast for Everyone page on Rosenfeld Media and in the UIE All You Can Learn library.

Thanks to you for listening in, and a special thanks to our sponsors, that’s UIE, Rosenfeld Media, the Paciello Group, and O’Reilly, for making this series happen. Be sure to follow us at A Web for Everyone on Twitter for information about future podcasts.

WordPress powers over 25 million sites with more than 14 billion pages viewed each month, making it one of the most popular web publishing platforms. Imagine if every one of those sites was accessible.

Joe O’Connor has been a leader in making that happen, through the WordPress accessibility team which works from the inside to make WordPress into a web publishing platform for everyone.

Transcript available.   Download file (mp3).   Duration: 21:09 (13.5MB)

Joe joins Whitney Quesenbery for this episode of A Podcast for Everyone to talk about what it takes to make an open source platform that can help authors make their sites accessible. They talked about:

• How can you make your WordPress accessible?
• What are the best accessible-ready WordPress themes?
• What tools can help you keep your content accessible for everyone?

Joseph Karr O’Connor lives in Santa Monica, California. When Section 508 came into effect in 1999 he began leading Accessible UX teams creating accessible web environments.  Joe has been using WordPress in support of non-profits, research, and university news since 2005. Now leading Cities, a world-wide effort to build free accessible WordPress themes, Joe also contributes to Make WordPress Accessible and asks you to get involved. He’s known on Twitter as AccessibleJoe.

Resources mentioned in this podcast

• WordPress Guidelines: Accessibility
• Accessibility-Ready WordPress Themes
• Making WordPress Accessible
• WP Accessibility plugin by Joe Dolson
• The Cities project 
• Accessibility checking tools

Accessible WordPress themes that Joe recommends:

• Blaskan
• Simone
• WordPress Twenty Fourteen
• WordPress Twenty Thirteen

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes  –   Follow @awebforeveryone   –   Podcast RSS feed (xml)

Transcript

Whitney Quesenbery: Hi, I’m Whitney Quesenbery, I’m co-author with Sarah Horton of “A Web For Everyone.” Today, I’m talking to Joe O’Connor, known to his friends on Twitter as “accessible Joe.”

Joe’s been using WordPress for almost 10 years. That’s a really long time in Internet years. Hi, Joe. Thanks so much for joining us.

Joe O’Connor: Hi, Whitney. Thanks for having me.

Whitney: I’ve been thinking about WordPress a lot. You probably know this, but maybe everybody in the audience doesn’t, that WordPress is one of the largest web-publishing platforms in the world?

The stats I looked up said that there are over 25 million sites and more than 14 billion pages viewed each month. That’s gigantic.

These sites range from little, tiny personal blogs but also big, corporate sites, like CNN, UPS, CBS, TED. That, it seems to me, is a really large target for accessibility. That’s a really large target for accessibility.

Joe: Yes, some of the other stats that I’ve seen, say that WordPress runs about 20 percent of the Internet. When I found those statistics I was astounded, but indeed it makes it a really large target for accessibility.

Any change that we make in the admin, in the back-end, any seams that come out that are accessible, are used by millions of people, and so it’s an important segment of accessibility work.

Whitney: I’ve noticed that it’s still a little hard to figure out where to start. When we built the user experience magazine site, we knew we wanted it to be accessible, but we finally decided we had to start from an accessible theme, and it was hard to figure it out.

I noticed recently that 2014, the brand new default WordPress theme, is now tagged “accessibility ready.” Can you tell us what that means?

Joe: I’m the Accessibility Team Lead for WordPress, and on the team we have many, many talented people. We set out to make a tag for accessibility, and we thought things through, and concluded that though there are those things a theme developer can do to make sure a theme is accessible.

Unless the content people use accessible methods, it will no longer be an accessible site. I’ve personally had content authors steadfastly refuse to write alternative texts for graphics.

Claiming that their work road was already too much to handle. Did I mention that I spent many years in higher education?

[laughter]

Whitney: Yes, hard to get people to change, isn’t it?

Joe: After some deliberation, we acknowledged this fact with a tag that signals that this theme is accessibility-ready as in, ready to add accessible content.

Whitney: For someone like me, who’s in-between. I’m not really a developer, and I’m not just a content developer. That means that if I use that theme, and I don’t mess it up, and I then put my content in the Web with good accessibility principles, then I’m OK.

Joe: Yes. You still have to check your work, and I have some recommendations for tools to do that, which will appear on the page with this podcast, the links. Accessible themes are still very few. We’re reaching out to more developers than ever before.

It’s been a lot of action this year in WordPress accessibility. A lot of mainstream WordPress venues, like WP Bacon, and some other podcasting operations have done features on us.

And we’re awed by the response from the developer community. Nonetheless, there are still very few accessible themes.

Whitney: You find those themes by going to the WordPress.org site, and going to the themes, and searching for the tag “accessibility-ready”?

Joe: There’s a hitch with that! We recently negotiated our way through getting the “accessibility-ready” tag to stick. Some themes mention the word accessibility in their tags, and a few of them have used the “accessibility-ready” tag.

Until recently, we had no way of coming back to them and saying, “You’ve used accessibility-ready.” Did you mean this? Did you copy the tag from another theme? Do you mean it’s accessible because it’s accessible on the Web?

Whitney: Right, truth in advertising, and making sure that we really mean accessibility in the sense we’re using it.

Joe: We’re now able to come back to theme developers and say, “OK. You’ve used the accessibility-ready tag. We’re going to assess your theme for accessibility.

If it fails we will come back to you and tell you what failed, help you make some changes, If you fail to make those changes with 10 days, the tag will be removed.

Whitney: You’ve got some teeth in it, but you’re also helping people out?

Joe: Yes, we’re extending, scaffolding all the way to everyone. We tell everyone we talk to that we’re ready to help, we’re able to help, and we’d love to help.

Yet, there are still very few accessible themes. The accessible themes that I use or recommend, one of my blogs uses Blaskan, B-L-A-S-K-A-N. That’s by Per Sandstrom.

The link will be on the page with the podcast. There’s a new theme, Simone, by Morton Rand-Hendrickson. He works at lynda.com. He does the WordPress videos there, many of them, and he’s a really great guy. He’s stepped up with a team recently called Simone.

One of the themes that ships with WordPress, when you download WordPress and install it in a site, you’re going to get Twenty Fourteen. Twenty Fourteen is accessibility ready, and it has that tag because the accessibility team worked on Twenty Fourteen to help make it accessible.

It has skip links. It has a number of different things that make a theme accessible. If you’re building a theme, I suggest starting with underscores. That’s not spelled underscores, its _s. But we call it underscores, which has recently been accessibility enhanced by Morton Rand-Hendrickson.

“_s” is a blank theme that developers can use to quickly prototype and build themes. It has some accessibility enhancements now, which will go a long way to helping them.

Whitney: That’s great. Are there other tools that someone developing a site could use? Are there good plugins and things?

Joe: Well, there’s a plugin by Joe Dolson, who is a mainstay of the WordPress Accessibility Team. Joe has a plugin called WP Accessibility. It’s for everyone. It’s not so much to help developers. I’ll take that back. If developers would take a look at WP Accessibility, and look at what it does.

It will help you install skip links, for instance. All you have to do is click it, and it’ll go there. It’ll happen, and your site can have visible or invisible click links. A skip link becomes usable when the user tabs into the site.

There’s a menu, and it says “Skip to Content” and you can skip to content. The plugin uses a JavaScript to move both visual and keyboard focus at the same time.

Whitney: This is pretty interesting because it sounds to me like the accessibility team at WordPress has really built, let’s use the word “scaffolding,” and I really like that because you’ve got guidelines, you’ve got a tag so you have a way to check sites and help developers get there.

You’ve got some plugins to help them, but the thing that seems to be really revolutionary is that you’re working on the WordPress Team. You’re not just coming in afterwards and saying, “This works. This doesn’t work,”

But you’re building the tools to help people build accessible tools. That seems like a real shift in the emphasis from being outsiders asking for things to be made accessible to being insiders helping build the plumbing that makes it possible to have accessible sites.

Joe: The beauty of WordPress as with other open source projects is, indeed, that it’s open source, and everyone’s invited to work on it. Anyone can work on it, and are encouraged to work on it.

Some of the older members of the team have been working on it for years. We focus on core, that’s called trunk. We’re working on live code to remediate accessibility situations that come up when people who don’t use accessible routines, contribute to core.

Whitney: You’re working on the team that’s building the core code that underlies WordPress, is that what I’m hearing?

Joe: Yes.

Whitney: Very exciting. You had an example of how the team has worked to make sure that what goes out in WordPress is accessible.

Joe: For instance, right now, we’re working on focus indication in the left navigation bar. The left navigation bar has some focus indication right now. Dark grey turns to black when you select one of the main menu items.

Then, as you move over into the submenus, the titles of the submenus change from a light grey to a dark blue. For those of us in accessibility, we understand that you can’t have color as the only means of signaling something.

We’ve added a visual indicator by drawing a white or a black box around the selected item. There are eight different color schemes to admin, and so some of them do better with white, some of them do better with black.

The idea is to make a contrasting color box appear around the selected item so that now there are two visual focus indicators.

Whitney: Like choosing that you want to edit pages or you want to edit posts.

Joe: Right, so when you go to the post’s main heading, you’ll see that the focus indicator is dark grey turning to black, plus there’s a white box around it.

Whitney: You’re not talking about making the sites that are built with WordPress accessible. You’re talking about making WordPress itself accessible. So that someone who’s using assistive technology or who has low vision can use WordPress to write their own blogs and to develop their own blogs.

Joe: Right, accessibility is required on both ends.

Whitney: That’s pretty revolutionary. [laughs] I say that with complimentary aim. We do often focus on the end users and making sure that we can build something accessible.

But I know more and more people who are developers who are also assistive technology users, and it’s great to hear that WordPress is accessible to them as developers.

Joe: I’ve been doing accessible UX since 1999, and in 1999, we thought, “Wow, all the websites are going to be accessible,” so maybe not revolutionary, but evolutionary. We’re developing tickets. We’re helping people write solutions for the tickets.

Some of us can write code. Others can’t write code. Some of us are better at documentation. We’re doing everything we can to help the WordPress developers with the back end, with core.

Then we’re doing outreach at Word Camps and at meet-ups to theme developers, to help them understand that we have resources for them to use to make their themes accessible.

Whitney: Now let’s move forward to an actual blogger, someone who’s maybe developed their own site theme, maybe they had someone else develop it.

Now they’ve got their site set up and they’re adding new content all the time, new blog posts. What are the most important things that they should do to make sure that the content they add to their site is accessible?

Joe: At this year’s Access U in Austin, Texas, presented by Knowbility, I did a class about adding accessible content to WordPress sites. You can download the Word Doc on my site at AccessibleJoe.com/tools. The link will be on the list of resources on the podcast page.

In it, I do mention some of the ins and outs of WordPress itself, so how to use some of the dialog boxes and where you put the alt text for images and all that.

There are some things that anyone can pay attention to in any web page, such as adding alternative text descriptions to media, using headings and lists, use simple language, if you can. Certainly if it’s aimed at physicists, you’ll have to use your judgment.

Whitney: If you’re talking to physicists, talk in physics, but if you’re talking to everyone, the mythical everyone, speak a language they know.

Joe: Ensure that the link text makes sense out of context. Screen readers can separate out lists of things. They can separate out a list of links.

If you used the default in WordPress, which is read more, or read more of this story, what they’ll hear is a list of links that say read more, read more, read more, read more.

Which one would you choose? I don’t know. Make sure that the link text makes sense. The plugin WP Accessibility will change that for you and append the story name to read more and the story name. Your links can be expanded to make sense.

Use some extra text there. Don’t rely on visual or audio cues. Don’t say, “Below, I’ve posted this,” or, “In the green box, you’ll see this.” Use of contrasting colors is good. Make sure that your color contrast is sufficient to meet the thresholds.

Pay attention to complex tables. If you have to make a table, make it accessible. There are all sorts of resources on the web for making accessible tables. Also, pay attention to creating accessible documents.

Whitney: If you post a PDF file that people can download, make sure that’s accessible?

Joe: Yes.

Whitney: These all sound like really basic content tips, applied to WordPress, nothing particularly special here. In fact, I do authoring in WordPress, and I’m not a coder, and I’ve found it pretty easy to do everything except tables.

I have to say, the table editor doesn’t help me all that much, even with tables, at all. Certainly the alternative text is right there in the media files and headings and lists, all the themes that I’ve ever worked with come with heading and list code built into it.

And link text and language, of course, is your own writing. For me, the only thing that I still find hard to do is tables.

Joe: I’ve been around for a while, and the only thing we had was a text editor in the beginning.

Whitney: That’s right…. We do have to go into that text editor and edit and put the table heading codes in.

Joe: I code my own tables. I don’t rely on the wysiwyg editor Tiny MCE. Tiny MCE, by the way, has been upgraded and updated for accessibility greatly in the last iteration. In 3.9, there are more accessibility routines built into Tiny MCE.

Whitney: That’s the basic post-editor?

Joe: Yes, that’s the wysiwyg editor.

Whitney: If I could paraphrase what we’ve been talking about, it’s start with an accessible theme to build an accessible theme. Follow the basic rules for accessible content.

Make sure that anything you add, whether that’s a form, or a media, or a document, that you’re uploading is accessible. It doesn’t really sound that hard. Got any final words of advice?

Joe: It’s a matter of civil rights, and you’ll hear this from every accessibility person on earth. With the blind experiencing 70 percent unemployment, partly because of lack of access to information, with disabled people all over experiencing high levels of unemployment.

We owe it to our fellow human beings to make things accessible. Really, it is easy once you get the routines down. It’s like any other workflow item. Adding all texts does not take that much. I’ve been told otherwise, [laughs] simple routines can help a lot.

Whitney: Good advice. Thank you so much for joining us today, Joe. We’ve been talking to Joe O’Connor, known on Twitter as AccessibleJoe.

If you’re interested in learning more about how to make your WordPress site accessible, we’ll have a list of resources available up on the podcast page along with the transcript.

Thank you so much! Thanks to all of you for listening in, and a special thanks to our sponsors, UIE, Rosenfeld Media, The Paciello Group, and O’Reilly for making this series happen. Be sure to follow us at A Web for Everyone on Twitter for information about future podcasts.

Medical records are moving online. That means they have to be accessible, but it’s also an opportunity to improve them – especially personal health records intended for patients to use to monitor their own heath. Dean Karavite explains how a project to design a personal health record for people with disabilities led to some innovative ideas that could make them more useful for everyone.

Transcript available.   Download file (mp3).   Duration: 26:36 (17.3MB)

Dean joins Whitney Quesenbery for this episode of A Podcast for Everyone to talk about the work he’s been doing in a project to create usable and accessible health records.

• What are personal health records?
• Why are they important for people with disabilities?
• What have they learned about the accessibility of electronic health records?
• What can you learn about any product by testing it with people with disabilities?
• How does the design of the Cuisinart connect people with disabilities and the Mac?

Dean Karavite is a Human Computer Interaction Specialist for The Children’s Hospital of Philadelphia (CHOP). He has fifteen years experience in clinical informatics, was a usability specialist at IBM, and has experience developing assistive technology solutions for people with disabilities. He got his masters degree in HCI from the University of Michigan, School of Information. About the project collaborators.

Resources mentioned in this podcast

• Project website: Accessible Designs for Personal Health Records
• Project Research Report
• Useful Personal Health Records: Designing for Accessibility (User Experience Magazine)
• Book: Just Ask by Shawn Henry
• The Surgeon General’s Call to Action to Improve the Health and Wellness of Persons with Disabilities
• Marc Harrison
• CBMi and the Children’s Hospital of Philadelphia
• Inglis Foundation
• National Center for Accessible Media at WGBH
• NIDRR – National Institute on Disability, Rehabilitation, and Research
• Liberty Resources
• IDEO and OpenIDEO
• Dragon speech recognition software
• Book: Design for Care: Innovating Healthcare Experience by Peter Jones

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes  –   Follow @awebforeveryone   –   Podcast RSS feed (xml)

Transcript

Whitney Quesenbery: Hi, I’m Whitney Quesenbery. I’m co-author with Sarah Horton of “A Web For Everyone.” Today, I’m talking to Dean Karavite from the Children’s Hospital of Philadelphia, where he’s a human interactions specialist in clinical informatics.

That sounds like a mouthful, but it really just means that he works on making medical information usable for both patients and health professionals. One of his current projects is designing personal health records that are useful for people with disabilities. Hi, Dean. Thanks so much for joining us.

Dean Karavite: Hello, Whitney. Thank you so much for inviting me to talk about our work.

Whitney: Let’s start by talking about what you mean by a personal health record for people with disabilities. What kind of problems are you trying to solve?

Dean: First, I think we can start with some definitions. They’re actually important for a number of reasons. If you were to go to the healthit.gov website, there’s a page that provides precise definitions for different systems used in health information technology.

What’s interesting about these definitions is they’re largely based on system interoperability.

What that means is the ability for these systems, or the lack of ability, for these systems to share information between different healthcare providers or organizations, as well as to patients.

Whitney: This is all technical. This is “Can one computer talk to another?”

Dean: Yes, in effect. If I could go through some definitions, and then I can explain to you why it’s important to people with disabilities. First, we have the electronic medical record, or the EMR.

This is defined as the electronic version of a patient chart, but exists only within a single healthcare organization. For example, Children’s Hospital of Philadelphia or another hospital in town, or even your doctor’s office around the corner.

Corresponding to that on the patient side is what’s often referred to as the patient portal. This allows patients or family members to log in, access some of the record, and perform some basic tasks, like prescription renewals, lab results, things like that.

Again, like the EMR, they are confined or limited to a single healthcare organization. You might be receiving care from different providers, and each might have their own EMR, and therefore, you might have multiple patient portal accounts, none of which are connected.

Whitney: That doesn’t sound very good.

Dean: No, it’s a big problem, and there are many people working on this. Next, we have another definition. The EHR, or electronic health record. This refers to, again, a clinician system, but unlike the EMR, this has information about the patient from any and every provider they’ve ever seen.

Whitney: Now we’re getting a little more patient-centered.

Dean: Yes, but the problem with the EHR is that, at least in the United States, and at a practical level, it really doesn’t exist yet.

Then, we have the PHR, or personal health record. This is defined as a system that is managed by patients, where they can collect, compile, organize all of their information from multiple healthcare providers in one place, but the problem there is it’s not easily connected to healthcare providers.

Whitney: We have a mythical EHR, the thing that’s going to pull all of our data together, and then we have to make up for it, something patients can use on their own systems.

Dean: Right.

Whitney: We have a mythical EHR that will pull everything together, but doesn’t quite yet. Is it filling a gap to say we have a Personal Health Record, which the patient can manage to solve that gap?

Dean: Yes, it allows them to manage their own information, but it doesn’t allow them to easily share that information with new or existing healthcare providers.

Whitney: Another gap appears.

Dean: Yes, but in our project we decided to use the term PHR somewhat generically, and imagine hopefully a near future state where interoperability is solved.

Whitney: This sounds like a pretty big generic problem, and I’m sure you’re right. There are probably thousands of people in the US working on it, if not more, around the world. Tell me where this connects to accessibility.

Dean: As part of our project exploring accessible Personal Health Records, one of the methods we have applied was performing a survey with 150 people with different disabilities. In that survey, we had our participants’ rate over 20 health topics in two ways.

First, in terms of how important the particular topic was to their health and healthcare, and second, their current level of satisfaction with a particular issue or topic.

The number one, most highly rated issue in terms of importance was the ability to share medical information between different providers’ offices, and hospitals.

Whitney: This isn’t just technical…you’re just looking at a chart, and saying here’s a gap, let’s fill it. This is actually coming from people. Are you talking about people with various kinds of disabilities, here?

Dean: It certainly applies to people with severe disabilities, but also anyone who’s a complex patient and receives care from multiple healthcare providers, because the real underlying issue here isn’t just the transfer of data, but care coordination, which is the collaboration in not just communication, but collaboration between multiple healthcare providers.

Whitney: When we were talking before, you said something that I thought was really important, and I want to make sure we bring it out early, which is that disability doesn’t necessarily mean poor health.

Dean: Right. The source of that idea and that concept, which I think is really a very valuable resource that your listeners might be interested in, is the Surgeon General’s Call to Action to improve the health and wellness of persons with disabilities.

It’s really available online. I’m sure you’ll be providing a link to that on your website.

Whitney: We sure will.

Dean: In the report, which was published in 2005, it doesn’t really cover healthcare technology, but it does a wonderful job, I think, of describing the overall landscape, you could say, of people, disabilities, and health, and healthcare. The authors make a number of important points.

First, and foremost, is that people with disabilities can live a meaningful and fulfilling life, but the key is health and wellness. However, they go on to present a number of studies and data demonstrating that people with disabilities encounter myriad disparities with almost every aspect of health and the healthcare system.

Whitney: Give me some examples of things that might challenge them in managing their health.

Dean: The report cites a number of measures, for example, higher risks, poor outcomes, access, really almost you can think of. What’s, I think, important about that is now we know people with disabilities are underserved by technology that’s not accessible, but they’re also underserved by the healthcare system.

Whitney: Tell me about some of the kinds of health issues, in specific, someone with a disability might need to manage.

Dean: This is a pretty large topic, and there’s different ways to think about this. As you stated before, we should not equate disability with poor health, and not think of disability as an illness.

One thing that the Surgeon General’s report stresses is that we should treat not the disability, but the whole person. This was reflected with many of the participants in our study.

For example, we met plenty of people who were disabled, but their disability wasn’t necessarily a health issue, meaning it didn’t require ongoing care or any type of treatment, nor did these people think of their disability as a health issue.

At the next level, there are people who have a disability, and while their disability isn’t necessarily an ongoing health issue, there are secondary issues related to their disability that need to be managed.

I have a few examples. For example, a person who’s blind, they might have to take some eye drops to maintain their tear ducts. Or, it could be a person who’s deaf and has a baby, and undergoes genetic testing to determine whether or not their baby has a particular variant for hearing loss.

Then, there might be a person who has a spinal cord injury and is using a wheelchair, and with that, comes a number of secondary issues. For example, first, we need to prevent pressure sores or bed sores. There are special cushions that can do that, as well as checking and maintaining skin integrity.

They also might have a urinary catheter. Along with that, we have to prevent infection, and also measure daily fluid intake and output.

At the next level, we met plenty of people where their disability was the result of an illness that required ongoing treatment, for example, multiple sclerosis or spina bifida.

Then, you had other people who had these types of issues along with other more common chronic illnesses, for example, diabetes, heart disease, high cholesterol, etc.

What we found is that we’ve learned a lot from, of course, all of our participants, but from these more complex patients, they often provided us with the most detailed, sophisticated, and even innovative ideas on what an accessible PHR should do.

Whitney: It’s interesting. Shawn Henry, who wrote the book “Just Ask” about doing usability testing with people with disabilities, has been talking about, questioning whether, we ought to be thinking about people with disabilities as extreme users.

That is people who might be particularly stressed by websites that are written to code or by information that isn’t very clear or by information that doesn’t appeal to all their senses, so that if they’re relying one sense more than other senses, they’re more likely to find a problem.

That’s a pretty interesting idea. I think what you’re saying is very much the same.

That people with disabilities use the healthcare system a lot and in many different ways, both as the people with many different chronic health problems to people for whom their health isn’t really an issue at all to people who need some monitoring of things like what you said about monitoring infections and fluid intake and outtake.

That suggests that you have a population that represents, in a very small group of people, a wide range of what a good personal health record needs to do.

Dean: Absolutely, I actually had a chance to talk to Shawn on the telephone about a month ago about our project, and she was fantastic. I agree with this. I think that many people who promote this idea of the extreme user. I have two sources where I’ve learned about this method or this concept, you might say.

First, I met a gentleman from IDEO a number of years ago. He told me that this was a foundation of their approach to design in many ways. Maybe not specifically to people with disabilities, but any extreme user who represents the tail end of the normal curve. They’re more interesting, and we can learn more from them.

Another great example of this method in practice was the industrial designer, Marc Harrison. He was both a teacher and designer at the Rhode Island School of Design. Way back in the mid-70s, he applied this approach specifically by thinking about people with disabilities in the design of the Cuisinart food processor.

Whitney: Way before the Good Grips, huh?

Dean: Yes, some people say that Harrison’s work and teaching actually influenced people who went on to design all these wonderful kitchen devices.

He actually influenced technology, too. I have an interesting little story here that I love to tell.

If you read the Steve Job’s biography by Walter Isaacson, there are two references to the Cuisinart, where Steve Jobs told the original designers of the first Mac to go out and buy Cuisinart. “It’s great. You have to see this thing.”

If you put the original Mac in 1984 side-by-side with an early ’80s Cuisinart, the influence on the physical design of the Mac is immediately obvious. Not only is the Mac designed with software for accessibility and more universal design, but its physical design had this perhaps unknown influence as well.

Whitney: This goes along with the idea I’m hearing a lot in design circles which is that, the broader your influence is, get out of your little box and look for inspiration all over the place.

In fact, IDEO’s OpenIDEO project really espouses that, because they start with inspirations as their first step where people are encouraged to go out and get as broad and crazy, as many ideas as they can, and bring them into the group.

Can you give me a story about how one of your extreme users helped you see something interesting that you wrapped into the project? I think we’ve been talking a little theoretically, and I’d love to bring it down and ground it in some of your research.

Dean: I have many interesting stories, but there’s one in particular I’d like to share with you. One of our participants was a woman who, a number of years ago, was in a horrible accident. She was a pedestrian hit by a drunk driver.

This left her paralyzed from the neck down, paraplegic. Not only did she survive her injury, but she insisted on staying at home, though confined to a bed or wheelchair, with home health aides, in order to raise, I think, her three or four children to adulthood.

Once her children were fully grown and out of the house, she had more time to pursue her own interests. One thing she did, for example, she’s always interested in art. So, she had learned to paint both realistic portraits and landscapes by essentially holding the paintbrush in her teeth. That’s pretty amazing.

She also had never used a computer, but wanted to learn. With help from one of our project partners, Inglis Foundation here in Philadelphia, and their assistive technology experts, she had learned to use a computer, but the only way she could interact with a computer was using speech recognition, Dragon Systems.

She had to learn both a PC and navigating a PC and all the different applications while simultaneously learning how to use Dragon systems. She told me a story that brought together both healthcare and technology.

A little while back, she had seen her physician who, I believe, specialized in people with spinal cord injuries. They did some lab work, and there was some particular level, I’m sorry, I don’t remember what the level was, that was low.

The doctor prescribed her some supplements to bring this level up. I believe she went home and she thought about this, and she wasn’t happy about this prescription for at least two reasons. First, like a lot of people with disabilities, she has a very fixed, limited income.

This represented an additional cost that she really couldn’t afford. Second, she just didn’t like the idea of taking a pill. She went online and did some research and identified a number of foods that could help increase this blood level.

On her own, she changed her diet and then created a spreadsheet where she tracked, not only her diet, but these different blood levels over time. When she finally reached the desired level, she went to her doctor and said, we’ve met the level.

Here’s what I did and here’s my data. The doctor was so impressed that she not only agreed with this treatment course. She now prescribes the same dietary changes to other patients who have the same issue.

Whitney: I think what I love about that story is not the personal overcoming of difficulties, but how she used essentially a very small PHR, she created her own little PHR, to manage this. She was able to use data to solve her own health issues, but also to suggest things that could be used for other people.

Dean: What this really demonstrates, what I think is really interesting about it, is it demonstrates some of the work we’re doing at Children’s Hospital in research on shared decision making, using patient portals and different systems to support decision making and collaboration between patients and providers.

One of our research assistants’ focus, his name is Dr. Alex Fiks. What I’ve learned from Alex is that decision making is really founded on, first, defining and communicating a person’s preferences and goals.

Then you come up with a plan to meet those goals, and then you develop some measure that can be used to track the progress of meeting that goal over time.

This woman’s story perfectly represents a shared decision making model, and everything’s there except for a PHR that can support the collection and communication of this information.

Whitney: We’ve been talking about this project for a long time, and we haven’t given you a chance to talk about who’s involved and how you brought together the team. I understand it’s three organizations, the Children’s Hospital of Philadelphia, the Inglis Foundation, and NCAM at WGBH.

Why don’t you just tell me a little bit about who’s involved and how the collaboration comes together.

Dean: The project is led by WGBH and the National Center for Accessible Media. They received the grant from the Department of Education National Institute on Disability, Rehabilitation, and Research, NIDRR.

Both Inglis and I and my boss, Dr. Grundmeier, are collaborators on the project with WGBH. The grant is referred to as a field-initiated project, so unlike a more traditional research project, its real goal is to demonstrate some process towards improving the life or every aspect of people with severe disabilities.

Whitney: It’s like what we would call a pilot.

Dean: Exactly. Now we couldn’t build an actual PHR, but the project was designed to demonstrate the application of both usability and accessibility methods, including subjects of people with disabilities, and essentially going through a whole series of usability methods towards the final product of interactive prototypes that we user-tested.

Whitney: At the end of this, NIDRR, which is a federal agency, will end up with not just a bunch of concepts, but some good, user-centered design supporting the results and hopefully take it further. Is that the goal?

Dean: Right, and all of our methods, results, and even the prototypes are freely available to EMR, EHR vendors, developers, anyone in the community.

Whitney: That’s really great. I know that you have a website. I think it’s HealthITAccess.wgbh.org.

Dean: WGBH is managing that, yes.

Whitney: We will, of course, as always, have links and all the other names and links that we’ve been mentioning on the website. I know that a couple of your collaborators asked if they could be on this podcast, but we think it’s an easier conversation when we can’t see each other to do it one-on-one.

I’d like to just give them a nod and hope that you have represented them well.

[laughter]

Dean: I hope so.

Whitney: What else have you learned? Has there been anything that’s surprising? Actually, my favorite ideas are ideas that seem obvious once you’ve seen them happen in the research. Anything that’s come out that really jumped out for you?

Dean: Yes. Beyond all the data and the results and the analysis, there’s something that I actually learned a long time ago but continued to relearn, and I think it’s very important. You referred to this many times.

In technology, UX, many people are striving to create accessible technology, and then other people are striving to create innovative technology. Unfortunately, there are still people, though not in the UX community, who feel that accessibility can be a barrier or somehow inhibit innovation.

I believe the exact opposite is the case. People with disabilities can be the source of many innovative ideas. Going back to the mid-90s when I started working with people with disabilities and assistive technology, I remember a few things.

First, I was forced to learn about and apply very rigorous usability methods. There was really no way around that, so it’s a great environment for that. At the same time, I was extremely selfish and thinking, repeatedly, “Boy, this stuff is so computer, I wish I had this on my computer.”

For example, touch screens, on-screen keyboards with word prediction, zoomable displays, speech recognition, text-to-speech. Think about it. It took about 10 to 15 years, and now we all have it on our computers, our phones and other devices, and we absolutely love it.

Whitney: That’s a really, really great example. Sometimes, it takes awhile to figure out. We start with a new technology.

For a while, there’s the technology looking for a problem. Often, extreme cases are the problem they solve. Then, it slowly migrates into general technology.

Dean: I had the same thoughts in this project. By taking all these different participants and their experiences and their stories and their ideas, and creating these PHR prototypes, I found myself thinking repeatedly, “Boy, this is a pretty cool PHR. I wish I had one, not only for myself, but my family, friends, and, of course, all the physicians and patients we work with.”

Whitney: I want to touch on one thing that relates to methods. If people are interested in what you did, there are great write-ups of all of your surveys and your prototyping and your usability testing.

I don’t want to take time to go through them here because they’re much more comprehensive on the Web than we could cover. But one of the things that a lot of people find as a challenge is finding people with disabilities who they can work with, and setting up usability tests to be able to include people in their research.

Can you talk a little bit about how that worked for you?

Dean: We had a distinct advantage in that our project partner, Inglis Foundation, manages the care of hundreds of people with disabilities. Not only were they a collaborative in the project, they were a source of many of our participants.

However, they specialize mainly in people with severe physical disabilities. We also found another organization, here in Philadelphia, Liberty Resources, who helps people with all types of disabilities live independently. They provided us with other participants, too. They were a great help.

There are certainly a lot of people out there with disabilities and all they seem very appreciative and enjoy being part of the project. Another resource might be your local university.

Most have some type of assistive technology and lab and/or faculty and students who are interested in accessibility. That might be a good resource, too.

Whitney: It sounds like one of the pieces of advice I heard was to not wait until you are ready to do your first usability test to get to know people. Don’t put out a call and announce that you’re ready for the doors to open, but actually do a little bit of outreach in advance.

Start making those connections early. Find out who’s in your community, what organization are there, what schools are there, so that you’re building those relationships before you ask people for their help.

Dean: Absolutely.

Whitney: I want to end with one other thing, which I was reading the website, and it said one of the things you did was an audit of three personal health record websites. Of those three, one only met half of the basic accessibility guidelines.

That sounds really terrible, but the other two only met two of the 12 guidelines, but then it goes on to talk about an inverse relationship between accessible and functional. Can you tell me about that?

Dean: Yes, it was really an interesting experiment. We reviewed these three different systems for both usability, accessibility, and also functionality.

I really felt like I was in the “Goldilocks” scenario. Though, of course, it wasn’t one that was ‘just right.’

For example, the first system, they seemed to have made an honest effort at meeting accessibility guidelines. Yet, the system functionality was really very limited, and usability was also a problem. There was very complex navigation, very confusing.

The other system that did the worst in terms of accessibility actually had the most functionality, and a lot of very sophisticated functionality matching some of the ideas from our participants.

The third system was somewhere in between. It was a PHR type system. It was pretty good in accessibility except for one particular issue. It relied on patient entered data, and with every piece of patient entered data, you had to enter a date. Well, the date widget was neither accessible for screen readers or keyboard only. I thought it was interesting representing this one little problem that could be such a huge barrier.

But, overall, I think what we learned from that exercise is that if you were to put these three systems together, you’d have a pretty great PHR. I think what’s fundamental here and interesting is that the technology isn’t the problem. There are no constraints.

There’s no issue with making an accessible PHR. It can be done. The real issue here with these systems really comes down to good requirements gathering, and then the application of a solid set of both usability and accessibility methods.

Whitney: Was the focus of your work really about understanding what a PHR needed to do because you already knew how to make things accessible and usable?

Dean: Yeah, we actually talked about that quite a bit. WGBH, people like yourself, many are promoting all types of accessibility methods. There’s plenty of that out there.

We didn’t feel like we could add too much to the excellent works that already available. Instead, we wanted to go in a different tack, and think about, or demonstrate in effect, “What if we designed a PHR specifically for people with disabilities? What would that be like? Would it be usable? Would it be accessible? Would it be functional?”

I think we answered that. I hope we answered that. That no only would be accessible and usable, but also highly functional and more innovative than existing systems.

Precisely because it’s based on people who face a lot of challenges, both with their health, but also access, mobility, finance, everything, and as a result, have many more interesting and detailed ideas of how we can better engage with the healthcare system.

Whitney: I think that’s an awesome place to wrap up at actually. Dean, this has been fascinating.

I think we could talk for hours, but I’ll say again that there’s lots more information and some great research stories up on the Health IT Access site.

Tell me a little bit about some of the people who really helped make this project sing.

Dean: At WGBH, we had a number of people. Larry Goldberg who was the PI of the project, who’s the Director of NCAM. Madeleine Rothberg who’s Project Manager. Geoff Freed who’s their Accessibility Expert.

At Inglis Foundation, their CEO Gavin Kerr, who is fantastic. Lea Frontino who’s their VP of Health IT and Innovation. Don Waller, who’s the Head of their Assistive Technology Lab and did a lot of work in not only connecting us with participants, but building test stations that we could use for the participants we tested at Inglis.

At CHOP, myself and my boss, Dr. Grundmeier who was one of our most amazing researchers, physicians, developers, analysts, statisticians.

Whitney: That’s a really big team. That’s kind of cool. I’m used to hearing more about projects that are a couple of people, in a skunkworks project, but this sounds much more well rounded.

Dean: Yes. And…I forgot one person. I’m sorry, Jason Withrow who’s a developer. He’s a contractor, and he also has a degree in HCI and experience with accessibility.

Whitney: We’ll give a shout out on the website, and I’ll get some papers from you that might be interesting for people who want to dig a little more deeply in the research. To wrap up, if you’re interested in learning more, the project website is, again, healthitaccess.wgbh.org.

To find the podcast page on rosenfieldmedia.com, look for the page for “A Web for Everyone.” That’s our book and follow that link to A Podcast for Everyone.

Thanks so much to you for listening in, and a special thanks for our sponsors, UIE, Rosenfield Media, The Pacielo Group, and O’Reilly for making this series happen. Be sure to follow us at @awebforeveryone on Twitter for information about future podcasts.

About the Project Collaborators

CBMi and The Children’s Hospital of Philadelphia. The Children’s Hospital of Philadelphia was founded in 1855 as the nation’s first pediatric hospital. The Center for Biomedical Informatics (CBMi) at The Children’s Hospital of Philadelphia is the home for the development of innovative solutions to healthcare’s immediate and long-term informatics needs. CBMi provides informatics-focused services, applications, and educational programs to Children’s Hospital clinicians and researchers.

The Inglis Foundation is a community-based foundation that is committed to using technology and healthcare information to empower people with severe physical disabilities to live life to the fullest. Inglis maintains a skilled-nursing care facility and independent-living facilities as well as care management, adult day and employment services for people with disabilities living in their own homes.

NCAM and WGBH (Project Leader). WGBH Boston is America’s public broadcasting powerhouse—PBS’ largest producer of TV and Web content. The Carl and Ruth Shapiro Family National Center for Accessible Media at WGBH is a research and development organization that works to make existing and emerging technologies accessible to all audiences. NCAM is part of the Media Access Group at WGBH, which has been providing captioning and video description services for people with disabilities since 1972.

Web accessibility takes place on a foundation of technologies, the most common of which are developed and maintained by the Worldwide Web Consortium, or W3C. Its success is dependent on how well these underlying technologies support accessible user experiences. Fortunately for us, people like Steve Faulkner devote much of their time to ensure technology specifications, such as HTML5, include the hooks that make it possible to build an accessible and enjoyable user experience for everyone, including people who use assistive technologies, such as screen reader and screen magnification software, and different display and interaction modalities, such as user stylesheets and keyboard navigation.

The web was created with accessibility as part its framework. Steve’s focus is to ensure accessibility remains a fundamental component of the web’s foundational technologies. Steve is co-editor of the HTML5 specification. He has been closely involved in other W3C specifications development, including the Accessible Rich Internet Applications (WAI-ARIA) specification. In this podcast Steve joins Sarah Horton to tell us about:

• The current status of the HTML5 specification
• How WAI-ARIA and HTML5 work together to support accessibility
• How accessibility is integrated into specification development
• What it’s like to work on a W3C specification

Transcript available · Download file (mp3, duration: 44:19, 25MB)

Steve Faulkner has been working in accessibility since 2001, first with Vision Australia and currently with The Paciello Group (TPG), where he is Principal Accessibility Engineer. He is involved with several W3C working groups, including the HTML Working Group and the Protocols and Formats Working Group, and is author of the helpful resource, Techniques for providing useful text alternatives. He is also creator and lead developer of the Web Accessibility Toolbar, a resource for evaluating web accessibility.

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes · Follow @awebforeveryone · Podcast RSS feed (xml)

Transcript

Sarah Horton: Hi, I am Sarah Horton, and I am co-author with Whitney Quesenbery of A Web for Everyone, with Rosenfeld Media. I am here today with Steve Faulkner. Steve is my friend and colleague.

He is technical director with The Paciello Group. Before joining TPG, he worked as an accessibility consultant with Vision Australia. Steve has been a mentor for me since I started working in accessibility. Much of what I know about accessibility, I learned from Steve.

In addition to his day job, Steve is an active participant in key W3C initiatives promoting web accessibility. His tireless work has led to key accessibility resources, including the very helpful, Techniques for Providing Useful Text lternatives document.

As co-editor of the HTML5 specification, much of his current work is focused on ensuring the specification moves forward in a way that supports and extends all the great work that’s been done to bring accessibility to the web.

We’re here to learn from Steve about the status of the specification and whether there are changes that we should anticipate as this spec is approved and implemented.

We also want to get a sense for what it’s like to work on this spec and how accessibility concerns are addressed in that process. Steve, thanks for joining us.

Steve Faulkner: Thank you.

Sarah: Let’s start by talking about how you got involved in accessibility in the first place.

Steve: In the late ’90s, I became involved in doing some HTML development. It was at a time where if you could spell HTML then you could get a job as a HTML coder, and I did some work over here in the UK—I was in the UK at the time, and I did some workup over here.

When I decided to go back to Australia, which is my home country, I looked for a job, and there was a job at Vision Australia. At that point, I didn’t have any idea about accessibility. I had very little knowledge.

But I had an interest in working with people with disabilities, and aging people, which I had done previous to starting to do the HTML development. I did a degree in psychology. I gravitate towards social work type, career path, I suppose you could say.

It interested me to be able to combine both the technical aspects, both the HTML development work and working with people with disabilities, and hopefully making a positive difference.

When I started the job, as I said, I didn’t know anything about accessibility. This was around 2000, and it was at a time where the accessibility field was still in its infancy, I suppose you could say. It probably wasn’t an infant—it was probably more of a toddler.

My first day on the job my then boss, Andrew Arch, threw a copy of the WCAG 1.0 Guidelines at me and said, “Learn this.” So that’s where I started, auditing and reviewing websites for accessibility against the WCAG 1.0 Guidelines.

Sarah: Did you read the guidelines from beginning to end?

Steve: Yes, I did. In those days, there weren’t a lot of the resources that are available now, 13 or 14 years later. It was very much explore and find out. There wasn’t the community that we have today through Twitter, Facebook, and all those things.

There were mailing lists and there was WCAG, the Web Accessibility Initiative, but those were not exactly as user-friendly as the informal networks that have grown up over time.

Sarah: When you think about the changes from WCAG 1.0 and now, and the issues that you were encountering when you were auditing things back then, are you seeing different types of issues? Are things getting better, are they worse, or both?

Steve: Obviously, we’re seeing different types of issues in that the interactions and processes that we regularly encounter of websites and web applications are much more complex than they were at that point.

We weren’t dealing with a static web at that point, but we were dealing with web that was a lot more server-side functionality, so a lot of the processing went on the server side. You’d fill in a form, you’d input it, and then you’d get some results sent back, for example.

These days, everything happens in the browser, or a lot of things happen in the browser. The user-interface elements that you’re dealing with, you could describe them as a house of cards built in HTML.

They often don’t have the required accessibility information, such as the roles, states, and properties. They don’t work correctly with the keyboard, or work as expected they do.

Things look like a button, but you can’t use it with a keyboard, for example. Whereas, in the olden days, when people stuck more to using the basic, native HTML controls, it was a bit easier in that sense.

The complexity of the content, in general, was less problematic. Because it was less complex, there were less things to go wrong.

Back to your question, “Are things getting better or worse,” as complexity increases, then obviously new issues arise. At the same time, there’s a lot more awareness, these days, about accessibility. There’s a lot of information out there to be able to draw upon, to be able to fix issues.

Hopefully, developers, in general, are more aware of taking into account building usable and accessible interfaces from the get-go, rather than having to come back and add this stuff in all the time, even though we still do encounter that a lot.

Sarah: Then things are getting worse, in the sense the interfaces are getting more complex and more difficult to support and code accessibly, but you’re seeing, at the same time, a lot more awareness on the developer-end of things, and more resources to support accessible coding practices?

Steve: Yeah, I would generally agree with what you’ve just said. Except that I don’t think they’re becoming more difficult to make accessible because of the tools that we have available now, such as the Accessible Rich Internet Applications specification and that features that describes, that are implemented in browsers, make it a lot easier and possible to make more complex user interface elements that are non-standard user-interface elements, accessible.

Previously, they couldn’t be. In that sense, things have got a lot better. But, as I say, the complexity does breed new issues. There’ll be challenges, and we face them and find out a way to fix them.

Sarah: You do a good deal of work with W3C working groups and task forces. What about that work interests you?

Steve: The main thing that interests me is that I have the opportunity to influence and contribute to defining the standards that define the web and how it communicates. For probably about seven years now, I’ve been involved in HTML Working Group at the W3C, and HTML is the language of the web.

Every web page is written in HTML. A lot of the information that’s communicated to users with disabilities who have to use assisted technology is communicated through the HTML content and structures that are defined within the HTML specifications.

To be able to contribute to the further development of the HTML language is both an honor and a very exciting privilege.

Sarah: What about the work you’re doing right now with the HTML spec? I see a lot going on about that.

Steve: It’s got to do with process within the W3C. The specifications proceed along a particular track. They’re initially published as working drafts, and then they’re reviewed and further work is done on those.

They get input from implementers. Anybody is free to provide feedback, and that feedback is taken into account. The editors make changes to the documents.

At the same time, new features are being added as either things that implementers are thinking, “We want to have this feature,” or developers have developed some custom feature that is popular, and then it becomes standardized. There are all things constantly being drawn into the specification.

At the same time, they’re trying to stabilize the specification at a particular point to get it through the W3C standardization process. It goes through an iterative process of feedback, editing, and then moving to the next stage.

The stage we’re at in the current process for HTML5, you could call it, is that we have reached what is last call. That means that what’s in the HTML5 specification is fairly stable, all the requirements are there and the features are there.

There’s not going to be any new features added to HTML5. There’s a last call, which means that people get to provide some feedback.

Once that feedback’s been dealt with, it moves to proposed recommendation, and then, ultimately, to become a recommendation, where the content of that is set in stone, so we’ll have the HTML5 recommendation.

At the same time, we are working on the HTML 5.1 recommendation, which is essentially a super set of what’s in the HTML5 specification plus new features. And so, things are being added in parallel, there’s a number of different versions of the document.

That’s the most stable version, which eventually will be locked down. And then, there’s the continuing 5.1 spec, and that will go through the same process. In 2016, its set to again go through this process of becoming a proposed recommendation.

People in the meantime, will start working on a 5.2 so there will be further extensions. It’s a living language, things are constantly being added. What’s written in this specification is, essentially a set of rules for how browsers are supposed to implement.

And browsers being Chrome, Firefox, et cetera, are supposed to implement the features defined in the specifications. If you’re familiar with HTML, all of the HTML elements, and attributes are all defined, and what they do is defined within the specification, how they’re supposed to be implemented, is defined in the specification.

As well as that, there is lot of what we call “implementor requirements”—these are requirements on authors, how to use particular features of HTML. That’s where I have a lot of interest, is defining the author requirements, because how authors use HTML affects the accessibility of HTML.

If authors misuse the features—write the code incorrectly, don’t use the headings in the appropriate way, don’t mark up tables, use data tables correctly, without using the correct features—then that has a negative affect upon users, especially users with disabilities. I spend a lot of the time working on the text of the specification in those areas, in particular.

Sarah: I see. You’re focusing on authoring aspects of the specs, primarily?

Steve: Yeah. That’s primarily what I do. But I also, obviously, review and feedback with implementers about aspects of the implementations, but mainly, in regards to the accessibility of the implementation.

If a particular feature is a new control but it doesn’t describe how it’s going to be used by someone with a keyboard, for example, or it doesn’t seem to have those hooks in there to be able to make it keyboard accessible or provide an accessible name and label, appropriately for it, then the process is, we file bugs against the specifications, but, also, when things get implemented, we file bugs upon the software itself.

I spend quite a bit of time, filing bugs against Chrome, Firefox, Internet Explorer, and Safari, to say, “Well, this is supposed to be implemented this way, but you’ve implemented it in some other way, and it’s made it less accessible. So, let’s try to get it implemented as it’s defined in the specification.”

Or, if the way it’s defined in the specification is wrong for particular reasons, then, provide some information about the reasons and we can see if we can change the specification to fit the reality.

Sarah: You’re looking out for accessibility as the specification is built out, and how it’s supported within the browser.

Steve: That’s right. Over the last weekend, or week, I’ve done a lot of testing. There’s a process of going through this recommendation process, one of the criteria for the specification to become a recommendation is, what is defined as a requirement upon browsers for particular implementation requirements is tested.

You need to write tests, and you test that the assertions in the specification are implemented as they are asserted in the specification.

There’s a fairly big section of the specification that defines how the roles, states, and properties for HTML elements are supposed to be exposed by the browsers within the accessibility APIs in the software.

A browser must, in simple terms, if you have a button element, then that button element must be exposed with a role of button within the appropriate accessibility API. This is by the browse. So you need to go in and check that that assertion is being supported within the browsers.

You create the files, you check, you use some software that looks at what the accessibility information is, and in the case of the button element, is it exposing a role of button? And happily, it is. But you can imagine that, for the accessibility aspects, there’s a lot of testing.

That is a similar model that’s used for the whole specification, and remembering how HTML specification is 600, 800 pages long, with lots and lots of assertions in there, there’s hundreds of thousands of tests that need to be written and tested.

There’s a big effort within the W3C and within the development community to create these tests and do the testing, to show what the HTML specification defines is in-line with what is implemented in browsers.

Sarah: I seem to remember reading somewhere along the way that, in order for a specification to be finalized, it needs to be fully implemented in two browsers—is that correct?

Steve: Yeah. What are known as the exit criteria, where the thing can pass—they are not always the same across specifications—but pretty much the rule of thumb is that, if the browser has an assertion in there, that says that X must do Y, then that assertion needs to be implemented in two browsers, at least two.

Obviously, the more the better, but the whole idea is to get the features of HTML implemented inter-operably—implemented in the same way in multiple pieces of software.

Sarah: Sounds like a pretty rigorous process.

Steve: It can be. A lot of time consumed, a lot of people spending time in this thankless task, that’s for sure.

Sarah: We’re all very thankful that you are doing it. Just so you know.

Steve: Thank you. As always, what’s wonderful about doing this work is you’re working with a large community of people. A lot of people are giving their time and knowledge to improve the web.

Sarah: Pretty impressive. Another specification that you have worked on quite a deal is the WAI-ARIA spec. Could you tell us a bit about that specification, and what that’s for, and the role of that moving forward, as this new HTML spec comes into play?

Steve: Sure. I will prefix that by saying that, I have been involved with the development of the WAI-ARIA specification. But my main work has been in integrating the HTML specification and the appropriate bits of the ARIA specification. The majority of the work for that specification was done with some wonderful other folk within the accessibility community.

As I was explaining before, the button element has a button role, and that role is conveyed, or is hooked up in the software, by the browser.

Previous to ARIA coming along, there was no way for an author to set that button role within the browser. What ARIA has done is allowed authors to set that information, to expose that information, to say, “This is a role=button,” and then browser sends that information to the accessibility API, so it’s exposed correctly within the accessibility API.

For most HTML elements, you don’t need to do this because the browsers do it automatically, but as we mentioned previously, what we have is a lot of development of custom widgets—things that aren’t represented as native HTML controls—being developed, using quite often, non-interactive HTML elements that have no meaning within themselves, like divs and spans, or building on top of native controls that do have meaning, such as elements, such as anchor or link elements and buttons and things like that, but actually adding to their functionality and changing the meaning of what they are.

Before ARIA, you couldn’t do anything about that, or it was very difficult to convey the changing meaning that the author has imposed upon it through scripting and coding.

With ARIA, if you change a link into a button—I’m not saying that you should do that, but people often do it—that you can, through the use of ARIA roles, space and properties, you can provide that information to let the user know that, hey, this is not a link, it’s a button, and you can interact with it as a button. It does button-like things, not link-like things.

Sarah: When you look at that specification, are there things happening within the new HTML spec that would change how ARIA is used?

Steve: To a certain extent. There are some of the newer HTML features, such as the dialog element, which didn’t make it into 5.0 because it hasn’t been implemented. It was implemented in one browser, but it’s not inter-operably implemented, and it was very unlikely that it was going to be implemented within the timescale of the 5.0 specification becoming a recommendation, but it is still present and living on in the 5.1 specification.

The dialog element, as the name implies, provides a native dialog control. Instead of having to script divs and spans to make it look like a dialog, you can use the dialog element and it has more of the features of a dialog.

Some of the interaction that you need to script in for custom dialogs is already built in. For example, when you open the dialog and you have a modal dialog using the dialog element, the keyboard interaction is that the keyboard interaction will stay inside the modal dialog until the dialog is closed, whereas with custom elements, custom dialogs, you have to use scripting to listen for the events and control the keyboard behavior via scripting.

The good thing is that with the dialog, you no longer have to do that once it’s implemented. Another thing is that, like most user interface elements, it has a role. With custom elements, as I said with the advent of ARIA, you could add a role as well as all the other things you need to do.

You could represent it as what it is, but with a built-in native dialog element, you don’t have to do that. There’s other things like the visual effects that you get. You get this dimming of the screen behind. You get those automatically.

It makes it a lot simpler for developers to create the things that they’re already creating using divs, spans, CSS and JavaScript trickery. It’s done natively in the browser, by simply having the dialog element and controlling the display of that element.

Sarah: That sounds great. Less trickery.

Steve: Less quackery even.

Sarah: [laughs] Do you see a time where ARIA would be obsolete in the sense that there would be native elements that make those additional attributes, that way ARIA brings to the process, unnecessary?

Steve: No.

Sarah: Why not?

Steve: The reason being is that there is a lot of controls that come in and fall out of favor, but they’re never standardized. Not every type of UI control will be standardized and implemented. There’ll always be room for the use of ARIA or reasons you need to use ARIA.

Also, note that one of the things I always like to say is that people see ARIA as a bridging technology—that at some point, everything will be wonderful and we will have native support for all of these interactions and roles, states and properties.

But when we look at, for example, the humble button, as I was mentioning earlier, the button element has been around since ’94, so we’re talking about 20 years. Still today, people are building buttons out of any other element you can think of but a button.

I’m not saying that’s correct and they should be doing that, but they do it, and there’s no way to stop them doing it, because part of the integral features of HTML is that every element, whether it be a control or a paragraph element, can have interaction and events associated with it. If it can, then people will do it.

Another aspect is that the focus of ARIA is shifting to a certain extent, in the sense that instead of becoming this bridging technology, it’s starting to become the abstract layer, the way that accessibility semantics are described.

They’re starting to use ARIA as the generic way to describe the accessibility semantics for a number of platforms. What happens is that if you have an ARIA button role, that equates or maps to a number of accessibility APIs and is coded into various platforms and browsers.

In that sense, it’s being used more as a generic identifier these days. Even if its usefulness as a way to plug gaps in native functionality, that it’s got a different usefulness within itself.

To give you another example—or to give you an example, even—the way that the requirements for HTML elements, the accessibility mappings that they require, are couched in terms of ARIA requirements.

In the specifications, it doesn’t say, “A button element needs to have a button role in accessibility API X, Y, or Z on platform X.” It says, “It needs to have an ARIA button role.”

It’s describing in terms of ARIA, because ARIA provides that mapping information through a sister specification to the ARIA specification called the ARIA Implementation Guide.

That has the nuts and bolts of how an ARIA button role equates to a button in Safari on the Mac, for example, what role that equates to. I don’t know if I’m getting it across, but it’s like a dictionary of terms that are defined for a variety of platforms and software.

On the one hand, you have that usefulness of ARIA, but on the other hand, you also have ARIA-like other specifications still in development. The 1.0 version of ARIA has been shipped, but there is currently work on ARIA 1.1, which is in active development.

There’s work around, for example, extending ARIA properties to be able to describe annotation information. For example, currently there’s no way for me as an author to adequately define if I have crossed something out, using a line through or whatever in a word processing program.

There’s no way for me to convey that unambiguously to an assistive technology user through the accessibility API because there’s no semantics for that that are clearly available.

What they’re looking into in developing ARIA 1.1 is additional attributes that will allow you to describe all those sorts of things like footnotes, comments, et cetera, that typically we’re used to using within Word documents and things like that, or on the web.

You’ll be able to use ARIA to provide clear, unambiguous descriptions for those things. And also, as new roles and states are being developed, one of the new controls that has become ubiquitous, especially on mobile, is the toggle button. The “switch” is another word for it.

Previously, there hasn’t been a role for that type of control. There’s roles being added for that and for some other things, so there’s further refinements and additions as new things get invented.

The other aspect, talking about, things becoming native in HTML, one of the exciting and also potentially problematic from accessibility standpoint is the new developments within what is known as “web components.”

This is a whole suite of applications that essentially allow developers to create new HTML elements that they can use in their pages, and add new functionality. It’s like they’re supercharged custom controls, like supercharged jQuery, but they allow developers to do all these great new things.

A lot of the accessibility semantics, a lot of the information that will be required to be provided, will need ARIA to be able to do it. If anything, ARIA is becoming more important and more integral to the story for HTML going forward, rather than becoming less important.

Sarah: It seems that these things move forward in tandem, one supporting the other. How is ARIA support on mobile devices, for that switch, for example, that’s used a lot in iOS? The little on/off switch, is that what you were talking about?

Steve: Yeah. Obviously, if something like that which is still being specified, there is no support. In general, the differences, the problems associated with the support for accessibility in general in various devices is that there’s a different browser culture within mobile devices than there is in the desktop.

On the desktop, you have the four major browsers. Depending upon the device that you are using, saying if you’re using an iOS device, on the surface you might have Chrome and WebKit and even Firefox…I don’t know if you can get Firefox for iOS…but underneath it, the iOS platform, the rendering engine, the engine that powers the browser, is the WebKit engine, which is the Safari browser engine.

It’s much more dependent on one vendor or one browser engine implementing something. But on the desktop, Chrome isn’t that great, IE’s pretty shabby, but then Firefox is great, and WebKit on OS X is great, as far as accessibility support, so you’ve got some choice.

Where you have the more controlled environments of the mobile then things aren’t good. Having said that, WebKit and Apple on both iOS and OS X, they put a lot of work into it. It’s obviously not perfect, but they put a lot of work into it.

In a general sense, you would find that the accessibility support for ARIA implementation is a little bit behind on the mobile devices, for a variety of reasons.

Sarah: Recently I read, somewhere on the Twitters or something, that the alt attribute on the images isn’t required for validation with the new HTML specification. Did I get that right?

Steve: Not exactly, no. Within HTML5, the alt attribute is required. To have a conforming document, you need to have an alt attribute with an appropriate text alternative on every image element.

Except in the cases where you have an image element that is contained within a figure element that has a non-empty figcaption element. Essentially, it means that if you have a caption for an image, you don’t need an alt attribute, necessarily.

It’s quite a refined rule, and it’s quite narrow in its scope. What it’s designed to do is to reflect the reality of situations like where you have image upload sites.

You have photos sites, where you have people uploading thousands of images with no desire to add text alternatives to each of them, or oftentimes no time, or they’ll have no opportunity to do that. At least, if you have a caption, you have something that identifies that image.

If you have something that identifies the image and gives some information about the image. If you had an empty alt on there, which is what, in the past, people have put on there, what that essentially does is say, “This image is of no interest,” to the assistive technology user.

With the implementation of the HTML5 semantics for images with an empty alt, it will mean it will no longer be represented in the accessibility tree if it has an empty alt on it. It’s a way of saying, “This image may have some information of interest. It doesn’t have a text alternative, but it does have a caption.” It tells you something about the image, in that the image is there. Where, if you put an empty alt on there, then it would disappear.

Sarah: I think I got that. I understand the use case. You’re saying I have an image and I have a caption, and so that will be wrapped in this figure element.

Because it’s within the figure element, it knows that it has a caption, and so doesn’t feel as though the image needs to be described in any way. It’s essentially like automatically adding null alt text to the image?

Steve: Yeah. The spec doesn’t say the image doesn’t need to be described. The spec’s quite clear in that it says that if there’s any chance at all that the image can be provided with an appropriate text alternative, it must be provided. It’s the reality is that quite often it’s not.

What’s happened in the past is that, quite often when it’s not, the software or authors put an empty alt tag on there. In doing that, they’re essentially hiding the image and the user’s not going to know there’s an image there at all, even if they wanted to interrogate it.

Sarah: Okay.

Steve: They won’t know, so they can’t even say to their mate, “Hey, there’s an image here. You’ve got a pair of eyes. Can you tell me what it is?” because they won’t know the image is there.

Previously, a way to provide the caption for an image was via the title attribute. Number of problems with this is the title attribute itself doesn’t carry the semantics of a caption, and also that the title attribute has various problems the way it’s implemented in browsers.

On mobile, you don’t see it. You can’t access the title attribute, anyway. Or, if you’re using a keyboard, you were hiding information.

With the use of the figure and figcaption pattern, what you’re doing is providing a programmatically associated, because the figure wraps around the image and the caption. You’re saying these things are associated, and you’re providing a visible label for the image, so the user knows something about the image.

Sarah: Nice.

Steve: I like it.

Sarah: [laughs] It sounds like a really elegant way to present the design pattern in a consistent way. Hopefully, it will lead to more accurate and descriptive and helpful descriptions of images, since it displays on the page.

Steve: That’s the hope. One of the issues is getting people to provide a text alternative, full stop— Maslow’s hierarchy of needs. [laughs] Get them to provide some text, and then make that text an appropriate text alternative, make it useful and meaningful. Each step is a little bit harder to make.

The thing is, at least quite often what’s happened in the past is that a text alternative will be provided using the alt attribute, where as a text alternative it will be what is, semantically, a caption. Now, we have a caption element that you can provide a caption for something.

It has a different meaning and it has a prescribed meaning that’s conveyed. For example, in Firefox, the figcaption element is exposed with a role of caption. That can be conveyed to the user, so they get told that this is a caption. This text is a caption. It’s not a text alternative or a replacement for the image.

Sarah: Oh, OK. That’s what I was thinking, that captions might have a really different function than a text alternative.

Steve: They do, in most circumstances. But, if people aren’t going to provide the text alternative, but they are going to provide a caption, at least the user knows that this is a caption and it’s a caption for something that’s not adequately described.

Sarah: It sounds like you can really look at the specifications. This is an instance where you’re looking at the real world and thinking about how things are implemented, the process for putting images on pages, and stuff like that.

When you’re working on specifications, do you talk a lot about the implications of changes on processes? In this case, we spend a lot of time in accessibility talking to people about creating good text alternatives for images.

This adds a little twist to that. Is that part of the spec development process, thinking about the cultural impacts of these things?

Steve: I think it definitely is. That’s the thing. A lot of the things that make it into HTML specification, other specifications, is that they look at the way authors use HTML in the world, they look at design patterns that are used, and say, “Let’s formalize that design pattern.”

The provision of a caption for an image is.…It’s not ubiquitous, but there’s a lot in the print media, academic textbooks, anything that has captions.

Newspapers and online news media have captions for images. There are a lot of circumstances where you have a visible piece of text that is associated with a particular image.

Previously, there was no way to say, “Hey, this is a caption for this image.” Now there is. It’s really formalizing design patterns or code structures that developers have been using.

Sarah: As someone who builds things and evaluates things that other people build, I find it really reassuring that the web standards people are looking at what’s happening and adapting those standards to support it. That’s great.

Steve: Yeah, that’s one of the things I’ve been particularly interested in. There have been big changes over the last 10 years in the way that the HTML specification, particularly, has been developed, how things get added, and what get described.

A large part of that has been a renewal of browser implementation information, ensuring that that is correct, and working closely with the browser vendors, and things like that. The authoring guidance, within the specification has not kept pace in the same rigor, and the real-world perspective hasn’t been applied to that.

One of the things that I’ve tried to do since I’ve been involved is get the information of the guidance and the specification to reflect both the constraints and the best practices that are in the real world.

To give you an example, one of the new features in HTML5—it’s new, it’s been around for a while now—is the placeholder attribute, which essentially allows you to define a piece of text that is displayed within a text-edit field or a text area in a control.

The thing that’s usually light gray and difficult to read, and then disappears. It’s a feature that a lot of people were doing via scripting.

You could use JavaScript to change the value of the control so it’d have that. It’s also a feature that’s available in other platforms, desktop platforms, et cetera, so it’s been added…but.

One of the things that I wanted to insure is that the advice around the use of that is clear that it should not be abused. It shouldn’t be used as a label in place of a visible label. We can’t always stop people doing that.

At the same time as not wanting to have it used as a visible label, one of things that’s important, and have worked and tested, is that in the absence of any other label text that it is exposed as a label through the accessibility APIs to assist technology users.

At least, again, a realistic point: they get some information. At the same time, in the specification, which echoes information that is provided by people like usability gurus like Nielsen Group, that you shouldn’t use a place holder as a replacement for a label.

It states that clearly in the specifications as author guidance, and states the reasons why. It’s problems with the color, that it disappears so it has an affect on users with cognitive impairments. There’s a whole litany of reasons why it’s not a good idea.

Those are clearly stated within the specification. It’s the thing that wasn’t there, but I have been working to get into the specification.

Even though the HTML specification is meant to be primarily for browser implementers, it’s also looked to, used, and is a valuable resource for HTML authors and developers, et cetera.

Sarah: I know I speak from many, many people in thanking you for bringing that perspective into the development of the specifications, and all of the hard work you and everyone else who’s involved in developing these specifications put in. Thanks very much for talking to us today.

Steve: Thank you.

Sarah: It’s been very informative and and enlightening.

Steve: I hope I haven’t gabbled on too much. I tend to gabble, especially when I’m sitting alone in my hallway talking to people.

Sarah: [laughs] It’s good gabbling. Let me put it that way.

Steve: Excellent. Thanks very much, Sarah. I had an enjoyable time speaking with you today.

Sarah: This has been Steve Faulkner sharing insights on how specifications like HTML5 and WAI-ARIA are there to help us in building a Web for everyone.

Many thanks to you for listening, and to our sponsors, UIE, Rosenfeld Media, the Paciello Group, and O’Reilly for making this podcast possible. Follow us @awebforeveryone on Twitter, that’s @awebforeveryone. Until next time.

Audio accessibility is concerned with making information provided audibly available to people who are deaf and hard of hearing. We see examples of audio accessibility in captions and live captioning. Like all forms of accessibility, there is a spectrum that is defined by features that influence the quality of the experience. At one end of the spectrum, a text version of the spoken content is provided and is somewhat accurate. At the other end, the text closely matches the audio, with accuracy, sound description, and punctuation helping to provide an equivalent experience. To provide a quality user experience, we must make use of all the features that go into an accessible and enjoyable experience of audio content for people who are deaf or hard of hearing.

In this podcast we hear from Svetlana Kouznetsova. Sveta is a user experience designer and appreciates the value of providing a good experience. She brings this perspective to her work as an audio accessibility consultant. She joins Sarah Horton for this episode of A Podcast for Everyone to answer these questions:

• What is the current state of audio accessibility?
• What are different features that influence user experience with regard to audio accessibility?
• Does speech-to-text technology help in creating accessible audio experiences?
• What should we be thinking about with speech-based interfaces?
• How can we better promote audio accessibility?

Sveta is deaf, so we did the interview on Skype using video and chat. That way we could see each other’s expressions and reactions to the text-based conversation. It was Sveta’s idea to conduct the interview in this format and it worked very well. Also, at the end of the interview we had the transcript, included below (note the transcript is a little different since it came from a text conversation—for example, it has smileys). To make the interview accessible to podcast listeners, Elaine Matthias from Rosenfeld Media and Sarah connected on Skype to read and record the interview. It was a great process, and a wonderful way to share Sveta’s insights with both readers and listeners.

Transcript available · Download file (mp3, duration: 17:31, 10.8MB)

Svetlana Kouznetsova is a user experience designer, accessibility specialist, and captioning consultant at SVKNYC Web Consulting Services. She also provides audio accessibility services and resources through the Audio Accessibility website, including information about deafness and hearing loss and best practices for accessible media.

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes · Follow @awebforeveryone · Podcast RSS feed (xml)

Transcript

Sarah Horton: Hi, I’m Sarah Horton, and I’m co-author with Whitney Quesenbery of A Web for Everyone from Rosenfeld Media.

I’m here today with Svetlana Kouznetsova. Sveta is a user experience designer who knows the value of a successful and enjoyable user experiences, and focuses on usable and accessible design, above all else. She is also an audio accessibility consultant, helping companies produce accessible video and audio experiences. Sveta is very active in the user experience, design, and accessibility communities, advocating for audio accessibility and advancing access to media for people who are deaf or hard of hearing.

As an aside, Sveta is deaf, so we did the interview as a text conversation using Skype. We both prefer talking face-to-face, so we used the video feature, so we could see each other’s expressions, smiles, and laughter, without relying on emoticons. After the interview, I read the transcript of my part of the conversation and Elaine Matthias from Rosenfeld Media read Sveta’s part, and we recorded the reading to use as the audio podcast. Kind of a reverse process, where typically we record audio and transcribe to text for accessibility. It was Sveta’s idea to text and then voice the interview, and it worked really well. And it’s wonderful to be able to share her insights, with listeners and readers alike.

Sveta, many thanks for joining us.

Svetlana Kouznetsova: Nice “meeting” you.

Sarah: First of all, let me say how happy I am that we figured out how to make this work. I really wasn’t sure how a podcast, which is first an audible experience, would work, and it was great thinking it through with you and exploring other options, learning from you other ways to communicate. I’m grateful for the insights, and wonder if you would share them with our listeners, on ways you use technology to communicate?

Sveta: Okay. Email is my primary way to communicate if people want to reach me. I also use texting when needed—mostly to send brief messages.

When communicating with people online in real time, I usually use instant messaging features like Skype, Gtalk, AIM, etc.

I also use video when Skyping with people so that we could see each other and each others’ facial expressions and body language—it’s similar to when people listen to each other voices over phone and hear voice intonations.

Sarah: Nice, makes sense, and works well! It’s great to see you and talk to you.

Sveta: Likewise. 🙂

Sarah: So, how did you get started working in user experience?

Sveta: I was originally trained as a graphic designer, but I also liked doing websites, and I did a lot of web design work at my first job. I got interested in coding and got a degree in Internet Technology. While in graduate school, I took some business classes—marketing and management.

I liked marketing classes a lot and had fun doing customer research, but I did not like the idea of asking them to buy things—I wanted products to be more usable to them. Later I found out that it’s part of user experience that is similar to marketing, but the difference is that it focuses on improving experience for users.

Also, when working on websites, I did sketches and wireframes and loved it. I had no idea that it is also part of user experience and information architecture.

At another job I was collaborating with a developer who encouraged me to make coding cleaner, and from there I somehow found out about web accessibility and user experience.

I learned more about it from reading online information and attending events and conferences.

Sarah: When you talk about user experience and marketing, is that like “experience marketing”—where in providing an excellent and enjoyable experience you end up getting people to buy things?

Sveta: Yes, I believe that user experience and marketing can go hand in hand and are interdependent.

I think that marketing is about attracting customers and user experience is about keeping them.

Sarah: Yes, I like that part, too. It’s not always easy to convince companies that UX will help with the bottom line, though. Have you found that to be the case?

Sveta: It’s hard. And many businesses think that UX = visual design and coding.

Sarah: It’s a tough nut to crack, for sure. Let’s talk about audio accessibility; what’s your sense of where we are? Are people thinking about this? Are you finding that companies are receptive to working toward audio accessibility?

Sveta: It’s something that I still keep needing to educate more people. Even when talking about accessibility in general, many think it’s about coding and doing alternative description for images, and focus more on people with visual and mobility difficulties. But less often on hearing and cognitive difficulties.

Many think that it’s enough to just have hearing aids or turn up volume to listen to audio, which is not necessarily true. Sadly, hearing loss is very stigmatized by society, so it’s not discussed that much. For example, more people take eye exams— but how many people would take a hearing test?

More people are willing to wear eyeglasses, but many would try to conceal hearing aids or not to wear them at all. Those who are deaf and hard of hearing would not ask for access—only those who are involved in advocacy work. So it gives the impression to people not familiar with deafness that if a few or no people ask for access to aural information, there’s no demand for it.

When I ask people to caption video or provide transcripts to audio or to provide real time captioning at events, I’m often being told that I’m the only person asking for it. They do not realize that I speak for about 50 millions of deaf and hard of hearing people in USA. Also, captioning benefits many more people than those who are deaf —like people who are foreign language learners, remedial readers, having a hard time understanding foreign accents, or happen to be in noisy or quiet situations, for example.

Sarah: It’s true that discussions about accessibility often come down to numbers—how many people will really benefit from this? Unfortunately, since as you point out, so many people benefit from it. With captions, it seems like the benefits are more widely understood and felt than with some other accessibility features, like alt text.

What I encounter a lot is a resource argument against captions, because it’s something extra.

Some aspects of accessibility require people—designers, developers—to do things differently. Like using a different design or interaction pattern—like a disclosure widget instead of a tooltip to display supplementary information. Or in code, adding attributes to code so information is available to assistive technology. But captions are different—they require people to do something more. And usually they cost money. In my experience it can be a hard sell, making a case for spending additional time and resources on captions. How to you approach that challenge in your work? What arguments can we use to make a compelling case?

Sveta: It would be no different from spending money on making buildings accessible for wheelchair users, for example. You need to add ramps and elevators. They are as universal as captioning in the sense that they benefit more people than those who are in wheelchairs—like parents with baby strollers or workers pushing carts.

It is also no different from spending on other things like editing audio and video—it also costs extra money.

It is also a better investment than spending more money on lawsuits.

Lawsuits would not only cause businesses lose money, but also give them a bad reputation. Providing accessibility is the right thing to do. Like ramps and captions, they benefit more people than just those with disabilities.

Many businesses do not realize that people with disabilities make the largest minority with significant spending power. They make $1 trillion market in USA and $4 trillion market in the world—the latter is about the same size of China.

And they would also get more customers like families, friends, coworkers—they would make additional 2 billion people in world with a disposable income of $8 trillion.

So it’s a pretty significant number of potential customers that many businesses ignore.

Sarah: Yes, there is a strong business case. Also, when it comes right down to getting videos transcribed, I’ve found the costs is not that significant. I think we all wring our hands about how expensive it is, but when it comes right down to it, it’s pretty small in comparison with other costs, as you mention, like shooting, editing especially.

Part of the difficulty is getting the process embedded smoothly into the overall process. Some people hope technology is the solution.

I remember getting very excited back in 2006 reading an article about IBM’s “superhuman speech recognition,” which set a goal and timeline for recognizing speech as well as humans. At the time I was working on lecture capture project where we were trying to automate transcription of recorded lectures. Since then we have Siri, which works pretty well, and YouTube auto captions, which don’t work so well. How realistic is it to look to speech to text technology for help with creating accessible audio-based experiences?

Sveta: That’s the issue. It’s important not to just provide speech to text translation, but also to make it of good quality. No matter how much speech recognition has advanced lately, machines are still not as good as humans. Even people who use speech recognition to provide real time captioning—called voice writers or re-speakers—are not as good as steno captioners. For example, BBC uses voice writers for real time captioning, and that makes many deaf Brits frustrated because they have so many errors.

And a couple weeks ago I was provided with voice writers by an event organizer who went against my advice for hiring steno captioners. Those voice writers have years of experience, and yet they made more errors than skilled steno captioners.

If human voice writers using speech recognition cannot provide smooth real time captioning, machines cannot do it even better.

Sarah: Can you explain what a voice writer is?

Sveta: There are 2 types of real time captioners. One is a steno captioner that uses a steno machine—like a court reporter. Another one is a captioner who uses speech recognition like Dragon to voice instead of typing.

I’m not a captioner so I cannot explain it in details. From what I have seen, they speak into a microphone and make words appear on screen. To reduce mistakes, they would need to practice a lot to add words into vocabulary. Steno captioners also practice by adding specific strokes into vocabulary.

Sarah: Ah, I think I get it.

Sveta: Another thing about automatic speech recognition is that machines are not able to add proper punctuation, speaker identification and sound description—it can be done only by humans. Proper punctuation is as important in transcription as voice intonation in human speech.

Another thing also is that speech recognition is not good at foreign accents and background noises.

Research shows that errors of more than 3% make it harder to read and understand material in print. That’s why real time captioners are expected to type at least 220 words per minute with at least 98 to 99% accuracy in real time.

For these reasons you need to train a machine to recognize your voice. You cannot just use speech recognition and then start captioning. From what I understand, it takes as much practice for a voice writer as a steno captioner to provide smoother real time captioning with less errors.

Voice writing may be better for transcribing recorded audio and video so that they can take time to clean up. For real time captioning, however, I would recommend steno captioners.

Sarah: Speaking of voice and dictation, what about speech-based interfaces, like Siri? What should we be thinking about to make sure those tool are accessible?

Sveta: I think that Siri may be good for voice commands or other functions than real time captioning. I did try myself—sometimes it may transcribe speech well, sometimes not. The main issue is the time lag to have speech transcribed.

Siri may be fun for informal conversation—some people tried to use that with me. However, it’s not good for real time captioning.

Sarah: Thinking about using speech to interact with features, do we need to be sure to have alternative interaction features, like with Siri you can speak a search term or enter it as text. And as long as the text option is available there won’t be barriers for people who can’t speak?

Sveta: Yes.

Sarah: Great. I see more interfaces, particularly apps, that use speech, and I’m not sure we are all thinking about having that redundancy.

Sveta: Even though I can speak, I have Russian accent and deaf voice, so speech recognition would not understand me. It’s hard enough for some humans to understand my speech, to say nothing about machines.

Sarah: 🙂

So the last thing is, if you have one bit of advice to offer someone on a product team who needs to advocate for audio accessibility, what would it be? What one argument or rationale could we use to persuade people to commit across the board to, for example, CART for events or transcribing podcasts?

One note on that—when Whitney and I started doing podcasts with UIE, we didn’t need to convince—they were already transcribing all their media, which was pretty awesome!

So how do we get others to do that?

Sveta: I really appreciate that you and Whitney try to make sure that aural information is accessible via quality transcription.

It may be surprising, but even some people who advocate for accessibility do not practice what they preach as they do not think of making their audio accessible.

And when posting podcasts or videos, they say “Transcript and captions to come soon.” This is not a good practice because many of us deaf and hard of hearing people are often being told, “I’ll tell you later,” when we ask people to repeat what they say or discuss in group conversations. That message is equivalent to saying, “I’ll tell you later.” So it is advised to post audio and video online only after they are made accessible.

The example is the recent CSUN conference about accessibility—they posted videos online without captions! They said to be patient and wait. Why should deaf people be patient and wait? Why the rush for hearing people to listen to audio and video? If we are told to wait, so can hearing people, too.

To answer the last question, I would say that captioning and transcription is universal access and not something that needs to be asked for in advance.

Hearing loss is very stigmatized and many deaf and hard of hearing people would not ask for it. There are also many people who are late deafened and trying to cope with their hearing loss. So captioning would benefit everyone.

Generally I would say that accessibility and user experience are not to be separate—things need to be usable and accessible to everyone regardless of whether you have a disability or not. What benefits people with disabilities also benefit others.

Last but not least, it’s important to provide quality transcription and captioning. It’s more than just converting speech to word. And it also depends on type of audio—transcription for a podcast would be different from transcription for video and live events.

Sarah: So, don’t wait for someone to ask for captions or transcripts—just do them, do them well, and everyone benefits.

Sveta: Yes. Just like you don’t wait for someone to ask for ramps and elevators—they benefit everyone.

Sarah: Right! This has been very helpful and informative. Thanks very much, Sveta!

Sveta: My pleasure! 🙂

Sarah: This has been Svetlana Kouznetsova sharing insights on what we can do to design accessible audio experiences, and work toward building a web for everyone.

Thanks, also, to Elaine Matthias at Rosenfeld Media for voicing Sveta’s part of the text interview for the audio version of the podcast.

And many thanks to you for listening, and to our sponsors—UIE, Rosenfeld Media, The Paciello Group, and O’Reilly—for making this podcast possible. Follow us @awebforeveryone on Twitter. That’s @awebforeveryone. Until next time!

Global Accessibility Awareness Day officially begins at 8pm EST on May 15, 2014. The first GAAD was in 2012, and was inspired by Joe Devon’s challenge to mainstream accessibility. He called for “a day of the year where web developers across the globe try to raise awareness and know-how on making sites accessible.”

While GAAD continues to be an awareness-raising event, this year it has taken on a celebratory tone. There has been real progress in the last years, as reflected by the number and diversity of GAAD events—in-person and virtual. People are talking about and engaging with accessibility around the globe. It’s definitely an exciting time to be involved with accessibility.

This year’s GAAD coincides with UXPA Boston, and Whitney will be presenting on Personas for Accessible UX. I will be presenting on Involving People with Disabilities in UX Research as part of Inclusive Design 24, a 24-hour online GAAD celebration hosted by The Paciello Group and Adobe. And Rosenfeld Media is celebrating GAAD by offering a 40% discount on A Web for Everyone. Just choose your format, click Add to Cart, and enter the discount code GAAD.

We hope you will join us in celebrating all the great work and progress, and take time to learn more about how you can help in making a web for everyone!

I always like it when worlds collide, showing that we can start from different goals, but end up with similar guidelines. One of those happy collisions is plain language and accessibility.  If you are looking for one thing you can focus on to improve your web site content, plain language is a good place to start. Making information clear helps everyone because:

• People read with different degrees of literacy. Clearly written information helps those who don’t read well.
• They do not always read carefully. Even skilled readers may be scanning a page quickly.
• They may have a cognitive, language, or learning disability. Understandable vocabulary is an important part of making information clear.
• Visual disabilities can affect reading, so presenting text well helps, too.
• They may not know (or read) the language well. In a global web, readers may be from anywhere in the world.

I’ll be teaching a class on writing in plain language at AccessU, in Austin on May 12-13, 2014. But if you can’t join us at this great conference, my slides are available online on Slideshare.net (where you can download an accessible Powerpoint file).

For the accessibility side of this collision, plain language is part of the WCAG 2.0 accessibility guidelines, especially “3.1 Readable: Make text content readable and understandable.” But  well-written content is also helpful for meeting other guidelines, by making sure that:

• Headings and field labels organize the content in a descriptive way that supports readers. (WCAG 2.4.6 and 2.4.10)
• Users can understand what will happen when they click on a link because the link is written clearly and presented in a clear context. (WCAG 2.4.4 and 2.4.9)
• Instructions and help are available, especially for interactive features and forms. (WCAG 3.3.2 and 3.3.5)
• Unusual words that the audience may not know and abbreviations are explained. (WCAG 3.1.3, 3.1.4, 3.1.6)

The plain language advocates also point out the understanding information can be a civil right. This is especially true when the information comes from your government, or affects your rights and benefits as a citizen. But it can be just as important in reading contracts, terms of service, or instructions for using a product. At TEDxO’Porto a few years ago, Sandra Fisher-Martins, of Português Claro, gave one of the best presentations ever on this perspective.

• The Right To Understand
  (YouTube Video from TEDxO’Porto, 2011)

It’s in Portuguese, with English subtitles so I’ve posted the transcript here.

Transcript: The Right To Understand, Sandra Fisher-Martins

Good evening

The story I’d like to tell you started in 1996, when I was studying in England.

One day, I was looking through my bank statement, even though there wasn’t much to look at and, in the top corner, I noticed a symbol which said that this document had been written in plain language, so I could understand it.

I thought this idea interesting, so did a bit of research and found out there was a campaign for language simplification. I thought it a fabulous idea, and then forgot about it.

When I returned to Portugal, I was confronted with several documents, for example, my work contract, the mortgage agreement, the power bill documents which reminded me of that symbol [ the Crystal Mark ] not because they were clear and simple, but because they were the exact opposite. Because, only after a second or third reading, I could begin to understand them.

So the little seed that had been sown in ’96 started to grow. And, one day, I found myself walking into the boss’ office and quitting my job so I could dedicate myself to this.

Right from the start, I realized the problem was a lot more serious than I thought. Not only were these documents complex and annoying, but literacy, which is the ability to understand written documents, was very low in Portugal.

Here’s a graphic about literacy in Portugal. There’s still about 10% of Portuguese who can’t read or write at all. This graphic shows us the ones who can – or claim they can – read and write.

So, there we have the red group which represents those who are on the lowest literacy level, Level 1. They’re those who can join up letters to make words, but can’t actually understand what they read. For example, if they need to read a medicine leaflet to figure out the correct dose to give their child, they can’t. They can’t understand the information. That’s 50% of the Portuguese.

Then we have another 30%, the guys in yellow. These are the ones who can get by, as long as they don’t have to read anything new or different. So, for example, if they work in a factory and a new machine arrives and they have to read the manual to operate it, they can’t.

And that’s already 80% of the Portuguese.

Then there’s a few who can handle documents as long as they’re not too complex. And there’s 5% of the population who can understand truly complex documents.

And just so you don’t think this is the norm, that other graphic shows literacy in Sweden. While we have 20% of people with a literacy level considered essential for daily living, Sweden has 75%.

And looking at this graphic, I realized we live in an information apartheid. I realized there’s a small minority who can access information and use it for their benefit and a huge majority who can’t. And because they can’t, they’re excluded and at a disadvantage.

I’ll give you an example. That’s Mr. Domingos. He’s our building’s janitor. He started reading when he was 27. He’s in the yellow group we saw earlier. Once in a while, he comes to me and says “Miss Sandra, I got this little letter…” Whenever Mr. Domingos or someone in his family gets a letter they don’t understand he brings it to me and I help translate it. So, that time he said, “I was about to throw this in the bin, but could you just check if it’s something important?” It was. Mr. Domingos had been waiting for some time to have knee surgery and it was he letter that contained a “Surgery Voucher.” When someone has been waiting a long time for surgery, they’re sent this voucher that can be used at a private clinic. And Mr. Domingo’s letter almost went in the bin.

Later, I found out that, in that same year, only 20% of those vouchers had been used. I find it hard to believe the other 80% just got better while they waited. They probably did what Mr. Domingos was about to do: “What’s this? Don’t get it. It’s rubbish.” They missed the opportunity to have the surgery they needed.

When people don’t understand, it has serious consequences, not only for themselves, but also for the whole country. If I don’t know my rights or the benefits I’m entitled to, I probably don’t know my responsibilities either and I’m not an active and participating citizen.

And now, maybe you’re sitting there thinking “Poor Domingos, that’s tough.” “Me? I’m a green one. I’m pretty sure I’m a green. I was invited to come to TEDx.” But let me read you a few things I’ve got here and we’ll see what color you are when I’m done.

This one is from a car insurance policy. It says:

“Unless otherwise stipulated, upon demise of the insured person, the insured capital is provided, in case of predeceasement of the beneficiary relative to the insured person, to the latter’s heirs. In case of commorientes of the insured and it’s beneficiary, to the later’s heirs.”

Next, I’ve got a medicine leaflet, “Beware. Erytheme, edema, vesiculation, keratites and urtication can still occur.” Got that?

This one is really good. Is signed the new office’s tenancy agreement on Friday and it said: “I, the guarantor, assume the tempestive payment of the lease, waiving the benefits of division and previous exclusion.” When I read “tempestive payment” I pictured myself barging into the landlord’s office, slamming the door and shouting “HERE’S THE MONEY!” But that’s not what it means. It’s not.

When we move away from our area of expertise, and we don’t’ have to go very far, it doesn’t have to be string theory, when we move away from our area of expertise, we’re as much in the dark as Mr. Domingos. And these are not documents written by experts for experts like the string theory ones. These are documents written for me. These are public documents. Documents I need to understand to get by daily. To live my life. The tenancy agreements, the medicine leaflets, the power bills. All these should be clear, so we can understand them. Because, what happens if they’re not?

I’ll give you an example of mistakes, bad decisions, due to misunderstandings of bad documents. You remember the “subprime crisis” in the United States? People were signing agreements without truly understanding what they were agreeing to. If they knew, they would have realized as soon as interest rates went up, their mortgage payments would shoot through the roof. Do you think that, if the financial sector had a culture … captions missing…

This huge gap between the average literacy level, and the complexity of public documents, all the way… captions missing …

Well, the most obvious solution, given that literacy is .. captions missing… Let’s teach people. It’s obvious. Of course we must teach people. But it’s hard, and it’s slow. I don’t even want to imagine how many generations it will take for us to reach Sweden’s level. But it’s not just because it’s slow. There is another reason. If the documents’ language isn’t simpler, we already see that even people with high literacy, people like you guys, struggle to understand a document if the language is complex. Yes, we must improve literacy, but right now, it’s much more important to reduce public documents’ complexity and simplify language.

I’ll give you an example. this is what I mean by “simplify language.” This is an extract from an insurance contract: “It’s agreed the insurer blah blah blah…” Compare the before and after versions. This is what I mean by “simplifying language.” It’s communicating in a simple and clear way so that our reader understanding it the first time. Which one do you prefer? Pretty obvious, isn’t it?

So, how can we get the government and businesses to communicate with citizens in a language they can easily understand? There are several ways. Some countries have take the legislative route. Last year, the U.S. and Sweden passed laws which require the State to communicate with people in a language they can understand.

You might think: “But that’s normal. Sweden and the U.S. are more advanced than us.”
“It would be nice if we also had these laws, wouldn’t it?”

It would. And you know what? We do. Since 1999. The administrative modernization law says the communication between State and the people must be simple, clear, concise, meaningful, without acronyms, etc. etc… But no one complies with this law. The legislation route only works in countries where laws are made to be applied.

But there is another way. The marketing way. And how does it work? Private companies simplify tier language, they make a big song and dance about it, consumers love it, sales go up. Works a treat. But it works just for the private sector.

And there is a third way, which for me is the most important. It’s through civic movements, which are based on a change of mindset.

In those countries where this succeeded – remember the English symbol of the Plain English Campaign? it’s often based on consumers’ movements.

And how do you star a civic movement? We need to understand two very important things. First, wanting to understand public documents, it’s not a whim, its not intellectual curiosity. t’s a daily need and, most of all, it’s a right. It’s everyone’s right.

So, understanding is a right. But there’s something else. Those who write, must write to be understood. How do we make this work? First, we need to become more demanding consumers and citizens. Think about it. Next time someone hands you a document you just can’t understand don’t just let it go and pretend you get it. No, demand to understand. Ask questions. I know it’s not easy to ask the guy in the suit: “This bit here in the contract, what does it mean?” It’s not easy at all. Maybe even a bit embarrassing. But don’t worry. It’s actually a sign of intelligence. What do you teach your child to do when they have a question at school? “Be really quiet, pretend you know and make a clever face.” That’s not it, is it? You say: “When you don’t know, stick your hand up and ask until you get it.”

And that’s exactly what we need to do as consumes and citizens. Next time you’re handed a document you don’t get, demand to understand. Put pride to one side for a bit and ask until it’s all clear.

Then there’s another side. Those bad documents don’t just fall from the sky. Someone wrote them. In such a large audience, there are probably some lawyers, public servants…Don’t worry, I’m not asking you to stand up. But I do ask you to think about it. How many times do you write documents for the public, for those who don’t share your language, and you do it in a way that only you will understand? And you’ll say: “But there’s a reason for it.”

My friends, I’ve heard them all. There are thousands of them: “It’s the way we’ve always done it,” “my boss…” “the judge…” “what if it goes to court?” “You want to destroy language,” “We have to educate people,” “We can’t lower the standard.” Blah blah blah. I’ve heard them all. They’re all excuses.

Someone mentioned Einstein before. He said once: “If you can’t explain it simply, you don’t understand it well enough.” For Einstein.

So… (arggh running out of time!) If you know what you want to say, you just need to believe it is possible to write it in a clear way. And how do you do it? It’s very easy. You write for your Grandmother. I’ll show you Grandma. You write with respect and without patronizing her. And you use these three techniques.

First of all, you start with what’s most important. Grandma is busy. She’s not going to read three full pages just to get to the main idea. Start with what’s most important.

Second, use short sentences. Because Grandma, like any of us, if the sentences are too long, by the time she gets to the end, she won’t remember the beginning.

And finally, the third: use simple words. Those that Grandma already knows. OK? It’s easy.

Before I leave, I’d like to tell you about Claro. It’s a social responsibility project with the aim of changing the way public communication is made. What do we do?

We’ll start this year with a collection of Clear Guides. We’re going to take very complex subjects and boil them down to the essentials. We’ll start with the Clear Guide of the Justice System, which, I think, will be very useful.

Another thing we’ll do is give prizes to the best and worst documents. Because there are people out there trying to communicate clearly and should be rewarded. And there’s some lazy ones who don’t even try and should be humiliated. So, we’ll award the best and worst. I’m counting on you to help out. The campaign will be launched through Claro’s Facebook page. So become friends and you’ll be up to date.

But finally, most of all, what does Claro want? We want to put two ideas in your heads.

First demand to understand.
Second, write to be understood.

Write for Grandma. But if you don’t have a Grandma, write for Mr. Domingos. He’ll appreciate it.

Thank you.

Accessibility research can help us better understand how people with disabilities use the web and what we in product design and development can do to make that experience more successful and enjoyable. However, accessibility research is often carried out in academia. The valuable insights gained through research are shared and built upon among scholars, but often do not make their way into the practice of people who are designing and building digital products and services.

In this podcast we hear from Dr. Jonathan Lazar, a computer scientist specializing in human-computer interaction with a focus on usability and accessibility. Jonathan has done a great deal of work bridging the gap between research and practice. He joins Sarah Horton for this episode of A Podcast for Everyone to answer these questions:

• What are different accessibility research methods and what they are good for? And when are they most effective in the product development lifecycle?
• What are the broad benefits of accessibility research?
• How can you get organizational buy-in for conducting accessibility research?
• How can researchers and practitioners work together to advance accessibility?

Transcript available · Download file (mp3, duration: 37:38, 34.9MB)

Jonathan Lazar is Professor of Computer and Information Sciences at Towson University, where he directs the Information Systems program and the Universal Usability Laboratory. He has been working in accessibility research for 15 years, most recently focusing on law and public policy related to web accessibility for people with disabilities. His publication credits include Research Methods in Human-Computer Interaction, Web Usability: A User-Centered Design Approach, and Universal Usability: Designing Computer Interfaces for Diverse User Populations.

Resources mentioned in this podcast

• Evaluation tools: WAVE, WorldSpace
• Locked Out (Video) by Jonathan Lazar
• Cambridge Workshop on Universal Access and Assistive Technology (CWUAAT)
• SIGCHI Public Policy
• Harvard Law School Project on Disability

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes · Follow @awebforeveryone · Podcast RSS feed (xml)

Transcript

Sarah Horton: Hi, I’m Sarah Horton. I’m co-author with Whitney Quesenbery of “A Web for Everyone,” from Rosenfeld Media. I’m here today with Jonathan Lazar.

Jonathan is a computer scientist who works on topics related to accessibility and universal usability. Among his many activities, he directs the Information Systems program at Towson University conducting research on what people with disabilities need to successfully use the Web and how well or how poorly we, who build the web, are meeting those needs.

Jonathan has a great deal of experience with different research methods. We’re here to learn the benefits and drawbacks of different methods for evaluating accessibility of websites, applications, and apps, and how we can incorporate accessibility assessment into practice. Jonathan, thanks so much for joining us.

Jonathan Lazar: It’s a pleasure to be here with you today, Sarah.

Sarah: First of all, can you tell us about the Information Systems program at Towson?

Jonathan: Certainly. Since 2003, I’ve been director of the undergraduate program in Information Systems at Towson University. At Towson, all of the computing programs are in one department. We have computer science, information technology, and information systems.

In our program at Towson, we like to say that information systems focus on the four Ps — People, Process, Policy, and Profit.

Students in our program learn a lot about human computer interaction. They learn a lot about using technology, business needs, hence the profit. They learn about international technical standards and the laws related to technology. They learn about design methods for including users into design to ensure a good outcome. They learn about testing and evaluation.

Again, starting with a P for People, they learn all about human computer interaction and how to build interfaces that meet the needs of users.

We’re really excited. This fall, we’re actually implementing four new career tracks at Towson University for our undergraduate students. Students will pick from one of these career tracks to help them focus their electives towards a specific job goal.

Those four career tracks are user interface design, system analyst, business analyst, and E-government. Those are the four career tracks and we’re excited. Students are already signing up for them. We’re going to help them go directly into these different careers and really helps define what we’re interested in and what our goals are in information systems.

Sarah: That sounds like a great program. Sounds like something I’d like to sign up for. [laughs]

Also, I know you direct the Universal Usability Lab, which is also somewhere I’d like to spend some time. It sounds like it’s right up my alley. Can you tell us a little bit about that as well?

Jonathan: I founded the Universal Usability Laboratory at Towson in 2003. We just celebrated our 10th anniversary. The goal of our laboratory is really to do research but research focused on practitioners and policy makers. We’re not doing theoretical models. What we do is research that can really help improve the outcomes of technology in our community and in society.

It’s a number of people involved. It’s myself, Heidi Feng, Joyram Chakraborty, and Suranjan Chakraborty, who are all faculty and a number of doctorate students, as well, and a number of graduates of the lab.

The idea is we do research about user diversity. We’re interested in people with perceptual impairments, motor impairments, and cognitive impairments. We’re also interested in users with very little computer experience. We’re interested in older users and younger users. We’ve very interested in these issues of user diversity.

Our research tends to be targeted towards either industry and practitioners. For instance, we do a lot of work that we publish in the UXPA. We’re also very interested in doing research that informs policy makers.

I can talk about this a little bit more later, if you want. Typically, if you’re aiming your research towards policy makers versus impacting those who fund public policy and government policy, it’s a little bit different.

Our research is really aimed at impacting policy makers and impacting practitioners and developers.

Sarah: You must have quite a toolbox of methods for doing that research. One thing we’d really like to learn from you today is about some of those methods.

Whether you have favorite methods, and are some things good for some tasks and not for others? How do you convey that information from your research to those policy makers in a way that is persuasive, and hopefully prompts some action on their part?

Jonathan: Generally, we have three different types of evaluation methods related to accessibility. You could have your typical usability testing where you have people with disabilities attempt to perform task on whatever level of interface you have, whether it’s an early prototype or a fully finished interface.

You can have expert inspections or expert reviews where you have interface experts or accessibility experts that go through a series of interfaces whether we’re talking about screens on a desktop, or whether we’re talking about mobile devices, or whether we’re talking about an operating system but you have expert inspections which are, again, inspections. It’s not users attempting tasks.

For things like websites, you also could do automated accessibility reviews, where you have a software tool. So something like Deque WorldSpace. Something like the free tools on the web, like for instance you have WAVE. Something like the paid tools, so you could have Comply First.

There are a lot of tools out there that you could use. They have a limit though. Really what you need is some combination of user testing, expert reviews, and automated reviews.

The question really is, which are the appropriate methods do use, in which scenario?

Let’s start from a practitioner point of view. The most important thing to do is actually impact the design. Your number one goal is to impact the design. You could do a perfect method and a perfect data collection, and it could last six months. If you spent six months doing it, you wouldn’t actually influence the design. They would have moved ahead without you.

Let’s first say that the most appropriate method that you can use is the method that will actually lead to results. Given that, you have to look at what the budget is. You have to look at what the timeline is. You have to look at where you could actually impact the design to improve accessibility. That’s the first thing.

Sarah, I think you would agree with me. If you’re going to do a perfect study that won’t get anything done, why do it?

Sarah: Exactly. It’s a very good point about timing, and things like that. That really influences whether anyone can actually do something with the results of your research.

Jonathan: I always when I talk with my students, I tell them, “What’s the right number of users? What’s the right level of testing?” It’s whatever you can get into the timeline, given the budget, given the limitations, that actually will allow you to influence the design. That’s what we’re interested in. We’re interested in influencing the design.

For someone to say, “Well, we must do a strict 40 user Usability Test,” that’s not that likely to actually impact. That’s not likely to impact the design.

Let’s talk about some of the strengths and weaknesses about each one of these three methods. When we talk first of all about Usability Testing — we’re talking about getting users with disabilities — one of the challenges there is that you have to determine which users with disabilities and which disabilities are likely to use whatever that interface is, that website, that device.

One of the challenges is if you say, “Well, I’m going to have blind people test it. I’m going to assume that applies to everyone with every disability.” Clearly, that’s not true.

What you need to do is get a sampling of different disabilities that represent the target user for whatever operating system, interface, website, device you’re referring to.

You need to make sure that you have a sampling of not just people with one disability. People with a disability typically can only find accessibility problems that relate to their disability.

One of the strengths of user testing, first of all, it goes beyond simple technical accessibility to make sure it’s easy to use.

One of the core problems we often talk about is that someone will say, “Well, I followed the technical standards, so I think it’s accessible.” In fact, it may be accessible, but really hard to use. So it’s not really usable.

User testing is also really good for determining usability of multi-step processes. Let’s say, if you have a dialogue boxes or a series of screens, something like signing up for a new email service, something like purchasing an item online, something like registering for classes, where it’s not just one screen, but five or six different screens that you have to go through, Usability Testing is most accurate on that.

Next, on to Expert Inspections. Expert Inspections, as you know, should always be done before Usability Testing if possible in the schedule. Experts can find some of the obvious flaws first, get those improved, and then hopefully you can have users actually find sort of the more fine grain problems related to accessibility. So if possible, an Expert Inspection first.

We typically have people who are experts in accessibility. Sarah, I’m sure you’ve done many expert inspections, right?

Sarah: That’s right. What you’re saying is you do an Expert Inspection prior to Usability Testing?

Jonathan: Absolutely. If you can do that in the schedule with the budget, you should do that. Hopefully, the expert in interface design can find a few major accessibility flaws, get those fixed, and remove those by the time that the users actually get to evaluate the interface.

Expert Inspections typically won’t figure out if the interface works really well, in terms of ease of use. They can determine if it technically meets the requirements, but there may be things that relate specifically to the task. Obviously, the expert may not have deep task knowledge. They may have deep knowledge of the interface.

One thing though an Expert Inspection is really good at, is very good at determining compliance with either technical guidelines, or with legal requirements.

Typically, usability testing will tell you where there are some flaws. You can’t run three blind users, have them evaluate an interface and they can’t tell you if it complies with section 508 of the Rehab Act or not.

An expert inspection is typically better at evaluating a series of interfaces for strictly on compliance. Basically, the expert’s going, “OK, does it meet paragraph A? Does it meet paragraph B?” That’s expert inspections.

Automated reviews are actually the weakest evaluation method, however they have one strength.

I’ll tell you why they’re weak first. They’re weak because, obviously if you could have human expertise inspects an interface, that’s better. Or, if you can have real users with disabilities inspect an interface, that’s better. The real weakness of automated accessibility testing tools is that they often can’t tell if something is useful.

The example that’s given often is that all web pages need to have alt text. Alternative text that describes what is on the screen for a certain image or something like that. If there’s alt text for an image and the alt text is the word “blank,” or the alt text is “picture here.” Or, let’s say there are 20 pictures on a web page and the alt text for every single picture is “hamburger.”

Unless you’re actually running a hamburger store and all your pictures are indeed hamburger, an automated tool would mark this as you’ve met that paragraph of the law because you have alternative text for a picture, even though the alternative text might not be useful at all. It’s “hamburger, hamburger,” or it’s “picture here.”

The idea is that automated accessibility inspections…the software tool is actually the weakest. However, they scale really well.

Given that with user testing…You want to get as many users as possible, but you’re probably not going to be able to get 50, 100, 150 users. Given that expert inspections are great but you’re probably not going to have time for the expert to inspect every single web page in a website, the automated accessibility tools scale really well.

You can have a tool spider through your whole website. You could have it examine 10,000 web pages.

Automated tools are good at giving you the overall picture of how your website is doing and what types of flaws occur most often. A lot of times the automated tools will either give you information that can be misleading. “Oh, it has alt text,” but the alt text isn’t actually useful.

Or, it may give you results that you have to interpret. It’ll say “There are manual checks required due to the presence of these features.”

Really, you want some mix of automated review, expert inspection and usability testing. Of course what combination you use and how much depends on the timeline for your project. It depends on the budget for your project. It depends on how you will be able to influence the design.

We shouldn’t focus on doing perfect experimental design of our research here. We should focus on, “How do I influence the design and what methods will give me the information I need to fit into the timeline and budget, to actually influence the design?”

Sarah: Thanks, Jonathan, for that very clear and thorough exposition of those three methods.

It’s great to think about how each of them might be used in different ways within a project and certainly, how each has strengths within the context of different constraints. Like time, resources and numbers of people available to do usability testing, for example.

A couple questions come to mind. One is, who should be asking these questions about what needs to be done and when? How can, particularly user experience designers know when and what to do? What tools to use and add these tools into their tool sets for making decisions about design and integrating these research questions into the process of designing and building.

Jonathan: User experience professionals are really in the right situation to be able to have an impact. User experience professionals really need to advocate for accessibility.

Accessibility happens as a group effort. If you think about like in a university, you have to have a number of different people involved. Not only do you have to have the disability student services office, you also have to have the CIO’s office, the people who control the technology. You need to have any people who are involved with diversity. You need to have the provost involved.

The user experience professionals have an advocacy role to get out there and inform people about technology accessibility. Really informing people and making them aware is what I’d say is the biggest challenge. In many cases, people simply don’t know.

If they didn’t grow up with people who are blind, people who are deaf, people in wheelchairs, they don’t know. They’ve never considered how someone who’s different than them might use technology. Very often it’s an awareness issue.

User experience professionals, because they’re already going out there informing people about usability and all those issues for user centered design, they’re really in a great position to advocate for accessibility. To let people know, “Hey, you have all these different users. Here’s how they use your technology.

Here’s what you can do to make it better. We have these technical standards. Do you love what we’ve already done with user experience? Guess what we can do related to accessibility.”

You asked also, I believe about tools, right?

Sarah: Yeah.

Jonathan: One of the problems with most developer tools is that there isn’t much front and present to developers about accessibility in the tools.

Imagine if you had a web development tool that every time you insert an image, it would immediately say, “What is the alt text?” If you didn’t type in alt text, it would stop you from moving any further. Wouldn’t that be great?

Sarah: It would be great.

Jonathan: One of the problems is that developer tools — whether they’re web developer tools or any other developer tools — often are really transparent about accessibility. Yeah, there might be some accessibility features hidden away somewhere, that you have to look and search for. It’s not front and present.

That’s a common problem in many organizations. You ask them, “How are we doing on IT accessibility?” They say, “Well, we don’t know,” rather than saying, “Here’s how we’re doing. In the month of May, here’s the type of evaluation we did for accessibility. Here’s how we did, but we’re going to work on improvement.”

Think about the airlines. The airlines post, “In the last month we are 87 percent on time, which was an improvement over last year.” Why can’t we get organizations to do that for accessibility?

“We’re 87 percent accessible, and we’re getting better every month.” You rarely see any organizations with that level of transparency, right Sarah?

Sarah: Right, but I guess my initial question would be, are they doing those assessments to begin with? Are there numbers to report on?

That actually feeds very well into my next question about what organizations can do to incorporate some of the research methods that you’ve been talking about to build better products. Then they would have numbers to share.

At this point, I don’t know if many companies, organizations or design teams are actually monitoring accessibility in quite that way.

Jonathan: You read my mind, because that was the next thing I was going to talk about. Why do they often not report statistics? Because very often they’re not doing evaluations. The organizations — whether they’re government agencies, universities or companies — they don’t know how they’re doing. They’re not doing the evaluations.

It’s hidden secret. “We don’t know how we’re doing, so don’t ask about it.” Instead, what we need to get organizations to do is to talk about it and say, “Look, we haven’t done evaluations. We’re going to start.”

If you look at, in 2010, there was a memo coming out of the US federal government, that talked about the fact that the Justice Department hadn’t been doing their evaluations of federal government websites since 2003, but they were going to start doing it again.

I really give them credit for that, that federal government, and there were a number of parties involved, the Justice Department, OMB, GSA, they really all said, “Yeah, we haven’t done this, and the law requires this, and we’re going to start doing it again.” And the Justice Department did.

What we need is to get companies to follow the lead of the Justice Department, in saying that, and admitting that. “Yeah, we haven’t really paid attention, but we’re going to start paying more attention, we’re going to start doing more evaluations, we’re going to start making this a priority.”

Because once you find out how you’re doing, of course, what’s the next step? “Oh, we’re not doing well. Well, we need to start making some improvements.”

Sarah: Jonathan, I really agree with what you’re saying about organizations needing to be more transparent about the work that they are doing in accessibility, and I think what I’m trying to get to in this conversation is some practical guidance, as to how to go about doing that research. This is one thing that organizations struggle with, and not really having the tools and the knowledge that you’ve been sharing with us, today, about how to assess accessibility, and improve it.

As you know, because you were there, I recently attended the Cambridge Workshop on Universal Access and Assistive Technology, which you co-direct. It was a really great conference, and I was delighted to be able to participate. I was so struck by the insights that were shared at that conference, from the research community and the scholarly community, primarily.

I also came away, though, with the feeling that all of that great information and insight isn’t making its way into practice, into organizations, so that groups know how to move forward, based on the insights gained through that knowledge. People who are looking really deeply into accessibility are in one place, and the people who are trying to provide accessibility are in another. There is a big gap, in between.

From what I know of your experience, you’re a person who is both a researcher and a practitioner. You work with researchers and you work with practitioners, and have found a way to bridge that gap. If you could tell us a bit about how you’ve found ways to do that, so that organizations could move forward with accessibility in a more deliberate and an informed way, benefiting from all the insights in the research community.

Jonathan: My approach is simply that I talk with everyone. If a group wants to have me present, if there are some people I want to do outreach to, I just go talk with them. A lot of times, there’s a hesitation by, especially university researchers, not as much the industrial researchers, but there’s a hesitation to work with practitioners.

There’s this silly hesitation about, “Well, we want to stay in our research lab, we want to do a clean study. We want to do it this way.”

I say, the world is messy. Let’s get out there, and work on influencing the world. Yes, it’s messy. Yes, you can’t control as many factors. Yes, it may not be a neat study that you can publish in a certain journal. But the reality it, what could be better than actually influencing either practitioners in UX, or developers, or policy-makers.

The key thing is to first engage with people and say, “I’d really like to talk with you more about the topic of accessibility.” UX developers go out and talk to researchers, researchers go talk to practitioners and policy-makers.

The first step is simply to engage, and to talk. The next step is to find out, what do you need? What information do you need, and in what format do you need it? Because, if you present to different communities, if you present to all these different people I talk with, researchers and practitioners, they all have different needs. We talk about user-centered design, you need to understand the user needs.

For instance, if you look at public policy-makers, there’s very little data from the UX and HCI communities that actually is influencing public policy. Why? Because we don’t have things prepared in the format that policy-makers need. For instance, policy-makers are very interested in year-after-year studies.

They don’t want to know if we’re doing perfect work, they want to know, are we improving? So you’re saying, maybe, “Three years ago, our websites were 50 percent accessible, and now we’re at 70 percent. Our goal next year is 75 percent.” That’s great, we’re making progress. You might say, “But we’re only at 75 percent.” But a policy-maker sees progress.

They’re very much interested in longitudinal studies. In the HCI research community, we don’t do many longitudinal studies. On the other hand, if you look at, let’s say, the healthcare community, the medical research community, they do tons of longitudinal studies. We have to figure out, what do other communities need?

When I present to practitioners, I always make sure to give lots of examples, and be very specific about policies. One problem, that as researchers we often do, is we say, “There’s a law that says that it must be accessible.” We need to learn, when speaking with these other communities, to be specific. What, specifically, is the law? Is it a federal law? Is it a state law? What does it cover? Who’s covered? What type of compliance mechanisms are in place?

It’s very often about, first engaging with these other communities, and then really trying to figure out, what do they need? What format do they need things in? What are their questions? Say, “What are the questions you’d really like to have answered?” That’s how you do it and not to be scared of messiness. The world is messy. Yes, we have to get out of our university and engage with the world.

I’ll give you an example. I’m working on a project, right now, with my undergraduate students. I teach a class that’s just about technology designed for blind users. The students are working with Baltimore County Public Library, to evaluate the services that the Baltimore County Public Library offers for people who are blind or low-vision.

I tell the students up front, “I think this is going to be the most awesome project we’ve ever done in this class. I could be wrong. It may not work out well. But that depends partially on the amount of work you put into it.” When you do a real world project, you have to be up front about that. Yes, it’s going to be messy.

Rather than be in our usability lab and focused just on experimental design, if we’re going out and trying to implement things in the real world, there will be lots of unexpected things that we find along the way. We’ll probably find some new flaws in our interface. We’ll probably find some technical challenges that we have. That’s exactly why we should do it.

Because, if we do only experimental studies in the lab, very controlled, we’re not really able to influence the world. We have to get out there in the world, and see what real challenges people face. What are the real challenges with the technologies we build? How do we tweak the technologies? Where are there problems in our technologies?

How do we impact on public policy? How do we impact developers? How do we impact practitioners’ end-user experience?

These are really my ideas. Engage with people, find out what they need, and don’t be afraid of failure, don’t be afraid of messiness.

Sarah: Sounds good. That’s really great. You’re putting the onus primarily on the research community. Is there something that the practitioner community can do to work the other way? There were very few people at that workshop that I mentioned, that were from industry. How should the practitioners, and people who are out there building things, how should they be engaging with the research community?

Jonathan: Practitioners should do everything they can to reach out to university researchers, as well as industrial researchers, and say, “Here are some questions that we don’t have resolved in our community. What could you contribute to making this happen? We want to find a way to work together.”

And realize that, as they do that, you have to get to know other communities. You have to get to know, what are their reward structures? What do they get credit for? What do they get dinged for? That’s part of it.

I wasn’t just speaking as a researcher. I was saying practitioners should absolutely go out, talk with researchers. Both practitioners and researchers should go talk with policy-makers. Go talk with your local government official, who probably will actually, really want to talk with you. They’ll want to say, “Yeah, I’ve been having these problems, and I don’t have data on this. I don’t understand the problem. Can you give me some more information?”

It’s many different communities. It’s technology developers and software engineers. It’s UX practitioners. It’s researchers. It’s policy-makers. We all have to get out of our comfort shell, and go out there and explore with other communities. Be willing to fail. Be willing to say, “It may be messy, but we need to at least start the engagement process.” A lot of people never even get that far.

Sarah: You’ve mentioned a few times, policy. I know that you spent a year at Harvard, as a Fellow, researching public policy. It’s interesting how some of your insights today relate to ways to use the research techniques and results in a way that are going to be persuasive, and affect public policy. If you could talk to us a little bit about how you ended up taking this path of researching public policy as a computer scientist. It’s not a common path.

Jonathan: [laughs] No, it certainly is not. It was very interesting. I’ve been doing accessibility research for about 15 years, now. I’d been doing user diversity, before that, but accessibility for about 15 years, now. What kept happening is that I would get calls and emails from policy-makers, asking me, “Hey, do you have any data on this?”

I would receive requests from the disability community, from the advocacy community, saying, “Can you go talk as a researcher, about research foundations for this bill in the legislature?” Policy-makers at the federal level, too, would reach out to me. Over time, I kept seeing this pattern. I kept getting requests for information to really help influence public policy.

No one’s asking me to be an expert on law or policy. What they’re saying is, “Can you give me data? Do you have research studies that can answer some of our policy questions?” That’s, at a core, what I’m interested in. I’m interested in, at least from the policy point of view, how can we use human-computer interaction, usability experience, accessibility research data, to help inform policy-making?

Because a lot of policy-making in this area doesn’t have any data, it doesn’t have any research behind it. There are a lot of other fields that do much better at this, than we do.

Over the years, I kept getting requests for, again, “Do you have any data on the following topic? How is our state government doing? Can you talk a little bit about this bill and, from a scientific point of view, what this bill in the legislature means?” Over time, I kept getting more and more requests. Freely admitted, I don’t have a public policy or a law background. My background is in human-computer interaction. I was getting request after request.

I’d been involved with SIGCHI, a special-interest group on computer-human interaction. I had been a founding member of the US Public Policy Committee for SIGCHI. Later, that role was expanded, where in 2010, they created a new position, called the International Chair of Public Policy, and they asked me to serve in that role.

I’m doing more and more public policy, and I thought, because I’m doing public policy, I really need to have a little bit more of a foundation in disability rights law and public policy.

I applied a number of different places. I was very thrilled that I won a fellowship at the Radcliffe Institute for Advanced Study at Harvard University. The Radcliffe Institute is a fantastic place. They specialize in people who do interdisciplinary work, and they will fund people. They will fund a portion of your salary, to spend a year at the Radcliffe Institute.

You apply, it’s about a five percent acceptance rate, and you apply for one of these Radcliffe fellowships. They have 50 every year, across all fields.

I was thrilled. I won one of the Radcliffe Fellowships, so I was the Shutzer Fellow at the Radcliffe Institute for Advanced Study. I spent a year investigating and researching the intersection between disability rights law and public policy, and human-computer interaction for people with disabilities.

As you know, I was really involved with the Harvard Law School Project on Disability and Michael Stein. In fact, we had some publications out already about these topics related to, for instance, societal discrimination. There’s a great video, also, if you go to YouTube and search on Jonathan Lazar Harvard. There is a great YouTube video of my fellowship presentation, which talks all about societal discrimination against people with disabilities occurring when a website is inaccessible.

If a technology is inaccessible, how does that lead to a form of discrimination, like employment discrimination or pricing discrimination? Over time, I got more and more involved with public policy and I said, “I want to do something related to policy and law for my sabbatical.”

Again, I applied and I was thrilled that I won one of the fellowships at the Radcliffe Institute. That really has helped me get a much deeper understanding of public policy and disability rights law related to my human-computer interaction.

For instance, I continue to do work in ACM SIGCHI, where I continue to serve as International Chair of Public Policy. We’re working on a rapport to service, a foundation, for understanding human-computer interaction and public policy.

Also, if you look at SIGCHI, I’ve been involved with, but I’m not leading the effort, related to making SIGCHI more inclusive for researchers, practitioners, developers and students with disabilities. SIGCHI has been working both on conference accessibility, making sure that our conference locations are accessible for people with physical disabilities.

We also have been working on digital accessibility, working on improving our conference website, working on improving our submissions to the digital library, so we are making progress on making SIGCHI a more inclusive organization.

Sarah: Now that you’re back at Towson after that year of doing research into public policy, are there things that have changed the way that you approach accessibility research on, for example, the three methods that we talked about earlier and pulling that all together at this point? Are there ways of doing accessibility research that we should be looking to in the profession, in the UX profession, to influence things like public policy, in terms of how we administer and how we use our research methods to learn about accessibility in products and services?

Jonathan: I certainly learned a lot last year on the fellowship. I learned a lot about disability rights law and have a much deeper understanding of the law. One of the things I think that is important for all UX professionals to understand is that anytime you talk about policies or laws, be very specific.

That’s something I really learned last year. That they cite specifically, “Title II of the American Disabilities Act, Paragraph III.” That’s the way that people do policy in law, typically refer to things rather than saying, “There’s a law that said so.”

Anytime we reference a law or a policy, we need to be very specific about what we’re referring to. I do think that when you look into not only the laws, but the regulations, when you look into legal settlements, you see a little bit of a trend where the legal settlements now are being much more specific about the evaluation methods required.

You didn’t used to see that. It used to be that some form of testing will be required, some evaluation. Now, for instance, if you look at the two legal settlements recently with the University of Montana and Louisiana Tech, they’re very specific about the type of evaluation methods required.

For instance, for one of the settlements, the university has to file an annual report documenting compliance with the Department of Justice. With the other one, they have to do user testing involving people with disabilities.

That’s slowly starting to become more encoded in all the various forms of policy, the statutory laws, the regulations, the legal settlements and such. That’s something that we really could help with. The more that the UX profession could help inform policymakers about the different methods of evaluating for accessibility, the strength and weaknesses, the more information we can put out there.

Again, the more transparency we can get, the more we can talk about it because a lot of people still don’t know. If you went to these universities, a lot of the higher-ups say, “Well, I had no idea. I didn’t know.” We need to do a much better job educating people out there about accessibility and different evaluation methods for accessibility and why it’s important.

That’s my charge to everyone who’s listening to this podcast, get out there. Talk with people. Connect with people. Inform them about accessibility state-wide, it’s important. Give them your business card. Make sure that you do your best to get the word out because there are still a lot of people out there who are not aware.

Awareness, openness, and transparency are really the best ways that we can move this topic and this agenda forward.

Sarah: Thank you so much, Jonathan. That’s all really helpful and insightful. This has been Jonathan Lazar talking to us about the best ways to gain and share insights through research to help in building a web for everyone.

Many thanks to you all for listening and to our sponsors — UIE, Rosenfeld Media, The Paciello Group, and O’Reilly — for making this podcast possible. Follow us @awebforeveryone on Twitter. That’s @awebforeveryone. Until next time.

An edited version of this interview appears in Chapter 11 of A Web for Everyone.

Valerie Fletcher, Executive Director of the Institute for Human Centered Design since 1998, helped shape the Principles of Universal Design. With many years of engagement in advancing accessibility and universal design in the public and private sectors, Valerie has a deep knowledge and clear perspective of the challenges and opportunities that exist in moving forward the agenda of universal design for web accessibility.

We wanted to learn what she considers to be the greatest challenge in integrating accessibility into the practice of web design.

The state of accessibility and universal design

Valerie Fletcher has been Executive Director of the Institute of Human Centered Design since 1998. That year the Institute, at that time called Adaptive Environments, took the lead and collaborated with the Center for Universal Design in Raleigh, North Carolina, Hofstra University, and the Universal Design Newsletter, on sponsoring the first International Conference on Universal Design, called “Designing for the 21^st Century.” It was at this conference that the Principles of Universal Design were disseminated for the first time to an international audience.

The Institute of Human Centered Design was a key partner is developing and promulgating the principles, and has been instrumental in promoting universal design through training, education, and by its multi-disciplinary design services. They provide consulting services that include accessibility compliance and design solutions that integrate universal design features in built environments, products, and Information and Communication Technology.

With many years of engagement in advancing accessibility and universal design in the public and private sectors, Valerie has a deep knowledge and clear perspective of the challenges and opportunities that exist in moving forward with the agenda of universal design for web accessibility. “I have both tremendous optimism and tremendous anxiety that we’re never going to get anywhere. Good ideas don’t thrive just because they are good ideas. But still, I feel more optimistic than I did five years ago.”

Trends transform the practice of design

Design responds to trends. Back in the 1970s and 1980s, architects were thinking about such challenges as designing affordable housing so people could live in peace[md]so they would not deface walls or be at war with their neighbors. This notion of “behavioral design” focused on the function and power of design[md]on how design could be put to the task of creating better living environments.

In the 1990s, functional or environment/behavioral design was replaced by “form as the ultimate good.” “Function became the thing you had to live with because the law required it.” And the field of architecture became one for “lone wolves who felt they had to be more creative, more brilliant than others to succeed.” Much was lost in the shift from human-centered to designer-centered design, including attention to the power of architecture to influence human experience.

In architecture, Valerie notes, “The only time an architect is likely to touch accessibility in a serious way is during licensing. Most commonly in the U.S., the only time one is taught anything about accessibility, let alone universal design, is likely in the context of an introduction to code requirements that teach plumbing code, electrical code, and accessibility. Is it any wonder people think [accessibility and universal design] is about cutting into your creative brilliance?”

Education is a catalyst for change

Education often drives design trends.  Students identify with what they are taught, and how they are introduced to their field. If they are taught that form is paramount, then more functional concerns, such as accessibility, will always be secondary.

Today’s design curriculum does not do an adequate job of covering accessibility and universal design, and the information that is provided is geared toward meeting compliance standards. This approach results in a “just tell me what I have to do” approach to accessibility, which, in turn, produces inadequate designs. “Just tell me what I have to do has not resulted in the kind of creative energy and true innovation we need to make progress in this area,” says Valerie.

What is needed is for universal design to be integrated into the practice of designing buildings, spaces, communications, products, interiors, and software into the design of the things we use, the spaces we inhabit, and the way we learn and communicate.

Building a curriculum in universal design and accessibility

Valerie sees design education as the critical component, but notes a lack of rigor in the curriculum requirements, and a lack of commitment from the instructors. “There is a readiness among the students that is not quite met by the readiness of the faculty, but it is a short bridge. I think they can get there especially in light of the adoption of the value of environmental sustainability.”

Universal design needs to be adopted by faculty and then taught to students. With students, universal design needs to be intrinsic to their practice[md]fundamental to how they brand their work and pitch themselves professionally. “If we miss that opportunity, then it becomes a case of the one-off student[md]the one who, against all odds, persists.”

And she sees responsiveness in the students. Because universal design and accessibility have not been perceived as significant elements of the curriculum, schools do not have faculty teaching the subject. This is where the Institute for Human Centered Design has stepped in, teaching class sessions and seminars on accessibility and universal design. Valerie has found a great deal of receptivity among the students. “With every year, the students have become more and more interested.” Many students seek internships with the Institute.

She also sees a rise in attention paid to accessibility by the accrediting organizations, especially for interior design and architecture. The fields of interior and industrial design are the most progressive today, whereas architecture has historically fallen short. It’s reported that a dominant shortcoming in schools of architecture during accreditation visits is the availability and quality of instruction for accessibility and universal design.

Accessibility guidelines set the baseline

Regarding the accessibility of the digital environment, Valerie notes that there are good efforts underway worldwide. She notes in particular the work of the Web Accessibility Initiative (WAI) of the Worldwide Web Consortium in promoting web accessibility through the development of standards, guidelines, and best practices that is clearly the most widely accepted global source. She also notes that web accessibility has more policy supporting its efforts than other design fields. There are many examples of organizations and institutions adopting a policy of meeting accessibility or universal design standards, even when it’s not a legal obligation. With reliable guidance such as Section 508 in the United States or the W3C/WAI, “mandating policy for inclusive design is a choice any organization can make.”

But Section 508 and the Web Content Accessibility Guidelines are in some ways equivalent to building codes in the build environment. They help in establishing “a floor of accessibility and, in the case of W3C/WAI, beyond that to a high standard of usability.” However, design and designers are too often not part of the discussion, and Valerie sees this as a major failing. “There’s still a big gap in being able to identify great websites that look as good as they act. A lot of designers have yet to be convinced that you can get great design and great usability performance in a single site.”

Great examples inspire great designs

Bringing universal design to bear adds a whole new dimension to the discussion. “You need to drive the conversation by capturing people with great case studies, great examples, great leaders, and bringing in a global perspective. You will see better outcomes if you inspire and catalyze.”

Take, for example, the NAO robot and the iPhone and iPad. NAO is a programmable humanoid robot that is being used for such tasks as providing assistance to people with significant dexterity and mobility limitations and teaching social interaction to children with autism. Apple’s mobile devices offer a wide array of interaction modes, including speech recognition and text-to-speech, so people can interact with software on the device in whatever way suits their context. As Valerie notes, “People learned a lot about design that is user friendly from Apple.”

Looking ahead, Valerie sees the demand for customization and personalization of technology products and services as a catalyst for adoption of accessibility and universal design concepts by designers. “If you take ‘we’re all different’ as the starting point, and then train designers to respond to that reality, then you hit the sweet spot.”

If you work in user experience or accessibility, you probably spend part of your time on advocacy–making the case for a new design idea or a new way of working. Lawsuits are the ultimate way to get two sides to come to an agreement, but it’s also an extremely confrontational style of advocacy.

A more collaborative process might be a better way to reach your goal with an agreement that is a win for everyone.

Transcript available.   Download file (mp3).   Duration: 22:45 (12.9MB)

Lainey Feingold is a disability rights lawyer with an extraordinary record of landmark cases, including settlements with some big companies that have made their sites more accessible. She’s done all this using Structured Negotiations, a process that lets a group of people work together to find a solution to a problem. It takes active patience, flexibility, grounded optimism, confidence, trust, and a empathy to be successful at Structured Negotiations.

Lainey joins Whitney Quesenbery for this episode of A Podcast for Everyone to answer questions about this new way of reaching agreements.

• What are Structured Negotiations?
• Why are they more effective than lawsuits?
• How can you used the concepts in structured negotiations for UX advocacy?
• What are the characteristics of a good negotiator?

Lainey Feingold is a disability rights lawyer who works primarily with the blind and visually impaired community on technology and information access issues. She is nationally recognized for negotiating landmark accessibility agreements and for pioneering the collaborative advocacy and dispute resolution method known as Structured Negotiations.

Resources mentioned in this podcast

• Law Office of Lainey Feingold
• About Structured Negotiations
• Examples of Web Accessibility Settlements

A Podcast for Everyone is brought to you by UIE, Rosenfeld Media, The Paciello Group, and O’Reilly.

Subscribe on iTunes  –   Follow @awebforeveryone   –   Podcast RSS feed (xml)

Transcript

Whitney Quesenbery: Hi. I’m Whitney Quesenbery, and I’m co-author with Sarah Horton of “A Web for Everyone for Rosenfeld Media.”

Today, I’m talking to Lainey Feingold. Lainey is a disability rights lawyer with an extraordinary record of landmark cases. She’s also a California Lawyer of the Year for 2014, and recognition of her work that includes settlements with companies like Walmart, Bank of America, Weight Watchers, Major League Baseball, and the Safeway grocery chain, all of which have made their sites more accessible for people with disabilities.

Hi, Lainey. Thanks so much for joining us.

Lainey Feingold: Hi, Whitney. Thanks for asking me.

Whitney: I love your work so much. I’ve heard summaries of the kind of work you do focusing on the settlements that you’ve reached, but it seems to me that a lot of the UX work we do includes what I might call internal advocacy that is when we’re working to convince other people on our teams or in our companies, that a new design idea will work.

We always seem to be looking for better ways to make the case. Before I met you, I always thought lawyers meant lawsuits, but you’re doing something quite different, using structured negotiation as an alternative. Can you start by telling us what structured negotiations are? Maybe a quick example of how it works?

Lainey: Sure. Structured negotiation refers to a way to resolve legal claims without litigation. Most of your listeners are probably familiar with lawsuits or mediation or arbitration. Those all involve third parties helping the people at the dispute make a decision or come to a conclusion.

Structured negotiation is a way to resolve claims working directly with all the stakeholders. The way it works is we get a call from most often a blind person that’s usually our client base, but the method would work for other claims as well.

We get a call and, say, we recently did a settlement with Weight Watchers. The person was a blind woman who’s a Weight Watchers member and she wasn’t able to access the tools on the Weight Watchers site. They have an amazing set of digital tools to help people lose weight. She wasn’t able to reach the right people in the company to make it work.

She called the lawyer and we did a little research and found that this was really a health issue that impacted a lot of people in the community. We wrote to Weight Watchers. We said, “This is a claim. You really need to make your website accessible for people with disabilities, usable by people with disabilities.

Rather than file a lawsuit, let’s sit down and see if we can make it work, talking with each other.” That’s how we do it.

Whitney: Do people respond to that? Why would a company be willing to work with you?

Lainey: Whitney, that is a very good question. At the beginning, I first started doing a lot in this way 20 years ago. We had been approached by a blind lawyer who was an expert in tax issues and finance issues. He had written a book, yet he couldn’t use a basic technology to finance industry, which was, and still is, the ATM.

We got this situation. Blind people can’t use ATMs, but the ADA was new. There were no accessible ATMs in the United States. We thought, “Maybe we should a couple of banks and see if we can work with them on a solution.” It worked. I used to think it was luck, but now, I’ve been doing it for 20 years. We have some of the biggest institutions in the United States.

I think that it’s a viable method, and it works because when approached in the right way on these kinds of issues, large institutions can say, “Hey, I didn’t really think about that. With occasions extremely expensive for all sides, let’s see if this thing can work.”

Whitney: You said something at the beginning about how instead of having a third party making the decisions, you got to work directly together. Does that mean that everybody gets to sit around the table together and work? Because I’ve been an expert on some legal advocacy work, and it was really frustrating that I wasn’t allowed to be in the room.

Lainey: It’s funny you mentioned that, because I think the way that structured negotiation brings expertise to the table is one of its strongest qualities. Too often in legal claims, the basic idea of litigation is people are opposed to each other. There’s one side and the other side. Both sides usually need expertise.

Each side has to hire their own expert and that expert has a very defined role when they can speak, what they can write, what are the circumstances when they communicate their expertise.

In structured negotiations, we really try to always think of it as a round table. For web consultants, for example, we really think it’s important for a company to feel comfortable with the consultant that they hire, because every corporate culture is different. There are a lot of great consultants out there, but they wouldn’t all work well with every company.

In our process, we try. The best cases, it works this way

We bring our expertise and the client’s expertise by saying, “Here are these experts. Why don’t you see who will work best with your company?”

Whitney: You’re not just coming to a decision about how to solve a problem. You’re actually helping them get the skills they need, the experts they need to help them solve that problem?

Lainey: With the ATMs, when we started, there were no talking ATMs in the United States. The blind team, a spokesperson really helped the companies understand what makes something usable for a blind person. The developers and the technology people were thrilled to have that input. That’s been my experience throughout.

The people who are doing the work, they want the web to be available for everyone. They want the ATMs to work. Having, especially the usability side of it from the blind users was completely critical. With the websites, we use WCAG 2.0 Level AA as a standard. We know, going in, that that is what we think the companies need to do.

There are many situations where we can have WCAG 2.0 AA compliance, but you still need the user feedback. We did negotiations with the major credit reporting companies in the United States to make sure that blind people could get their credit reports in accessible formats. They had a very unique catch at the time.

We had 19 different blind people testing it on a whole variety of configurations. The process allows for that kind of involvement of the people directly affected

Whitney: That’s really great. It’s a little like participatory design where we go from where designers and we know what you can do to where usability experts and we’ve worked with enough users to be able to represent them to actually letting the users be part of the process.

Lainey: Yes, as much as possible. That just seem so many “Aha!” moments or light bulbs going off when the developers, the designers, the content writers actually get to meet the consumers who are using their site in different ways.

Whitney: It sounds like early usability when we would make what we call highlight reels. We can make videotapes of pieces of the usability sessions for the “Aha!” moments, just to try to bring it home. I knew that we’d tipped over a corner once when I was working with a team. We had done some recording and I said, “What would you like to do?” They said, “Could we just sit and watch?”

They said, “What you said is great, but we’re learning even more by being able to see it directly.” I thought that was a big moment for me in my work, thinking about how we bring people together. It sounds like you’re both trying to solve a problem but also creating relationships. Maybe not with those individuals forever but between a development team and a company and the people they work for.

Lainey: Relationship building is really a critical part of it. In some ways, you could say, “It’s not really fair for any one blind person or one deaf person to be a stand-in for all blind people and all deaf people.” In fact, a lot of people have never met people who need or use a computer without using a mouse or can’t listen to the video unless it’s captioned. They just never had the experience.

Whitney: Does your relationship with the company go on past the settlement?

Lainey: Yes. We write the letter. When all works according to how we would like it to work, we have meetings and then there’s language drafting exchange, we have a settlement agreement. That agreement, at the end of the day, looks very much like an agreement as if we had filed the lawsuit. It’s just we skipped all that procedural nuttiness.

Then like a litigation settlement agreement, eventually, they do expire but we do continue the relationship. We’re working with very big companies with a lot of digital content and sometimes is backsliding, but we have the relationship there to do a quick correct if something goes wrong afterwards.

Whitney: It sounds great. Do you find that solving one problem actually opens the door to their being able to not cause so many problems in the first place? We always have this idea of, “Do the pilot project. That will show them how to do better usability or better accessibility.” Sometimes, we get to see whether that works. Sometimes, we don’t.

Lainey: I am a complete believer in the pilot project, or we call it baby steps. I would say probably 50 percent of our cases, we have had to take small steps first to get the company comfortable with doing the work and to dissolve the fear factor, which is very present in a lot of these issues. They don’t know, “If we offer large print, how many people? Is it going to be too expensive?”

We recently announced agreements with major pharmacy chains for talking prescription information. What might happen if we do this? There are a lot of unknowns. That’s OK. We can take it slowly. That’s another good thing about this process. We can take the first step.

A good example of that is Major League Baseball. We did a deal with them. They’ve been great negotiating partners. We’re representing the blind community, and the focus of the first level of work they did was their website issues, mostly affecting blind people.

We did a second agreement with them, extended that first one as a mobile app, became more popular. Now, they have a very good mobile app. Then this year, really directly unrelated to us but I like to think having something to do with us, they have announced a great captioning program, because they just got asked about accessibility and they’re just really doing a great job.

Whitney: It sounds like it takes a combination of patience and persistence. What skills or qualities do you need to be successful in this style of working?

Lainey: It’s funny you say patience and persistence, because if structured negotiations had a mascot, it would be the stone lions that sit outside the 42nd Street Library in New York, whose names are Patience and Persistence. They were named that during the depression by the mayor who felt those are qualities that New Yorkers should have. I think they’re qualities that negotiators should have.

In terms of the patience, a lot of lawyers feel patience is weakness and if you give extra time or you’re not insistent on holding the deadline, somehow, you’re not protecting your clients’ rights.

I put an adjective in front of patience and call it active patience for that reason, which really just means you’re not waiting around, tweeting your thumbs, hoping the person will do the right thing, but you’re recognizing that in a large institution, and even in a not-so-large institution, change takes time and there’s a lot of cultural factors that you just can’t come in and say OK overnight, snap your fingers, and usability is going to be a principle of this institution. Active patience is key.

Whitney: Your website talks about two other words that I really love. One is grounded optimism, and the other is confidence and trust.

Lainey: Grounded optimism, I actually stole it from someone I know named Gil Friend, who’s a sustainable business guy. He wrote a piece on grounded optimism, and I asked him, “Can I take that for structured negotiations?” Basically, that’s the same thing in terms of putting adjective active in front of patience.

It’s not being optimistic like, “Oh, everything is rosy. If we just wait long enough, everything is going to work out.” It’s grounded in strategy and that if you take the right steps, you can trust and here’s where trust comes in, one way. That’s going to work out.

I believe in negotiations. If you didn’t, it’s not all smooth sailing from the first time we write the letter. Even the companies we have best relationships with didn’t start out, “Oh, thank you so much for writing to us. We’re really glad to have a lawyer on board.” No. If you believe in the process, then you can weather the inevitable downturns that are going to come along.

Whitney: I love that you’re taking such a long view, because it’s really nice to see someone who can see this not as a day-by-day win but something that happens over months and maybe years. I really think that’s a quality that we need more of in UX, which is being willing to say, “Just because it isn’t perfect today, doesn’t mean that we can’t take baby steps that are accumulating.”

I think the thing we worry about is that they’ll be baby steps today and then they’ll be backsliding. It takes 15 more baby steps to get back to where you were.

Lainey: The key is to hold onto the big goal. I was actually talking to my husband about this, because he writes about activism. I was talking about this whole baby step thing and that it’s somehow falling short because another piece that I think has really helped structured negotiations is this idea of appreciation and appreciating the baby steps.

Because when we first worked on the talking ATMs with the banks, Bank of America had 15, Citibank had 5, Wells Fargo had 10. We did these press releases. Congratulations. That was out of their whole fleet. Now, every single one of those banks has every single ATM that’s accessible to blind people.

I think as long as you hold onto the far goal and don’t quit until you get there, the baby steps is a good strategy.

Whitney: You mentioned appreciation. Laura Packer, who is a storyteller and the wife of my co-author — I’m talking about Storytelling for User Experience — talks about appreciations. One of the things that she gets people to do when they’re working on stories is she’ll get one person to tell a story to another. Instead of critiquing it, that person has to give that person telling the story an appreciation of it, what did they like in it, what did it move them to feel.

I loved that because it let us turn off that little critic that sits on our shoulder and yaps in our ear and just let us sit back and think, “What’s good here?” Because her point is that a storyteller with a brand new story they’re working on, or anybody with something brand new they’re creating, doesn’t really need someone to critique them. They need someone to tell them what’s working well so they can build on it.

Lainey: I like that, because I think, as you know, I’m trying to write a book about all of this. It is a whole new thing. As I get feedback from people, I’m like, “Wow, you have to be confident that you’ll get to the end.”

Whitney: Dare I ask when the book will be done or you, like the rest of the authors on “I don’t know, I’m working as fast as I can” plan.

Lainey: Actually, I’m trying to say I’m staying in the present. Right now, in the present, I’m writing the book. That’s about as far as I can go with that.

Whitney: We’ll have to come back to you when it’s further along and see where you are in a future present. I just want to ask you one other thing, which is that when we are thinking about doing advocacy in our own work, just in any other kind of design work, do you have any tips for us that you can think of on how we could apply the principles of structured negotiations to just the day-to-day work of designing a product?

Lainey: Sure. Because I think advocacy skills and strategy are pretty much the same in whatever venue they’re being applied to. I think a lot of these traits that we’ve talked about come into play when you’re negotiating with your own side and your own team. I think that, this is one thing writing a book has taught me when I can take the long view and look at all the cases, usually, when people aren’t readily doing something that you want them to do, there’s a reason for that.

I like structured negotiations because it allows us to tease out that reason. When you sue somebody, the other side has to defend and say what they’re doing is right. There’s really no chance for a conversation about, “I’d like to do it different, but I’m afraid of this.” I think they would apply in any situation to just try to open up the communication to understand what is the issue that’s blocking us from going further.

Whitney: It sounds like we need to understand the motivation on our teams and partners, the stakeholders just as much as we need to understand the motivations for users.

Lainey: I think so, because there could be people are thinking, “How many people are really going to use it this way? Do we really have to work?” There are certain things, and if people are willing to express it, then it can be addressed.

We had a problem with the ATMs at the beginning, because everybody was counting the precise number of users at each ATM. Where are the users?

They didn’t take into account the fact that when ATMs themselves were first introduced in the United States in 1969, the industry had to do a huge amount of work with users to get them comfortable trusting a cash machine with their cash. But there wasn’t that same kind of user hand-holding when they first came online for blind people.

Whitney: Yeah, I’m working with a company on their website. It’s a news site. We suddenly realized that it wasn’t just about saying, “Oh, this is accessible,” or “This is usable,” or “This is a better app,” because if you’re already someone that reads news or gets cash or goes to the baseball game, you’ve found a way to do it already. Maybe it’s not a perfect way.

We have to actually convince you not just that it’s good enough but that it’s better than what you’ve got — that it’s an improvement and that it will actually be easier for you. It’ll improve your life in some way to try this now-improved website.

Lainey: That is so true for the disability community, because people are so used to having to create workarounds. For the talking prescription issues — the things that people do to figure out one rubber band is this prescription and two rubber bands is that — in this day and age there’s just no excuse for that, but people have gotten used to doing it.

Whitney: We’re trying to help people give up complicated, old ways of doing things in favor of nicer, newer ways.

Lainey: Yeah, it takes education on all sides.

Whitney: That is a lovely view for the future, I think, which is the idea that we could actually collaborate instead of just fighting our way through every problem that we come to. I love the idea about learning from how people solve problems that are similar, but in different fields and building on it, because we’re all people.

Lainey: Absolutely. I’ve learned so much listening to you, Whitney, in conferences and presentations and how usability works and how the whole field works. I think I’ve tried to bring some of those learnings into our relationships with our clients. When they’re meeting with the companies and trying to encourage the companies about not to think of accessibility off in some corner, but do you already have usability people, and let’s integrate these issues into something we already have.

Whitney: Yeah. Boy, that sounds like a better win, doesn’t it?

Lainey: Absolutely.

Whitney: I see that we’ve been talking for a while, so I wanted to say thank you so much, Lainey, for joining us. If you folks who are listening are interested in following Lainey’s work or in learning more about structured negotiations, we have links on our website, but you can follow her. She’s @lflegal on Twitter. Her website is lflegal.com.

There are wonderful summaries of the settlements that she’s worked on, but also some great descriptions of how she works and what kind of work she does.

Thanks to all of you for listening in, and also a special thanks to our sponsors, UIE, Rosenfeld Media, and the Paciello Group for making this series happen. Be sure to follow us at a web for everyone at Twitter. That’s @awebforeveryone — all run together as one word. Thanks so much.