Friday, March 7, 2014

Sarah Horton and Whitney Quesenbery — Introducing A Podcast for Everyone

A Podcast for Everyone artwork
In this premiere episode of A Podcast for Everyone, UIE’s Adam Churchill interviews Sarah Horton and Whitney Quesenbery about the book that inspired the podcast, A Web for Everyone. They describe their journey in creating the book and share their perspectives on the importance of accessible user experience. They also provide suggestions for how product teams can use the book to support their practice. At the end, they introduce A Podcast for Everyone, a companion to the book, and give a preview of what they will be talking about in upcoming episodes.
Links mentioned in this podcast
Recorded: February, 2014
[ Subscribe to our podcast via Use iTunes to subscribe to UIE's RSS feed. ←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]

Full Transcript.

Adam Churchill: Hello, everyone. Welcome to the first in a new series of recordings we’re calling “A Podcast for Everyone.” The concept for this podcast comes from Sarah Horton and Whitney Quesenbery, co-authors of “A Web for Everyone,” their new book from Rosenfeld Media. Whether you’re in charge of the user experience, development, or strategy for a website, “A Web for Everyone” is sure to help you make the site accessible without sacrificing design or innovation. I’m Adam Churchill, your host for this companion podcast.
A bit about our authors. Sarah Horton is director of accessible user experience and design for The Paciello Group. She works with companies and product teams to create born accessible digital products and services that work well for everyone. She’s also the author of “Access by Design” and co-author of “Web Style Guide” with Patrick Lynch.
Whitney Quesenbery combines an obsession to communicate clearly with her goal of bringing user research insights to designing products where people matter. Her previous books, “Storytelling for User Experience” and “Global UX,” helped practitioners keep users in mind throughout the creative process. She’s the co-director of the Center for Civic Design.
We thought it made some sense to open the podcast series with the authors talking a bit about what they learned putting this book together, the journey of people who will read it, and the plans we have in the works for future podcasts in this series. Welcome, Sarah. Welcome, Whitney.
Whitney Quesenbery: Hi, Adam.
Sarah Horton: Hi, Adam.
Adam: Accessibility. It’s a huge topic. Can you talk a bit about how you organized it for the book?
Sarah: Sure. We started off our conversations right away talking about organizing the accessibility topics around guidelines, because we personally are very much in favor of working around guidelines and principles — so much so, actually, that early on in our calls, we would have “getting to know you” calls because Whitney and I knew of each other but didn’t know each other well. We would talk through our different ideas for the book.
On one of the calls, we had this great moment where — they were video calls — I was talking about a particular book that I’m very fond of called the “Universal Principles of Design.” I was saying, “I really want to write a book like this. It lays things out so clearly, it’s so obvious, and there are these great illustrations.”
Whitney was like, “Wait, wait, wait, wait!” It was a video chat. Suddenly, she ran off screen, and I’m sitting there going, “Where did she go?” She comes back and she has her copy of that book held in her hands. From that moment on, I feel like we really hit a great synergy around this notion of guidelines as guiding the discussion.
We also wanted to talk a lot about people and have these guidelines come to life by bringing people into the discussion, so Whitney did a lot of work preparing the personas for the book. Maybe you should speak about that, Whitney.
Whitney: Sure. I come from a theater background, so the idea of making characters is pretty easy for me. Also, I think personas add something that’s often missing in discussions about accessibility, which is the people and their lives.
We often think about designing for someone who’s blind or designing for someone who’s deaf, but we don’t think about designing for Jacob. He’s a paralegal, he’s an equipment geek, he loves new tools, and, by the way, he happens to be blind. Blind is the last thing about him in his mind. It’s not the only thing we should be thinking about.
We should be thinking about everything about the person. Personas are a great way to show that. Now, no set of personas can represent the entire universe of people. There are many, many different variations of human beings in the word. But we picked eight of them that we thought represented the range of design considerations that you need to think about when you’re thinking about designing for a broad range of people.
They’re in the book. They’re also on the website. They helped us focus on who the audience was — not the audience for the book but the audience for design — and we hope that they’ll help other people as well.
Adam: With both your backgrounds, really broad and diverse experience, why accessibility? What was the goal in writing this book, and did that change at all during the process?
Sarah: I’ve been working in interaction design and user experience design for, good lord, a long time. I have been doing accessibility work sort of in parallel; but haven’t brought them together in the way that I think they need to come together. One of our goals in writing the book, particularly with the structure that we were using, is to bring universal design principles and accessibility together as an approach to moving forward with building accessible designs.
Universal design is an approach to design that takes into account the needs of everyone in making design decisions. It’s a very attractive way as a designer to look at accessibility so that you’re not thinking about accommodating people who are blind or accommodating people who have mobility issues, but rather building a product, a space, a park or a potato peeler that is going to be usable by everyone.
As a designer, that approach to accessibility is very attractive because it involves elegant design solutions as opposed to accommodations.
Adam: Whitney, how about for you?
Whitney: I’m probably pretty typical of a lot of people working in Web design and user experience. I thought accessibility was good. Of course we should do it! It seems like a generally good thing to do. But it wasn’t anything I really paid attention to.
What got me engaged in it was the work I’ve done around elections and ballot design. I started hearing people pit the needs of voters with disabilities against, say, security needs as though they were in opposition instead of saying, “We are bright, clever, innovative people. We can do great work that meets both technical requirements and human requirements.”
I don’t think this is that different than the battles that the early usability pioneers had. To say, “Look, it’s great that these computers exist, but let’s make them work for humans.”
The other thing that I see these days in UX is a really deep well of a desire to do good, as a designer to make things that change the world in positive ways. Some of us occasionally get to work on big projects. A lot of our work is routine.
One of the nice things about the way we’ve approached accessibility is that we’ve said accessibility is part of user experience. If you are thinking about people as you make design decisions, then you’re just doing design, but you’re doing it for a broader range of people. You’re doing it for more people.
Just like we think about diversity of devices these days — a laptop screen, a big computer screen, a tablet, a small screen, that’s one dimension of diversity — accessibility is really about how we interact. A screen reader, a mouse, a keyboard, or a specialized keyboard is another dimension of diversity.
Including that in our design work from the beginning rather than saying, “I finished my design. Now let’s sit down and make it accessible,” what Sarah was calling accommodation, where we layer it on afterwards. I’m trying to figure out how to help people think about this stuff from the beginning.
Adam: You’ve created what you call the accessible UX principles and guidelines. What is that and why is it important?
Whitney: Sarah was talking earlier about how we both really like the idea of principles and guidelines. I think it’s because principles are a way of thinking. They’re a starting point for how you think about it.
Too often we think about both usability and accessibility as checklists. “We have to do this, we have to do that. Let’s check off the things.” Trying to shift that to think about user experience principles that broaden out to be accessible. Again, it’s about designing it in and about changing the way we think about design rather than just giving us yet another checklist.
Adam: Sarah, tell us why “accessible UX”? Why is that the name?
Sarah: When we started the book, we had planned to map accessibility to the universal design principles. That’s what we had proposed, and that was our plan going out the door. As we worked on the book, it morphed into something other than what I think either of us expected at the start.
Because we were working with the universal design principles as well as the Web Content Accessibility Guidelines, principles, and success criteria, we ended up doing a lot of mapping, reshaping and rethinking of these existing guidelines and principles into something new. In a sense, we reshaped them such that they became a new set of principles and guidelines, which we’re calling the Accessible UX principles and guidelines.
It was a very organic process that, I think, surprised both of us a bit at the end, because we hadn’t really initiated the project thinking that we would end up with a new road map and a new way of looking at accessibility within the context of user experience.
Whitney: That’s right, Sarah. I love the principles of universal design, but they’re really designed for architecture. They started out thinking about buildings, things like ATMs on the side of buildings, physical spaces.
Digital spaces are different. There’s a lot of overlap between surface design, physical design, and digital design, but we think about them a little bit differently. We wanted to make sure that what we were creating was something that would fit into the process of how digital products are created.
Adam: Whitney, can you talk a bit about the big question of who’s responsible for accessibility?
Whitney: Yeah, that’s a good one. The answer is everyone. Of course, that’s our answer to everything — it’s a Web for everyone, and everyone is responsible.
We thought about the big areas. There’s that up-front research and design component, planning what it’s going to be. There’s content, figuring out how it’s going to work. You might add interaction to that. There are the developers.
Those are hard to separate in digital products. If you design something that’s hard to build accessibly, then you end up with something that’s kludgy. If you build something in a way that doesn’t express the design well, you end up with something that’s kludgy.
It’s about making sure that everyone is part of the process all throughout the process as opposed to just coming in and doing their little piece.
Let me give you an example from research. You might think that user research is pretty usual. “We’re going to find people in our audience. We’re going to use one of the many, many techniques in our toolbox to investigate them.”
But to make that into accessible UX, you can ask the question, who’s included in the research? Are we reaching out to include the voices and the needs of people with disabilities, older adults, or children? Are we only thinking about people who are “like us,” or have we reached out beyond that? Maybe to people who are bilingual or who happen to be getting old and their eyes aren’t as good as they used to be. When they’re included in the research, then their voices are included in our design process.
When we start thinking about teams, then it’s a whole bigger question. It’s not just one discipline. Sarah, you’ve done a lot of work helping teams learn how to build accessibility into their overall process. Maybe you could talk about that a little bit.
Sarah: That’s definitely an important aspect of this. The days are gone where you had one person doing everything from soup to nuts. Now we’re working on these interdisciplinary teams with different people responsible for different aspects of a project.
One thing that was very important to us in the book was to make sure that everyone involved in the product development team understood how the decisions that they are making affect someone else’s ability to build and make good decisions that are going to be accessible and provide an accessible user experience.
That was a very important aspect in the book, and one thing that, moving forward, if we’re actually going to build products with built-in accessibility and born-accessible products, everyone has to know how the work that they are doing is going to affect the next person involved in the product.
For example, if you’re building a layout or a design that’s going to be difficult for the developers to code in an accessible way, then you need to understand those constraints and build a design that is going to be aided by accessible coding practices.
Adam: We know that lots of teams are being faced with this challenge. They’ve never thought about accessibility before. All of a sudden, for what ever reason, they’re being challenged to make their sites and their applications accessible. Sarah, where do they start, and what are some things that they can do that will have the biggest impact immediately?
Sarah: That’s a really good question, Adam. The one thing I would say is that there are a lot of things that can be done at the code level to make a website or application have technical accessibility in the sense that all of the information that’s needed to make an interface functional and usable, a lot of that takes place in the code of a page.
If a team were to get started, I would suggest making as many fixes to the current implementation of the product to make sure that that underlying code does provide the information necessary.
Often, design related adjustments are much harder to make, because there’s a lot more that goes into that. At least in the work we’re doing, whenever we’re suggesting that a team rethink an approach to a design or an interaction, those changes are harder to make and take longer. There are more stakeholders involved.
There may have been a lot of usability testing that had been done for that particular implementation of a design. Those are harder to make. But the decisions about the code? Those you can go ahead and implement, and only have a positive effect on all users.
Adam: Whitney, what about when your clients turn to you? Anything additional that you offer?
Whitney: I want to second everything that Sarah said but add something else, which is that we often we often forget about content — the stuff in the middle of the page that we came to the site for, whether that’s a product catalog or information. There’s a lot we can do with that. It’s harder to change and fix maybe in a built site, a site that’s already existing.
Beginning to think about content. This stuff is simple. It’s using headings purely. A heading helps you find your way through the code. It’s the landmarks on the page. It’s making sure that the style sheet presents those headings well, they’ve got good colors.
If we think about headings, if we think about alternative text for images, and we think about making forms accessible, those get you a long way into fixing the content, whether you’re going back and cleaning up old content or starting again with new content.
That often feels more daunting. Many organizations have many different people writing information. It feels like you have to get a large team going. But that work is important. Even things like simplifying languages or putting in bullets makes a huge different to people who don’t read very well or are reading on a tiny screen. They make it easier for people to use the things you put out on their site for them to use.
Adam: “A Web for Everyone,” a fantastic resource for design teams. Sarah, can you talk a bit about how design teams are using the book in their work?
Sarah: One way that people are using the book and that teams are using the book relates to what I was talking about earlier in terms of having everyone understand how the project works together, and how decisions are made collectively and how they impact one another. That’s an important facet of the book because it highlights everyone’s role at the different points in the development lifecycle.
Another way that the book is being used. Also, we have resources right now on the website. The personas are among them. I recommend people have a look at those right away because those are personas that you can go ahead and start using to bring people with disabilities into user research discussions.
The personas were mainly done by Whitney. I have to do kudos to Whitney because I think they’re one of the strongest components in the book. The illustrator, Tom Biby, did a fantastic job working with us to get them to be the type of personas that we wanted to represent in the book and on the website.
The personas are already there for use. I recommend that folks have a look at them, download them, and start using them in your work.
Whitney: We tried to pack it full of examples and the kinds of things you think about at each different aspect of design. Even though it’s principles and guidelines, they’re meant to be inspirational. They’re meant to be things that will help you think about how to do your design better.
Adam: I have to ask this question, because it seems to come up at least here in the United States. There’s talk of compliance. As guidelines, should you follow 508 or WCAG?
Whitney: Let me explain what those are. 508 is our shorthand name for the US federal requirements for accessibility, and WCAG stands for the Web Content Accessibility Guidelines from the W3C, which is also a set of requirements and guidelines for accessibility.
The answer is that we think you can actually focus on WCAG. The federal government is about to update the 508 regulations. What they’ve announced they’re going to do, they’re going to say that if you follow WCAG, you will be following 508. We’re beginning to see these two important legal requirements converging.
The other thing that we did in the book was we have a crosswalk between the WCAG guidelines and principles and our guidelines and principles so that you can see how the things fit together. For example, there are requirements in WCAG that affect both the visual design and the content design. We’ve got them in both chapters. You can see how two teams, for instance, might tend to coordinate their work in order to meet those requirements.
Adam: At the beginning, we teased all the great plans we have for this podcast. Can you tell our audience what they can look forward to?
Whitney: First of all, you’ll hear a lot less of us and a lot more of other people.
Sarah hasn’t mentioned something in the book that is also important. We have interviews with people who were influential in our thinking. We want to continue that process.
There are a lot of people working in this field doing awesome work, often developing interesting tools and techniques that we can use. We’d like to introduce them to you. We’ll be bringing them in and picking their brains for practical, useful things you can put to use in your work.
Adam: Very cool. It’s super exciting. We’re looking forward to hearing what you broadcast with us in the near future.
Thanks, everyone. Thanks to our audience for listening in, and a special thanks to our sponsors, UIE, Rosenfeld Media, and The Paciello Group, for making the series happen.
Be sure to follow @AWebForEveryone on Twitter for information about future “A Podcast for Everyone” plans and availability. Goodbye for now!
via:http://www.uie.com/brainsparks/2014/03/06/sarah-horton-and-whitney-quesenbery-introducing-a-podcast-for-everyone/ 
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)