A Web for Everyone Blog

Designing Accessible User Experiences

Posts written by Sarah Horton & Whitney Quesenbery

  • CVAA with Larry Goldberg

    Posted on

    A Podcast for Everyone coverIf you work in media broadcasting or telecommunications you have probably heard of the U.S. legislation called CVAA, shorthand for the 21st Century Communications and Video Accessibility Act. This law, signed by President Obama in October 2010, seeks to ensure that accessibility requirements keep pace with advances in communication technologies.

    Like most legal documents, CVAA is difficult to decipher. It’s difficult to extract the key points, and determine what actions we need to take.

    Photo of Larry GoldbergLucky for us, Larry Goldberg is here to help. Larry was co-chair of the Video Programming Accessibility Advisory Committee (VPAAC), which provided reports that helped shape the legislation. He joins Sarah Horton for this episode of A Podcast for Everyone to answer key questions, including:

    • How did CVAA get started and what is it for?
    • What do web professionals need to know about CVAA?
    • Are there standards we should be looking to for guidance on CVAA compliance?

    Transcript available · Download file (mp3, duration: 24:33, 14.4MB)

    Larry Goldberg is Director of Community Engagement at WGBH, the company that pioneered captioned television in 1972. He has been with WGBH since 1985, for many years of which as Director of the Carl and Ruth Shapiro Family National Center for Accessible Media, and has been a leader in advancing accessible media at WGBH and worldwide.

    Resources mentioned in this podcast

    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)


    Sarah Horton: Hi, I’m Sarah Horton, and I’m coauthor with Whitney Quesenbery of “A Web For Everyone,” from Rosenfeld Media. I’m here today with Larry Goldberg, who is Director of Community Engagement at WGBH, the company that pioneered captioned television in 1972.

    Larry has been at WGBH since 1985, and has been a leader in advancing accessible media at WGBH and worldwide. We’re here to learn from Larry about the 21st Century Video Accessibility Act or CVAA.

    Larry was closely involved in getting this legislation passed and we would like to know more about what it is, and how it affects people who make websites and applications.

    Hi, Larry, thanks so much for joining us.

    Larry Goldberg: Great to join you Sarah.

    Sarah: Can you tell us briefly about the origins of CVAA, how it got started, what problems it was meant to address?

    Larry: CVAA came out of a roadblock that the blind community was facing back in the early 2000s. We had found ways to achieve requirements for closed captioning of television for the deaf community, but the blind community wanted to see more video description.

    The Telecommunications Act that was passed in 1996, where captioning was required, video description was left somewhat open, but the FCC at that time decided they had a mandate to require video description, limited amount, only on certain channels.

    They went ahead and recorded it, but the communications industry took the FCC to court and won. The video description mandate was overturned, and the only solution was to go back to Congress, and try to get a new law passed that would actually give the FCC jurisdiction to require video description.

    At the same time, many others in the disability community were concerned that digital technology was changing everything, that there were new forms of media coming out, new ways of using telephony, that weren’t really covered by existing laws and regulations, so a combination of these pressures came together to craft a new law that became the 21st Century Communications and Video Accessibility Act.

    Sarah: Sounds like quite a journey. Our audience is mainly people who make websites and apps, sort of strategy people, designers, people who code, people responsible for content. What do they need to know about CVAA in order to do their work?

    Larry: Well, there are two basic sections of the CVAA. Title One covers mostly telephony, including smart phones and mobile devices used for advanced communication services, and Title Two focuses on online media and Internet communication.

    For anyone who is developing mobile technology in tablets or smartphones where one can surf the web, receive email, get text messages, all of that must be made accessible now. By being made accessible, we traditionally are focusing on the needs of people who are blind or visually impaired.

    The user-interface needs to be navigable by audio and the content needs to be accessible, usually by transforming it into speech or into braille tactile versions. So, from the beginning of the design on a mobile device, it is now required that mobile browsers have to be usable by people who can’t see.

    The other advanced communication services, you need to be able to email on a mobile device, if you can’t see, text services, and various other related activities on both, mobile devices and really any kind of new digital technology that’s giving you access to these kinds of what’s called “ACS,” advanced communication services.

    Title Two is a very interesting different area, and that is where the requirement for video description on television came into play. There are now nine channels, the major four broadcast channels and five top cable channels now have to provide 50 hours per quarter of video description on their TV channels.

    On the Internet, closed captioning that has existed in broadcast, if it’s now carried on the Internet, needs to retain those captions. It’s important to note that, that means the video players need to be able to support display of captions, but it’s also important to note that this only covers previously captioned material that has been aired on television.

    It is not user generated content, it is not the entire world of YouTube, it really is those channels that are carrying previously broadcast content.

    Sarah: What is the status of all of this at this point in time?

    Larry: Well, the bill was signed into law in 2010, and immediately the FCC got to work issuing a long series of proposed rulemakings, law comment periods went into effect and then the laws began to take effect as well.

    Captioning is now required on the Internet under those parameters. Video description is required on TV. Smart phones presently have to be accessible, and the next round of accessibility is a really fascinating one. It is the world of over-the-top devices, set-top boxes for cable systems, smart TVs will soon, in two years, have to be navigable by persons who can’t see.

    I know many companies are working quite hard right now to make their user interface designs accessible without vision.

    Sarah: Those are like the menu systems and things like that?

    Larry: The menus, the programming grid, basically command and control.

    Sarah: I see.

    Larry: What’s interesting is that some companies are actually providing voice command of these user interfaces. That’s not required, but it’s a nice combination of audio feedback and voice input. You’ll begin seeing some of that come out in technologies that exist.

    In fact, there’s already navigable user interfaces on an Apple TV box. It has built-in VoiceOver, which is the screen reader software. You can navigate, turn on captions or subtitles on programming you’re watching from iTunes on an Apple TV.

    Sarah: This sounds like another of those advances for accessibility that everyone’s going to enjoy.

    Larry: I think it’s going to be a great time, I think engineers, people who are developers, who read your book could have a lot of fun with this because it’s a whole new way of thinking about good user interface design. The notion that the mouse, the keyboard, and the display monitor, we’ve been stuck with that for a long time now.

    For many years, people have been thinking that there must be a new paradigm. This need of this particular community is really now driving it. What’s interesting is the law and the FCC are not mandating a particular way to make your user interface accessible.

    It’s really up to you. We’re going to see all kinds of ways of controlling your online experience, and already there are many apps that can control a set-top box, and the apps are accessible.

    You can download the AT&T U-verse app, the Verizon FiOS app, or the Comcast app and use your smart phone to control your TV by voice and in an accessible app. In many ways, the emergence of small devices and this need for making accessible user interfaces are coming together right at the right time.

    Sarah: Sounds like it. If I’m someone building one of these apps that’s running on one of these devices and I need to comply with CVAA, how do I make sure that I’m complaint? Is there a standard that I can measure against?

    Larry: There are functional requirements and there are best practices that have been derived from the world of computer-based software and accessibility. We’ve built a lot on the basis of the work the W3C has done with their Web Content Accessibility Guidelines, their User Agent Guidelines.

    You should find all of that at w3c.org, but we also have the federal regulation, Section 508, and many of those will give you the basic equivalents or requirements on the functionality. There is not an explicit standard for a smart device to be accessible via audio.

    There’s no ISO standard for instance, but there are significant amounts of existing technologies and the functional requirements are fairly clear.

    Sarah: One thing that is really helpful for developers, designers, and content people who are trying to build websites and applications for accessibility is having those guidelines to measure against. It’s just a very straightforward way to try to meet accessibility requirements.

    You’ve mentioned that there are guidelines that are good as companions, but will there ever be a standard in place that would be used by CVAA to test for compliance, something like WCAG or 508.

    Larry: The way the CVAA was written and negotiated really shaped how the technology will roll out and how compliance will roll out. It’s very much a bill that was negotiated by industry with consumers. Both sides won some aspects, some lost. It was the telephone industry and the TV industry that was subject to these requirements.

    They argue pretty strongly that they did not want to have the FCC mandate a particular standard or a particular way of achieving accessibility, especially when they were talking about things like smart TVs that were rolling out when the law was written.

    They didn’t really exist then, or smart phones and the kind of capabilities, so there was a real hesitation to have the law or the FCC explicitly name a particular standard.

    They will make reference to the functional equivalence. They will make reference to the kind of things that you will see in the W3C Web Accessibility Initiative or Section 508, but the law really said that manufacturers have the leeway to develop their accessibility according to their own best attempts at achieving the end goal of making their technology accessible.

    If any of the industry standards groups gets together and creates a voluntary standard to achieve, for instance, a talking electronic program guide, they could do that, but it’s actually an area where these companies compete with each other. They compete very strongly on who’s got the best EPG.

    In some ways, this is a competitive issue. At this point it’s unlikely that you will see an explicit standard for how to command and control a TV set or a cable box. As I mentioned before, some cable companies might want to proliferate small devices with apps on them, and not build speech into their set-top box, but actually have it external, they’re allowed to do that.

    The industry was very clear that the technology is emerging and changing, and they weren’t prepared to have a standard imposed on them, which tends to be the way they go.

    There will be industry groups that, for reasons of interoperability, for reasons of consumer friendliness, might get together and say, “Let’s all follow this one particular route to accessibility,” but most of the time, it is pretty much every device will have its own way of achieving these requirements.

    Sarah: That’s interesting. It sounds like an opportunity and a challenge at the same time, but there are the performance objectives. Can you talk a bit about those, what those are, and how those play a part?

    Larry: Yes, they’re different for whichever portion of the law we’re talking about. For instance, we’ve talked about a mobile device, a tablet or a phone.

    The functional equivalent is basically usable without sight, so you start off with the notion that, if you’ve got a touchscreen or you’ve got soft buttons, they need to be programmed so that they can be discovered and used by a person who can’t see your device. It really starts there.

    How you navigate to those controls again will be a usability test as much as an accessibility. The notion of usable accessibility is an important aspect because there are devices, particularly in the Android world and some of the other platforms where, yes, you can make them accessible to a blind person.

    They can do it, but it would be quite a struggle, with special software that has to be downloaded, special configuration you have to do, and that’s not necessarily the best way to do it. The built-in inherent accessibility at startup, as set up, is really the way to go.

    From the box, you open it up, you start it up, it should present you with a talking user interface right away, it starts there, and then all the set up and all the way of setting up your device.

    That could be done on a website and then transferred to your device, that would be fine. A very accessible website, which is perhaps a common practice today, could certainly be a way of setting up a new device, but that’s where the frustration begins.

    The kind of things, you need to be able to move from one screen to another, you need to be able to enter characters, you need to have those characters echoed back to you, you need to be able to switch between modes, caller ID needs to be audible, your battery level needs to be audible.

    All of those aspects that you might take for granted if you’re sighted are things that need to be spoken out loud, and hopefully, presented to the user in a way that is readily achievable.

    That’s really the challenge for a good designer, to really come up with ways that make it easy, with gestures, with buttons, hard buttons, soft buttons, that really lead the person to a comfortable way of navigating.

    I don’t know that anyone’s come up with that best way yet. Of course, we all look to Apple, how they’ve done with the iPhone VoiceOver. There may be better ways they do it and others will.

    Sarah: It seems like this is a good point to talk about one of the things that I like about CVAA, which is this notion about considering performances objectives early in the design process that’s written into some of those lengthy tomes that I have dug my way through. I wondered if you could talk a little bit about that.

    What I understand is that one of the requirements for CVAA is this notion that you would be considering those performance objectives of, How is this product usable without sight, right at the beginning of the process versus at the end of the process, looking at something you’ve built and saying, “OK, how do I make this usable without sight?”

    I think that’s a brilliant inclusion. I would love to hear about how that got there.

    Larry: You would think that that is common sense. It is less expensive to build it in from beginning, very difficult to retrofit a product when it’s about to go out the door. It is quite a groundbreaking aspect of the CVAA, where they not only require that companies take into account the accessibility of their devices, their software, their hardware at the design phase, and certify that they’re doing that.

    They have to take into account the opinions and expertise of the consumer community. It’s required, and must be certified, that you have reached out to the disability community early in your design process to get their input.

    I’m not a lawyer or a legislator, but I don’t know of other legislation that has required what you and I might consider pure common sense. Of course, you ask your users how their technology is working, but as we’re into the law, a document must be signed off by the responsible party annually to show that you have considered accessibility in your design and you have reached out to the user community and experts in the field, so pretty impressive.

    Sarah: I love that part. Getting people to think about accessibility right from the start is a big part of the book, A Web For Everyone, we recognize that it’s a real challenge for many organizations to actually make that change because it is a change in a lot of cases.

    Do you see any opportunities coming out of CVAA that might help make a case for that kind of change, so that people move from being reactive to proactive about accessibility?

    Larry: For those of us who have been in this field for many years, toiling and trying to raise awareness, and convince people that it’s the right thing to do. We’re beginning to actually see a change in the mindset, a heightened awareness, from many of the major companies.

    Perhaps some of the smaller companies, some of the smaller app developers are still a bit confused about what they’re supposed to do, but I have seen the pervasiveness among the major carriers of equipment, the hardware and software manufacturers, that they need to follow these.

    They’ve hired staff, they’ve reached out to consultants, and organizations that are experts in this. There’s now even an International Association of Accessibility Professionals being formed, and we’ll see how that goes.

    To really professionalize the standard, the way privacy originally emerged, and security, which today is a key function for anyone dealing with technology. You would absolutely put a lot of resources into ensuring privacy of your technology and security.

    Accessibility will eventually match that as well and that you would never consider putting out a product where you haven’t at least considered the question, as how accessible this is to people with varying disabilities.

    My hope is and a lot of professionals in the field have seen that what has been a growing grassroots movement might finally become embedded in common practice.

    Sarah: In terms of looking forward, what do we have to look forward to about media accessibility in general?

    Larry: Well, we’ve had a great sea change in the world of deliverable media. We’re no longer watching our TVs though the latest high-def TV sets are pretty astounding.

    Captioning is pretty pervasive there, works in significant number of cases, almost 100 percent of television is now captioned with rare exceptions. Now we’re watching television and videos on our devices, and the new law actually carries a lot of captions over to those devices, and it’s working remarkably well.

    You could take your tablet, your iPhone, your iPad, your Android tablet and download the Hulu, the Netflix, the iTunes apps, and captions will work beautifully, very visible, where there’s a requirement now where the user can adjust the size, the font, the color. It works well.

    That has been one of the greatest successes since the initiation of the CVAA. I have to say that WGBH’s National Center for Accessible Media created this thing called the “Internet Captioning Forum” ten years ago, with the participation of AOL, Google, Yahoo, and Microsoft.

    This is what we’re working towards, it’s working, so we’re proud of that.

    Video description available, 450 hours per quarter of video description on television. We are still encountering a lot of problems with delivery of description, getting it from broadcast to the cable outlet to your TV set due to some legacy standards in technology. It’s great to see the pervasiveness of description on commercial and public television too.

    I think the new challenges are getting that description onto the web. There is no description on any of the streaming media sites. You won’t find it yet though we hear that some initial inquiries that have begun. It’s not required under the CVAA, but I know a lot of people who are blind and visually impaired have really been pushing hard for description online.

    After that it will be a question of what’s next in the media. Will you be looking at other kinds of devices, Google Glass, there’s no reason why that couldn’t be an accessible and usable device for people with disabilities and to display enhancements of media, captions, descriptions, other languages through those devices.

    The whole world of second and third screens will be a very interesting way of delivering captions and descriptions to personal viewing experience. You’re gathered with your family, you’re all watching TV. In my family, my wife and child do not like captions. I need captions, and of course, it’s my living.

    What about turning the captions on on my iPhone. I’ll watch them privately and everyone else will watch the uncaptioned version. That is actually quite doable today. No one’s implemented it yet. Give me a call anyone who wants to try it, same thing for description.

    It’s already been done in movie theaters with private viewing devices and there’s no reason it couldn’t be done on digital television. Of course, the web gives you full control over your own personal experience.

    The concept is personalized video, shape it to the way you like it, to the way it works for you, including even pausing to explain what’s going on if you have a cognitive disability. All those are quite doable today with the web architecture we have and the way media is being served up.

    Sarah: That sounds really great. Thank you so much Larry. This has been Larry Goldberg talking to us about CVAA and what it means to you and me, as we work toward building a web for everyone.

    Many thanks to you for listening and to our sponsors, UIE, Rosenfeld Media, and The Paciello Group for making this podcast possible.

    Follow us at “A Web for Everyone” on Twitter, that’s @AWebforEveryone.

    Until next time…

    Accessible Media: An interview with Larry Goldberg

    Posted on

    An edited version of this interview appears in Chapter 9 of A Web for Everyone.

    Photo of LarryLarry Goldberg was Director of the Carl and Ruth Shapiro Family National Center for Access Media (NCAM) at WGBH Boston, one of the most accessibility-aware media companies in the world. He is now Director of Community Engagement. In addition to producing award-winning, captioned, and described television and web programs, WGBH hosts the National Center for Accessible Media, or NCAM, a research and development group focused on ensuring equity in media access. Larry oversees NCAM, where his dedication to developing technologies, policies, and practices to support accessible media has been instrumental in mainstreaming captions and video description and other innovative technologies.

    We asked Larry what we could learn from the process of bringing captioning to television that will help us mainstream accessible media on the web.

    Integrated technology as the tipping point

    Captioned television is everywhere: in bars, airports, gyms—wherever hearing is difficult, and we need to see what is said. But that wasn’t always the case. There was a time when captions were an add-on, delivered using separate technology in the form of a set-top box purchased by deaf and hard-of-hearing television viewers. The tipping point for captions came when the capability for displaying captions was built into standard television sets—by means of an act of Congress. With the technology in place, the challenge became to produce captions for all television programming.

    Getting there wasn’t easy, as Larry can attest, having been around through much of the process. The first step was to dispel the notion that captions were costly and benefitted only a small number of viewers. “You don’t want to forget the primary purpose—that deaf people needed captions—but when it became obvious that captions helped comprehension and late-night television watching, and when the TV production community saw that they could integrate captioning into the production process without a lot of time and expense, they said, ‘Fine, go ahead.’”

    Like captions for television, most web media players can have caption display capacity built in. With Flash and QuickTime and Windows Media, you can add a caption into any video; however, in most cases, captions are not required. In the United States, captioning recently became required under the new 21st Century Communications and Video Accessibility Act (CVAA), but only for previously broadcast video, not for user-generated or web-only video.

    Perhaps the “CC” button on the YouTube player will play a role similar to what built-in captioning technology did for television, by compelling web media producers to provide a caption track in response to viewer expectations.

    Becoming part of the process

    Process integration was key to mainstreaming captions. Captioning services like those at WGBH had to get faster and more efficient, and integrate seamlessly into the media production workflow. “We had to work fast so we didn’t hold up delivery deadlines.” This meant overnight shifts, but also creating better tools so the captioners could work more quickly. It also meant coming up with workflows that would integrate into production. “Once captioning became a line-item in budgets, and an expected check-point in the production flow, it became an accepted way of doing things.” Expectations for captioned television in bars and health clubs also helped.

    When a TV producer who may never have met a deaf person goes to the gym every day and sees captions, they just accept it. Or they look and go, “Hey! Why isn’t that show captioned? There’s an interview on—I want to know what he’s saying!” Or they’re at a bar and there’s a game on, and they say, “What just happened? What’s that call? Hey! Could somebody turn on the captions?” These wider circles of usage certainly help.

    Once people stopped asking the question, “How many people are going to see these captions,” and captioning services became fast and cost-effective, captioning became part of the process of producing and distributing television programs.

    Enhancing media with accessible features

    With web-based digital technology, the broad benefits of accessibility features are even greater than with television. “In the earliest days, even in QuickTime 1.0, the benefits of searchability were fairly obvious,” offering the ability to find key words in a video by searching a synchronized text track. “Captions became a universal design enhancement that was feeding the world of search.”

    There is evidence that the presence of captions increases the attention to and time spent with video. “We believe captions are driving viewership and ‘stickiness.’” And text has myriad benefits over other media when it comes to sharing.

    You put time into creating a video, even if it’s a throwaway, even if it’s only going to be online for half a day. If there’s value to it and you want people to see it, then creating a text enhancement is going to help—for cut-and-paste, for sharing. Sharing video is kind of hard, especially since different devices have different support. But sharing text is pervasive. So if you have a text file of your media, whether it starts as audio or video, it’s much more readily shared. And you can tell people about it in all your social media tools by pulling pieces of text out, posting or tweeting the text, and driving people to your media.

    Some companies are starting to exploit accessibility features for other purposes, such as popping up advertisements based on what is said within a piece of media. “We will see a lot more targeted advertising in video,” Larry predicts.

    Making text from audio

    “It’s the transcribing aspect that takes time,” and speech-to-text software is only partially helpful, such as YouTube’s automatic speech transcription, “which is frequently only partially accurate.” Most media companies outsource transcription and captioning because the expertise needed is not typically part of a media production team. Some, like Netflix, are even now experimenting with crowd-sourcing their caption work. Services like the WGBH Media Access Group make it easy to outsource caption creation, and the prices for transcribing and captioning have come way down. Plus, there’s more to good captions than simply transcribing audio to text.

    High-quality captions are crafted to make the captions more readable. YouTube and other auto-captioning tools won’t do that: things like breaking the sentence in the right place, and removing captions during long pauses. Our captioners do everything in one step: they transcribe, time, place, and add extra stylistic aspects. So far, we have found that using speech transcription as a first step does not save us time because our captioners are trained to do all the enhancements in the first pass.”

    But there are instances when outsourcing may not be necessary. If you start your media production process with a transcript or teleprompter text, it can become the basis for captions. Services like YouTube’s auto-timing work fairly well for synchronizing a prepared and accurate transcript with video.

    Partnering with transcription software

    Speech transcription software can be a help, but only with clear audio. “You can’t just take random, noisy, multi-speaker audio and expect high quality automatic transcription.” But, with care, it’s possible to transcribe, with enough accuracy, a clean recording of clearly spoken audio using speech-to-text software like Dragon Naturally Speaking. As an example, Larry cites the Liberated Learning Consortium, an IBM research project in which professors record lectures using high-quality mics and trained software to produce accessible lecture materials.

    I know we want the tools to shape themselves to us and not us shape ourselves to the tools, but… if you talk a little bit more robotically and you enunciate properly you can actually get a decent transcript using automatic speech recognition tools.

    Adding captioning to the web media production workflow

    As for who should be responsible for integrating captions, Larry suggests it’s all part of post-production—editing the media and digitizing for different platforms. “The people who know video and editing tools get this, ” as adding captions is similar to titling video and adding credits—and adding other forms of metadata.

    Some organizations offer services to their constituencies to support the practice of accessible media. Several California colleges and universities offer an online service that manages the captioning workflow. Faculty submit a lecture recording, for example, and the service manages the transcription, captioning, and publishing, typically outsourcing at least the transcription part of the process. With low-cost transcription services available, the overall cost for the service becomes quite manageable.

    Looking ahead for accessible media

    The research and development aspect of Larry’s NCAM work looks at new technologies, “making sure that everyone can use whatever new, essential, or cool thing that’s coming up that will have an effect on people’s lives—at home, in school, and in the office and community. Can we make sure it’s a level playing field?” The other aspect is finding ways to exploit those technologies for accessibility.

    For example, the HTML5 media architecture offers capabilities for specialized content. “With HTML5, you can link to different types of synchronized streams within the same webpage.” For an instructional video containing information written on a board, the same information could open in a new window as text. Or the information could be inserted into the video as a text track, and viewers could pause the video, listen to the synthesized text, and resume playing the video, making the content accessible to people who were blind or visually impaired.

    Given the demonstrated value-added nature of captions and other accessibility features, Larry predicts that “as more captions come online as part of the new requirements, others not covered by the rules will too begin providing captions because they see the value.”

    Accessible UX presentations at the CSUN 2014 conference

    Posted on

    I spent last week in San Diego at the amazing CSUN Conference on Disabilities, absorbing the presentations and even better hallway conversations. And, I gave three presentations on UX and accessibility.

    It was very encouraging to see how much focus there is on moving beyond checklist compliance and towards making user experiences that are delightful for everyone.

    Many presentations from internal accessibility groups talked about efforts to work more closely with product and UX teams from the start. And when I asked the audience in one session how many of them had run or observed usability testing, most of the hands went up.  Breaking down the silos is a good place to start.

    My three presentations are all on my Slideshare page.

    Accessibility note: You can read the presentation online as a series of images, or download an accessible Powerpoint file. There’s also a transcript of the text in the presentation at the end of the page.

    Where usability meets accessibility

    Jayne Schurick and I looked at the intersection of usability and accessibility in the user experience:

    • How usability problems can be more severe when there are also accessibility barriers.
    • When accessibility problems can amplify usability issues and make them more noticeable.
    • Looking beyond the noise for the problems that have the most impact on the user experience.

    [iframe src=”http://www.slideshare.net/slideshow/embed_code/32521629?rel=0″ width=”427″ height=”356″ frameborder=”0″ marginwidth=”0″ marginheight=”0″ scrolling=”no” style=”border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;” allowfullscreen]

    Need a little usability? What you can learn from usability testing

    Every study starts with a question. This session started by examining the questions that usability testing can answer and then matching them to different approaches and methods. It will help you know what you can (and can’t) learn from working with real people as they try to use a web site or other product.

    [iframe src=”http://www.slideshare.net/slideshow/embed_code/32565930?rel=0″ width=”427″ height=”356″ frameborder=”0″ marginwidth=”0″ marginheight=”0″ scrolling=”no” style=”border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;” allowfullscreen]

    Accessibility as innovation: Creating accessible user experiences

    Accessibility can be a “wicked” problem – one that is difficult to solve because the requirements are incomplete, contradictory, or changing. It’s especially hard to keep advances in technology, standards or regulations, attitudes, work processes, and personal habits all in line.

    But, if we take diverse participation in the design process seriously, we might find that we change the question and end up with even more innovative products.

    [iframe src=”http://www.slideshare.net/slideshow/embed_code/32544532?rel=0″ width=”427″ height=”356″ frameborder=”0″ marginwidth=”0″ marginheight=”0″ scrolling=”no” style=”border:1px solid #CCC; border-width:1px 1px 0; margin-bottom:5px; max-width: 100%;” allowfullscreen]

    Accessibility Easy Checks with Sharron Rush

    Posted on

    A Podcast for Everyone coverIf you’ve just been put in charge of making a site or app works for everyone, the most daunting step might just be the first one. Sure, there are standards, but sometimes they raise more questions than they answer.

    What you need is an easy way to get started. And Easy Checks may be just what you need.

    Transcript available.   Download file (mp3).   Duration: 22:38 (11.4MB)

    Sharron Rush heads the Easy Checks project at the Web Accessibility Initiative. These simple steps help you get an idea of whether a site meets some of the basics for good accessibility, without any special technology or tools. She joins Whitney Quesenbery for this episode of A Podcast for Everyone to answer some of these questions.

    • What are the Easy Checks, and why are they needed?
    • Can anyone use the Easy Checks? Is there special equipment needed?
    • What’s the best way for a project team to get started with accessibility?
    • How do usability and accessibility fit together when you are evaluating a web site?

    Photo of Sharron Rush

    Sharron Rush has been an advocate, a learner, and a teacher of accessible technology for 15 years. She is Executive Director of Knowbility and an Invited Expert to the W3C Web Accessibility Initiative where she co-chairs the Education and Outreach Working Group, which wrote the Easy Checks.

    Resources mentioned in this podcast

    A Podcast for Everyone is brought to you by UIERosenfeld MediaThe Paciello Group, and O’Reilly.

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


    Whitney Quesenbery: Hi everyone. Welcome to this episode of “A Podcast for Everyone.”

    Whether you are in charge of the user experience, the development or the strategy for a website, our goal is to help you make your site accessible, without sacrificing design or innovation. I’m Whitney Quesenbery. I’m the co-author with Sarah Horton of a new book from Rosenfeld Media, “A Web for Everyone.”

    Today, I’m talking to the extraordinary Sharron Rush. Sharron is the Director of Knowbility, home to projects like the Accessibility Internet Rally, AccessWorks, they do projects to help companies make their sites accessible, and they run the annual AccessU conference. We’ll talk about that at the end.

    She’s also a part of the Education and Outreach group at the web accessibility initiative at the WC3. She joins us today to talk about Easy Checks, and how they can help you get your site on the road to part of being a web for everyone. Welcome, Sharon.

    Sharron Rush: Thanks Whitney. It’s great to be here.

    Whitney: Great to have you. Before we dive in, I want to just mention the URL, so we make sure we get it in the tape, that URL for Easy Checks is www.w3.org/WAI/eval/preliminary, and the full title of this page is “Easy Checks – A First Review of Web Accessibility.” You know, Sharon, that sounds almost practical, and this is from a standards organization.

    Sharron: [laughs] Are you surprised? You sound like you’re very surprised at that. That was our goal, in fact. We wanted something that was practical, and that really truly was easy.

    Whitney: Yes. It sounds like we all know what we need to do, what we don’t know is where to start. It’s great to see some material out there that will help. Tell me about who created the Easy Checks and how you worked on it.

    Sharron: You mentioned a minute ago that I was part of the W3C’s Education and Outreach Working Group for the Web Accessibility Initiative. That’s a group of volunteers and invited experts who take all of those fabulous very technical documents that are developed around HTML5, CSS, and all the accessibility standards, the Web Content Accessibility Guidelines, all of those things.

    What we try to do is digest them, and do outreach that will help lay people use them, understand what they are, and be able to really use them in a practical way. One of the things that we kept hearing was that…I just feel overwhelmed when I come to the W3C. I’m interested in accessibility, but I really can’t even begin to know how to apply those Web Content Accessibility Guidelines (WCAG). What we decided was, why don’t we make a really easy way for people who aren’t technical, who don’t necessarily have automated testing tools or any of that, but just to get an idea of what does accessibility mean and how do I know if I’m even in the Ballpark.

    Whitney: Cool. So, you see why I was a little surprised about something called the easy connectable standards, but it’s really great to hear that kind of project. I have a really big question with just how did you decide what you should include. I assume that Easy Check are things that are really important, but how did you decide what to include?

    Sharron: That is a good question. That part wasn’t an easy thing to do because there are some things that create great barriers for accessibility but that aren’t really easy to check. We start by developing a framework that says, here are the requirements in order to be an Easy Check. It has to be all these things, but paramount was, it has to be easy to make a decision, it has to be easy to make a call on whether or not it passes or fails.

    We weren’t always successful, and I think you’ll find, if you look at the Easy Checks, that we say, “Here’s what you can do. You can take this step and you can do this, but, even if you get a green light on this, you’ll probably want to go further. If you get a red light on this, at least you know that you have a problem. It’s not all black and white either, through the Easy Checks.

    Whitney: Two things. They have to be things that we could do, like someone like me who’s not very technical could just look at the site and be able to pretty easily tell…maybe not if it met the guidelines, but it certainly could tell if it fails.

    Sharron: That is correct.

    Whitney: Also, these are things that are important to get started with accessibility, so if it fails these, then maybe some of the deeper things don’t matter them much because you haven’t even gotten the door open.

    Sharron: That is exactly correct, too.

    Whitney: So, let’s pick one of them apart, and talk about how it works and why it’s important. The first one on the list is ‘Page Title.’ It seems pretty basic, doesn’t it?

    Sharron: One of the reasons that we put that as the first one is because it’s relatively easy to check, and it’s the first thing that you often encounter when you come to a website. We thought, “We’ll start with the page title. Does it have a page title, does it not”? And also relatively easy to understand the importance of, because people who are listening to the Web need that for orientation, to understand where they are, “Am I on the right page? Am I where I thought I was going to be”? If the page title is announced and it’s clear, and gives that information, then they have success.

    Whitney: Are you talking about the title that’s up in the title bar or the title that might be a big display title on the page.

    Sharron: The title that is shown in the window title bar.

    Whitney: If you’re listening to the Web with a screen reader that gets read to you as you enter a page?

    Sharron: It does, yes. That’s the first thing that you hear.

    Whitney: So, you know that if you clicked on a link, you’ve got to the place you wanted it to be.

    Sharron: That is correct.

    Whitney: The second one is ‘Headings.’ Again, that doesn’t sound like a really technical thing.

    Sharron: No. Checking for headings, but now what you have to do there is to make sure that you’re not just looking at the page to see if there’s big, bold text. In this case, you have to actually do a little bit more investigation and see, has it been marked up as a heading? So, before people get really scared about, “My Gosh! I have to know code,” we do also introduce in the Easy Checks some easy tools that you can just put in your browser and use to help you find those things.

    Whitney: Cool. So, I don’t have to have a web editor or a technical development environment.

    Sharron: Right. And you don’t have to open a source code and start digging through the source code. You can download some of these tools and, that’s one of the first things we take you through, how do you chose the tools that will work, that will be easy to use, and the results of which you can understand also very easily.

    Whitney: This sounds like you’re really addressing something that I hear a lot when I talk to project teams, which is that they say, “We want to do it but the whole thing seems daunting,” and they don’t know where to start. You’ve told us that someone who isn’t that technical could use Easy Checks. Here’s my real question, if you fixed the things that were in Easy Checks…let’s say you found out that you didn’t have good headings or good page titles and you actually fixed them, how much of a difference does that make?

    Sharron: It makes a huge difference because those are the ways that people even orient to the information on the page, to begin with. You used the phrase earlier about opening the door. You definitely are, then, opening the door so that people know where they are, know how to get among the different sections, where they’ve landed, and they just have a really useful way to interact with the information that they’ve come upon.

    Whitney: I noticed that the page actually breaks this into a couple of parts. There’s this page title, and then there are some things that are really about the text. I don’t think we often think about the content of the page when we think about accessibility, and a lot of people jump right into worrying about, “Is it Java script, and does it do things in complicated ways that are easy”? This sounds like it’s stuff that would apply to even a very basic website.

    Sharron: Yes, Absolutely. That was our goal, to make sure that anyone…and also regardless of the tools, if you are using WordPress, Drupal or some content management system, these Easy Checks still apply and you can use them really sequentially or you can jump around and see what…”Well, I just added some multimedia. I just want to check that out.”

    Whitney: If you’ve just added something new…

    Sharron: If you’ve just added something new to your site and you just want to check on that particular part of it…

    Whitney: You said something really interesting which is, this isn’t a sequence, so it’s not a process, it’s a series of checks that you can use. Tell me how you would decide when to check something.

    Sharron: Certainly, you’re welcome to…and people have used this sequentially, just gone one ride after the other and done all the checks. In some cases you may have just added a new feature, and you’re not sure if you can reach that or activate that with a keyboard. So, you might use a keyboard access check, all by itself.

    If you’ve added a new sidebar and you say, “I wonder if that text contrast meets the requirement for people who have color blindness or low vision,” and you just want to check that one thing. Then, you can really segment this out and check whatever it is that’s of concern or maybe that you have responsibility for, if it’s media or some other aspect.

    Whitney: That’s nice because I think often…I know there are sites where one person does everything, but a lot of times I would think that the people in charge of multimedia might be different that the people in charge of, say, writing forms. So, this lets you get the right check to the right person.

    Sharron: Exactly. That was what we were hoping for. Now, for people who are going to be at CSUN, the Assistive Technology Conference, we’re going to be trying to corral some people to really do some usability tests on this Easy Checks itself. If people are at CSUN, and they want to find us and do that, Shawn and I…Shawn Henry is my coach here at the Education and Outreach working group. We have a couple of different sessions.

    Just come find us, because we’d love to get feedback from people about the way that they use it, how they found it to be useful, or how it could be more useful.

    Whitney: Since you mentioned CSUN, that’s the CSUN Conference. That’s CSUN in San Diego, from the 18th to the 21st of March. You actually gave me a great lead into what I was going to ask you next. For those of us who work in UX, working with real users is an important part of developing any project.

    First of all, I’m really glad to hear that you’re actually testing the Easy Checks, but I want to actually ask you about where you think usability testing fits into accessibility.

    Sharron: Oh, Whitney. I think usability testing is so important, because there’s a difference between conformance to a technical standard and usefulness to a person with a disability. I think Education and Outreach, our working group, most definitely has the human perspective. We want to give people resources that certainly, by all means, meet the standards and conform to the standards, because that’s really important in terms of technology interoperability.

    But, ultimately, the most important thing is whether someone with a disability can get the information, interact with it, and perform the same functions and do it in an efficient way. I’m so much a fan of your work, because of the fact that you understand that intersection as well as anyone, and it’s an important thing for people to remember.

    Conformance, by itself, is almost secondary.

    Whitney: Yeah. When I started in usability, we used to do heuristic or expert evaluations, and the way I was taught to do them is, first, you did the expert evaluation, you fixed all the problems that you could see easily, and then, when you had something you really thought was working, you took it to users, and you tried it out with them to make sure that it really worked.

    You would really find different things. We would find technical problems, but the usability testing would find problems like, “Yeah, it works, but it doesn’t work the way people want it to work,” or, “It doesn’t really do the things they need.” I think it’s great to hear that getting into accessibility as well.

    Sharron: Yeah, and, often, that it doesn’t work the way that they expect it to work. User expectation is something that, I think, in the accessibility field, you have screen reader users who they’re managing some pretty complex interactions with the screen readers in the way they use the keyboards for certain things.

    Then, if the designer decides to introduce a keyboard command that contradicts that, maybe, technically, it doesn’t interfere with accessibility conformance, but, when it comes to use, it’s going to be a different story. Fortunately for us on Education and Outreach, we have group participants in the working group who have disabilities of various kinds, so we get that feedback immediately.

    We hope that we’ve integrated that into…one of the things you’ll find on the Easy Checks is we have different sections that expand and collapse in order to talk a little bit about the tools that you might use here, or give you some more tips of some more definitions. We had to really fiddle around with that expand-and-collapse function because of the way it interacts with its various assistive technologies and what were the expectations of people with disabilities who would come on the expand-and-collapse function.

    Whitney: I also noticed that one of the links on the page links to another page that talks about involving users in evaluating Web accessibility. I think that’s really helpful to have some guidance there as well.

    Sharron: Yeah. We also want to not just include that in our own group of people but encourage other people to understand that it’s really not that difficult to include users with disabilities in your testing processes.

    Whitney: It sounds like we’ve got a great thing here. We’ve got a strong standard that’s an international standard with some choices about where to start, some tools to help you get started, that’s been informed by actually users with disabilities as well as experts, and also guidance to help people who are evaluating their own website, include people with disabilities in that testing.

    Just to say it again, you can find the Easy Checks two ways: if you go to the home page of the Web Accessibility Initiative, you can look for Easy Checks under “Evaluating Accessibility,” or let’s repeat the URL, it’s: www.w3.org/wai/eval/preliminary.

    Before we run out of time and wrap up, Sharron, I would love you to tell us about AccessU, your conference is coming up May 13 to 15 in Austin, Texas. Full disclosure: Sarah Horton and I, are both really excited that we’ll both be presenting at this year’s event.

    Sharron: Oh yeah. We’re very excited that you’re coming. The whole usability track at AccessU this year is going to be one of the strongest that it’s ever been, thanks to the work that you, Sarah, and others who are doing so. Yeah, we’re very excited about AccessU this year.

    It’s the 12th annual AccessU. We get the run of the St. Edward’s University campus. It’s a beautiful campus in South Austin, looking right over downtown, and they’re in between classes, so we have the full run of the campus for those three days. We really tried to provide very practical…just like the Easy Checks. Something that’s practical, that you can take home and use right away.

    We have tracks in usability, we have technical tracks, policy and managing tracks, and really hope to see as many people as possible come to Austin in May. We haven’t turned on the big heater yet.

    Whitney: Who are some of the other stars that’ll be there?

    Sharron: Derek Featherstone, from Simply Accessible, is going to be there. Glenda Sims — she’s the stalwart, always a great contributor to AccessU. Estelle [?] is going to be there. We have quite a bit of expertise of HTML 5, CSS, all the new techniques that people are using, as well as some very basic and very introductory classes as well.

    Whitney: So, to work for someone just getting started and for someone who’s trying to do innovative design.

    Sharron: Absolutely.

    Whitney: Excellent. I really look forward to seeing you there. Sharron, thank you so much. This has been Sharron Rush, from Knowbility, talking to us about Easy Checks and getting started with accessibility.

    Sharron: Thanks for having me, Whitney. It was my pleasure.

    Whitney: And thanks to all of you for listening in, and, of course, 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 on Twitter. That’s @AWebforEveryone. We’ll be posting information about future podcasts there. Of course, if you go to our book site at Rosenfeld Media, we have lots of resources available for you as well.

    Russian Translation – Excerpt from Chapter 5 – Easy Interaction

    Posted on

    A Web for Everyone goes global. A few months ago, we were excited when A List Apart published an excerpt from our chapter on easy interaction. Now it’s available in Russian on Frontender Magazine.

    Read it in Russian. Or English. Or both.

    Thanks to George Sapronov and translator Natalia Lukanyuk (Наталья Луканюк) for their work in making this excerpt available.

    Universal Plain Language: An interview with Ginny Redish

    Posted on

    An edited version of this interview appears in Chapter 8 of A Web for Everyone.

    Photo of GinnyGinny Redish has been helping people write clearly for all of her career. She does research and analysis to understand what’s hard about reading and writing, and follows up with guidelines that people can use to make reading and writing easier.

    In our experience, language and content often get less attention than other elements in design projects. We wanted to learn from Ginny how to make language more of a priority.

    Plain language is important for accessibility

    Plain language is all about accessibility—making information understandable for everyone. Of course, plain language specifically benefits people with low literacy, of which there are many. ”The rate of functional illiteracy in many countries of the world is shockingly large.”

    However, we all have difficulty reading at some time or another, for physical or cognitive reasons, or when encountering an unknown topic or language. “Even people who are high literacy sometimes have problems reading—when they are under stress, or when it’s an unfamiliar topic.” In the end, “plain language is valuable—even necessary—to just about everybody.”

    Plain language is particularly important on “functional websites,” where people go to get information and accomplish tasks. When you use plain language, “people can find what they need, understand what they find, and use that to accomplish whatever it is they need to accomplish.” And plain does not mean dull.

    “It’s not a matter of dumbing down. It’s a matter of meeting people where they are and saving people’s time. People don’t come to functional websites to waste time. They are very busy with other parts of their lives. They need to be able to find, understand, and use the information in the time and effort that they think it’s worth.”

    Plain language fits well with the concepts of universal design

    Can one source of information work for everyone? For universal plain language, “whenever possible, you want to have one source that works for everybody, and when that is not possible, you want to satisfy everybody’s needs.” In this way, Ginny’s approach maps well to the universal design concepts of same means of use, equivalent use, and accommodation.

    Same means of use. In universal design, the idea is to build in flexibility so that different people can use the same design with individual tweaks to met their needs. “In some aspects of the web, you can build in flexibility that allows people to take something and make it work for them.” For example, people with low vision can enlarge text or switch to a high contrast view.

    “However, with the language part of a design it’s harder because you have to choose which words to use.” Plain language gives you the broadest “same means of use.” In most cases, following plain language guidelines will allow you to reach all your audiences with a single content source.

    Equivalent use. For times when one size does not fit all, it may be necessary to provide different versions. “When you have different audiences who are coming to the same topic with different backgrounds, different needs, and different vocabularies, you may need to provide different content.” For example, Ginny worked on the National Cancer Institute website, which provides two sets of information: one for patients and families and one for health professionals. “We can think of this as ‘equivalent means of use’ because the more technical language used for health professionals is ‘plain’ from their perspective. And both sets of information are available to everyone, so individuals choose which to read—or read both.”

    In all cases, following plain language guidelines is critical. As Ginny stresses, “You always want to write straightforward sentences.”

    Accommodation. “If you write your main content in plain language, you will reach a wider range of your audience, but there could be people for whom that is not simple enough.” In these cases, it may be necessary to look to an accommodation, such as Easy Read Online. This service uses techniques like video, images, and simplified text to modify documents for people with learning disabilities and little or no reading ability.

    The risk with alternative versions is maintenance–keeping the main and alternative content in sync and up to date.

    Ten years ago, the solution to accessibility for many websites—if they did anything at all—was to create a separate, text-only version. That turns out to be a very bad idea. They are meant to be equivalent, but after a short time they aren’t equivalent. Separate but equal is never equal.

    For this reason, if you decide to create multiple versions, you should do so deliberately and with caution. When working on a project that appears to require different versions, Ginny notes, “I only agree if I know we have different audiences who need different content.”

    Design projects need content people

    Key decisions such as this illustrate the importance of having a content strategist on the design team. Typically, teams don’t consider content until the very end of the design process, and then content providers scramble to replace “lorem ipsum” placeholder text with actual information. And more often than not, the people producing the words are not trained as writers, never mind in the techniques of plain language. As a result, the very thing people come for—information—is often the most poorly implemented part of a design.

    People who come to websites don’t come to navigate. They don’t come to admire your design. Obviously, the design and navigation are potential barriers, and they have to be good so as not to be barriers. But what people come for is the content, and the content is both information design and language. Understanding its importance and making content an integral part of the process is critical.

    Planning is critical to successful plain language

    With Ginny, plain language starts at the beginning of the design process, with three planning questions.

    The first question is: “Why? What are you trying to achieve?” In considering content, you may have one purpose or many, but the purposes cannot be vague, like “to give people information.” They must be “actionable purposes with measurable results.” Ginny gives as an example the purpose of information contained in a university catalog: “We want people who have never been to a university to make good choices about programs that would be appropriate for them to take, and we want them to choose to come to our university.”

    The second planning question is: “Who? Who are your site visitors?” “One of the problems with websites is that the people writing the website are often extremely knowledgeable about the domain of the website. They forget that a lot of the people coming to the site are not as familiar.” Personas are a great way to “see” the people you are writing for. For universal plain language, personas should represent varying abilities with language and literacy, including non-native-language speakers, people with little education, and people with cognitive disabilities.

    The third planning question is: “Why are these people coming to your website?” To answer this question, you need to get inside the heads of your personas to learn what they want to know.

    When users go to visit a website, they have a goal, a need, a task in their heads. They are starting the conversation with the site.

    In that way, the web is different from paper. If I get an envelope in the mail, the writer has started the conversation. Sure, I have to open and read it; but I don’t start with something in mind. My first question is: “What is the author trying to do or say to me?”

    Online, it’s always the site visitor who starts the conversation. So the only way to write clearly is to ask yourself: “If someone comes to my website and they are interested in the topic, what do they want to know? What is the conversation?”

    This notion of writing for conversation can be a difficult concept to get across, especially to people who have no training in writing or who were trained to write for academic journals. “When people hire me to conduct a workshop on writing for the web, they assume I’m going to jump in and teach 10 plain language guidelines, but I don’t start there.” Instead, she starts with purposes and personas and the need for conversation. “You have to convince them that the only way to achieve business goals is to satisfy the site visitor’s conversation. Only then are they ready to work through the guidelines.”

    Plain language must be part of the design process from the start

    Implementing plain language in the design process requires content people, real content, and a commitment to conversation.

    • Content people. Every project should have professional content people on the team from the start–people who know how to write “clearly and conversationally.”
    • Real content. Prototypes should use real content from the beginning. And teams should test and modify content throughout the process, along with other design elements. Ginny urges, “No more lorem ipsum!”
    • Commitment to conversation. The design team should adopt a philosophy based on engaging in a conversation. “Your content strategy can’t be a one-way spewing of information. It needs to be answering site visitors’ questions. And if you think about content as a conversation, you are much more likely to write in plain language.”

    Making a commitment to plain language and integrating plain language into the design process improves accessibility in an integrated and holistic way. No one is adversely affected by language that is clear and to the point—in fact, everyone understands better. Working toward the goal of universal plain language is one of the best ways to improve the user experience for everyone.

    One of the most interesting aspects of the ADA movement has been how often something created to meet the needs of a special group of people has turned out to be useful for everybody. Plain language is the same. People think of plain language for a low literacy audience. But when we simplify and clarify for a low literacy audience, high literacy people benefit just as much, and sometimes even more.



    Meet Carol

    Posted on

    Carol is one of the personas from our book, A Web for Everyone.  No set of personas can represent the entire world of people with disabilities, but we wanted to bring some of the statistics and demographic data to life in the stories of these personas.

    You can download an overview of all the personas from our Resources page. The personas images, created by Tom Biby, twofinechaps.com, are available on Flickr.

    Carol: Grandmother with macular degeneration

    An older woman sits with her cat on her lap, reading a large print book
    My grandkids are dragging me into the world of technology.

    Carol has always loved reading, so her fading eyesight is a real sorrow to her. She tried recorded books, but she didn’t like listening instead of seeing the words in front of her.

    As a bookkeeper for 25 years, she made the transition from ledgers to a software program, so she’s happy to use the computer. She has an old home computer, which she uses the same way she always did her work—carefully checking everything as she goes. She loves getting emails from her grandkids (and a few friends). She likes reading magazine articles online, especially when they are free. Last year, she discovered that she could get her prescriptions more cheaply online, and now she buys some things from the web.

    Her biggest problem is that the text is so small. She’s learned how to click on the symbol to make the text bigger, but is frustrated when it doesn’t work the same way on every site.

    She also finds that her hands aren’t as steady as they used to be, and she can’t always click on things accurately. She likes her “old fashioned” mobile phone with large buttons that she can feel easily. As her eyes get worse, she wonders how long she’ll be able to keep using the computer. All that light gray text on a white screen. It’s just too hard to see. Maybe it’s really better for younger people.

    I don’t understand what the screen is saying

    In Chapter 5, Carol explains some of her problems understanding how to use the web. “I love seeing photos of my grandchildren, particularly since they live so far away. My granddaughter set up a place where she can put up pictures and notes for me. I was excited, but it took me three tries and a phone call to get me connected. I thought I filled in all the answers correctly, but the same questions kept appearing. I’m sure that program was trying to tell me what to do, but I just couldn’t understand what the screen was saying.”

    Why can’t the text be just a little bit larger?

    In Chapter 7, Carol has a simple request. “I’ve always loved reading, but my eyesight has been going for years. Now, it’s getting worse with this macular degeneration in one eye. A friend gave me a magnifier that she used for needlework. It sits over my book, so my hands are free. That helped for a long time. But even though I’m not very good at using the computer, I still like to try, especially to see the photos my grandkids send me. I love keeping up with them that way.

    “Some sites have text that’s just so small. I don’t know what I can do. I’ve learned how to set up my browser so that the text is bigger. It makes the links bigger, too, so I can click on them more easily. I wish all the sites would do this. Some just don’t seem to work. The text stays the same size, and I can’t read it at all.”

    Snapshot of Carol

    • 74 years old
    • Husband passed away a year ago
    • Lives in an apartment near one of her daughters, so she can be near some of her six grandkids (ages 6 to 16)
    • Graduated from business college
    • Retired; worked as a bookkeeper for a construction company for 25 years
    • Older computer at home; basic mobile phone

    The A’s: Ability, Aptitude, Attitude

    • Ability: First signs of macular degeneration, mild arthritis; hearing aid; no special AT on computer
    • Aptitude: Used computers when she worked as a bookkeeper, but now her grandkids keep her old home computer updated
    • Attitude: Willing, but not adventurous

    Assistive Technology

    • Enlarges text, but little other adjustment

    To see what the world looks like with one of nine degenerative eye diseases, download VisionSim from the Braille Institute (for iPhone, iPad, Android)

    The Bigger Picture

    Sources: CDC, A Nation Online, U.S. Department of Commerce, Braille Institute, Census

    • 11 million people in the U.S. have age-related macular degeneration; many more have other forms of degenerative eye diseases.
    • After age 65, people have steep increases in disability, with over 59% experiencing a loss of hearing, vision, or dexterity. (U.S. Census says 38% of all adults have disabilities.)


    Responsive Design: An interview with Ethan Marcotte

    Posted on

    An edited version of this interview appears in Chapter 7 of A Web for Everyone.

    Photo of EthanEthan Marcotte is a designer who codes and a coder who designs. While many web professionals have this combined skillset, Ethan brings a high level of mastery to both disciplines. And like all great masters, Ethan is also a teacher. Ethan literally wrote the book on a flexible design approach called “responsive design.”

    We wanted to learn from Ethan how a flexible approach supports accessibility.

    Ethan started his career in the late 1990s, and has worked in design studios for most of his career, including several years as Interactive Design Director for the award-winning design studio, Happy Cog. Currently, he runs his own web practice, and has worked for a variety of clients including Stanford University, Sundance Film Festival, and New York Magazine. He recently finished a large-scale and groundbreaking design of the Boston Globe, with Filament Group, in which he employed the “flexibility in use” principle in a design approach he invented, and he literally wrote the book on “responsive design.”

    Balancing control and flexibility through responsive design

    “Flexibility is near and dear to my heart.” Ethan’s early career was spent creating flat graphics in Photoshop or Illustrator, vetting the designs with clients, and then implementing the design in code. “I started off building sites that were 620 pixels wide, then 760, then 960. Every couple of years there was a universal consensus established: ‘Okay, now it’s safe to upgrade.’ But natively, the web doesn’t understand width or height or anything like that.” This disconnect got him thinking about a more flexible approach.

    The essay by John Allsopp, “A Dao of Web Design,” helped Ethan see that by bringing preconceptions to the web based on a completely different medium–print–designers were getting in the way of the flexibility inherent in the web. And that flexibility was key to accessibility. Ethan began to explore ways to achieve “controlled flexibility” in web design, a place somewhere between absolute flexibility and absolute control.

    What is so fundamentally powerful about the web is that promise of access. We have the technology and approach in place to design sites that are as viewable on a feature phone as they are on a 27-inch monitor with the latest Chrome browser. Flexibility doesn’t require a sacrifice in the quality of the experience on one end or the other. It’s all about delivering content to people.

    Ethan says that content delivery is the primary goal of a responsive design approach: making sure that content is universally accessible, regardless of how it is accessed. It starts with structured HTML for content, and then uses CSS and JavaScript to progressively enhance the experience. HTML5 media queries provide the opportunity to “tune the display,” adapting elements such as color and size, depending on the needs of the user.

    “Responsive design is really just a new name for a lot of old thinking about capitalizing on the flexibility inherent in the web. We use flexible layouts by default, but then get some of the control and constraint we need as designers using media queries and other approaches to enrich the experience.” It’s an approach that looks at flexibility “not as something we need to work around or constrain, but rather as an opportunity to enhance the design.”

    In essence, responsive design is about “bringing the design to meet the users.”

    Redesigning the Boston Globe website

    Ethan and his colleagues at Filament Group implemented responsive design on the Boston Globe website. “It was a seriously fun project. There were a lot of interesting problems to solve. And the Globe was really committed to the idea of making their content as universally accessible as possible.”

    “We didn’t want to think about accessibility at the end of the project, as is usually the case. We tried to think broadly throughout the process, and work proactively rather than reactively.” Rather than work from a list of browsers and devices, they focused on characteristics, such as the size of the screen, the input model, and the availability of technologies such as CSS and JavaScript. “Those kinds of categories really helped when we were thinking more broadly about the design, both from the layout perspective and an interface perspective.” For example, rather than test how a carousel would work on a specific device, they asked how it would be accessible to someone who didn’t have JavaScript. Working from a master list of categories, they established a baseline for accessible content, and used progressive enhancement techniques to enhance the experience for more capable systems.

    The new bostonglobe.com, launched in September of 2011, has been cited as a “major step in the evolution of website design,” (Beaconfire) providing an “elegant, readable website no matter what screen size you’re using.” (Webmonkey) Ethan has been getting positive feedback on the site’s responsiveness, including in some scenarios they did not even consider during the design process. “Somebody posted a screenshot on Flickr after the site launched of the Globe as rendered on an Apple Newton. It’s structured HTML–there are headings, paragraphs, lists. You can still browse the site. That’s a testament to the portability of the technologies we work with.”

    Supporting responsive design in the design and development process

    The design process for responsive design is a departure from more commonly used methods. “It’s common in web shops to finish a design and then throw it over the wall to the development group, and those two groups never interact.” With responsive design, the approach needs to be more collaborative and iterative, testing ideas in a responsive framework and then iterating as needed.

    Also, with responsive design, it’s critical to move to HTML and CSS early in the design process, allowing for testing across browsers and devices, and using the built-in capabilities of different devices, such as VoiceOver on iOS devices. “If you treat mock-ups in the design phase as a ‘catalog of assumptions,’ and move quickly to responsive prototypes, you can test those assumptions directly in the browser. That cuts down the number of surprises.” And testing is key to accessibility, making sure that content was accessible and legible at the baseline and then enhancing up. For the Globe, they used Blackberry 4 as one such baseline: “If you give that browser more than a couple kilobytes of JavaScript to parse, it completely falls on its face.” In considering the experience of the site at the baseline, “You could argue that some of those experiences are less rich. What we found was that they matched the readers’ expectations for the device they had in their hand.”

    In some ways, the key to a successful responsive design is not the design or the technologies used: it’s the content. A “mobile first” approach is a great way to regulate the content requirements. “We talked about whether the content was useful to our mobile users. It the answer was ‘no,’ then we asked if it had value to anyone. Making a commitment to content across every device and every context was key.” The content management system and publishing workflows are important considerations as well. “If you are hoping to deploy the same content in different scenarios, then you have to look at the quality of the markup.”

    Ethan is a designer who appreciates the fine details of the craft, such as the rhythm and measure of a well-set block of text. In discussing design, he invoked Robert Bringhurst in speaking about “tuning the measure to the distance between the eye and the screen.” At the same time, he acknowledges, “We have no way to predict that.”

    But Ethan does not feel limited as a designer by web technologies. “Some people see HTML and CSS as a limiting factor. For me, there’s always been a way to do what I need to do.” In large part, that is because Ethan does not try to control his designs: “The notion of control is foreign to the web.” He finds that “letting go of the assumption of what you expect your design to look like is actually liberating.”

    I like thinking about how a design is going to read on a Kindle or a feature phone. Those might not be the most visually arresting experiences, but there are still opportunities for things to be designed. Even if someone is having content read aloud on a page, that experience is something we can design–we have the technology to do that now. For me it’s a process of discovery, trying to establish ideas on a page and then moving into code to finish the design process. That’s been fun for me.

    Ahead: More opportunities for responsiveness

    Looking ahead, Ethan sees more opportunities to build responsiveness into websites and web applications, including new CSS3 modules like flex box and grid layout, which will allow greater control over the display order of elements. But in order to move forward with a responsive approach, he believes that we need to revise our expectations about control. For so long. our efforts have been about “slotting paragraphs into specific positions on pages.” For universally accessible content, Ethan urges that designers work with the native flexibility of the web, rather than trying to constrain it. “If your web app is a call to one JavaScript function that spits out HTML to the page, think about what that experience is going to be like for less capable browsers and readers. If you think flexibly from the outset, it makes a lot of things much easier.”

    Introducing A Podcast for Everyone, with Adam Churchill, Sarah Horton, and Whitney Quesenbery

    Posted on

    A Podcast for EveryoneIn this premiere episode of A Podcast for Everyone, UIE’s Adam Churchill interviews Sarah Horton and Whitney Quesenbery about their book, 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.

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

    Resources mentioned in this podcast


    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!

    Meet Maria

    Posted on

    Maria is one of the personas from our book, A Web for Everyone. It’s important to remember that a person with a disability is, first, a person. They like their hometown sports team or love going to the theater. They are funny or quiet, or quick to anger, just like everyone else.

    You can download an overview of all the personas from our Resources page. The personas images, created by Tom Biby, twofinechaps.com, are available on Flickr. Tune in for a new persona every Tuesday until all eight are posted.

    Maria: Bilingual community health worker

    A woman leads a meeting. She had a tablet with a Spanish site in front of her.
    I love this. It’s all here … when I can find it.

    Maria comes from a traditional Mexican extended family. She grew up helping her parents and older relatives navigate the English-speaking world. Her work as a community health worker is a natural extension. She does outreach and health education in the Spanish-speaking community in LA.

    Her husband is good with the computer, and bought one for home, so their kids would be able to use it for their homework. It’s become an important way to keep up with their family back home. They post videos of the children and use Skype to keep up with cousins and friends.

    Her real lifeline is the smartphone that her family got her last year. Her daughter set up all of her favorite sites in her bookmarks, and she uses the calendar to keep track of her appointments. To tell the truth, she isn’t really sure how it all works, but it’s wonderful that it does.

    She prefers to read in Spanish, especially when she’s looking up information that she needs to share with a client in Spanish. Her daughter showed her how to translate a page on the browser. It’s not very good, but she can use it to get the general idea of what a page says.

    A lot of her professional health education has online videos. Captions help her understand the lectures better, especially for scientific words.

    When a site is confusing, I just leave.

    Talking about sites with clear purpose (in Chapter 3), Maria says, “My clients, most don’t speak  English well, so I need sites that have health information in Spanish, too. I can read it with them and make sure that they understand it, and that they know the words to tell their doctor.

    “To tell you the truth, on my own, I don’t stay on a site long if it’s confusing. On many sites, there is so much crammed in that I can’t find anything at all. It just makes my head hurt to even try. I like the sites that are simple and don’t have so many decisions I have to make. When I find a site that works for me, I stick to it. I have a nice health site that I use most of the time. For anything else, I just search.”

    When I hear and see it, health information makes more sense.

    She also talks about how text-to-speech features help make media more accessible for her (in CHapter 9), “My new phone is so good for my work. I don’t have to carry around so much paper because I can pull it up from my bookmarks. I even tried watching one of my health educator’s videos, but the captions were hard to read on the phone. Those captions are very nice. I can see the words spelled out while I hear them, so I learn how to spell them, too. It’s also nice to give videos to my clients. Sometimes they don’t read English well, but they can listen OK.”

    Snapshot of Maria

    • 49 years old
    • Community college + healthcare certificate
    • Married, grown children
    • Bilingual (Spanish dominant)
    • Community health worker
    • Smartphone from her phone service, home computer primarily her husband’s, for his business

    The A’s: Ability, Attitude Aptitude

    • Ability: Prefers Spanish language sites, when she can find them; needs information and instructions written clearly
    • Aptitude: Adventurous, but not very proficient; husband and daughter set up bookmarks for her
    • Attitude: Thinks it’s wonderful to be able to have her favorite websites with her at all times

    Assistive Technology

    • Skype
    • Translation sites

    The Bigger Picture

    Source: National Center for Health Statistics and U.S. Census, Marketing Charts

    • 17.8 million people in the U.S. speak English “less than well.”
    • Hispanic U.S. adults are more likely to use mobile devices and mobile search. They are more likely to take mobile pictures and video.