A Web for Everyone Blog

Designing Accessible User Experiences

Posts written by Sarah Horton & Whitney Quesenbery

  • Meet Vishnu

    Posted on

    Vishnu  is one of the personas from our book, A Web for Everyone.  Personas have names and personal characteristics and abilities, along with aptitudes for using technology, and attitudes about their experiences. And, they have stories that provide details about their life.

    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.

    Vishnu: Engineer, global citizen with low vision

    A man sits at a desk with a computer and engineering equipment. He has a large print keyboard.
    I want to be on the same level as everyone else.

    These days, Singapore is a center of the world, and Vishnu is one of its global citizens. After graduating from one of India’s technology colleges, he went to a postgraduate program at the National University of Malaysia. His work on visualizing data landed him a job with a multinational medical technology company.

    Vishnu was diagnosed with glaucoma and his eyes have been getting steadily worse, despite treatment. He can adjust his monitor and his phone, but many of the technical programs he uses don’t have many options, so he has started using a screen magnifier and high-contrast mode.

    Like everyone in Singapore, he has several mobile phones. One connects him to his family in India, one is for work, and one is for personal use.

    He’s lucky to have good bandwidth at home and at work. Some of his colleagues from the university live in places with much more erratic connections. Even so, downloading large pages from European or U.S. servers can be slow.

    But, if he had one wish, it would be that people would write technical papers and websites more clearly. His English is good, but idiomatic expressions can still be hard.

    If I can adjust my screen, I can read comfortably

    The flexibility of the web helps Vishnu read more easily, especially when the site adjusts (Chapter 7) to his preferences. “I use a smaller window than I used to, because my vision kind of fades out at the edges. When I can, I make the whole page larger, so I can see the details in images better, too. Once I find a site that I can set up to read well, I stick with it—the BBC for international news, a cricket site. What I really want is for the web to look the way I need it to, not just a few favorite sites.”

    Translating in my head is easier with simpler sentences.

    In a global world, Vishnu is often reading in English, a task easier when the content is written clearly (Chapter 7). “In my field—we’re working on medical imaging for diagnostic testing—the professional papers are in English. No matter what language we speak in our daily lives, everyone in my company reads two other languages: software mathematics and English. It’s the international language. The concepts are complicated, so I really appreciate it when I find a paper where they are presented in clear language. It’s not just reading the paper itself—searching and navigating in English can be harder than reading the technical papers, where at least I know the jargon.”

    Snapshot of Vishnu

    • 48 years old
    • Engineering degree
    • Works for a medical software company on projects for international use
    • Born in India, finished graduate school in Malaysia, lives in Singapore
    • High tech all the way at work; two mobile phones and a laptop for personal use

    The A’s: Ability, Aptitude, Attitude

    • Ability: Speaks three languages: Gujarati, Hindi, English, and a little spoken Mandarin. Uses contrast adjustment to see the screen clearly
    • Aptitude: Expert user of technical tools; frustrated searching across languages
    • Attitude: Sees himself as a world citizen, and wants to be able to use any site

    Assistive Technology

    • Contrast adjustments
    • Screen magnification software
    • Personalized stylesheets for colors that make it easier to read text

    The Bigger Picture

    Source: The Lighthouse/WHO

    • An estimated 135 million people have partial sight.
    • Many people in south Asia speak at least three languages: their regional language, Hindi or Mandarin, and English.


    Coding Accessibility: An interview with Steve Faulkner

    Posted on

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

    Photo of SteveSteve Faulkner has been an accessibility engineer since 2001, first with Vision Australia and currently with The Paciello Group. He has a hand in developing HTML5 and WAI-ARIA specifications as a member of W3C working groups, and is editor of W3C specifications on HTML5, Using ARIA in HTML, accessibility APIs, and text alternatives. In short, Steve has accessibility chops.

    Because much of what’s needed is beneath the surface of a page, we asked Steve to explain what user experience designers should know about how code supports accessibility.

    Elements of an accessible user interface

    Web accessibility is largely about providing the information needed to make a user interface accessible to assistive technology, or AT. This is accomplished via an accessibility application programming interface, or API–a standardized way of specifying elements of an interface. A primary goal of an API is interoperability, where different devices and software can all use the same elements. For accessibility, Steve explains, “One piece of the puzzle is for information to be defined by an accessibility API. The second piece of the puzzle is for AT to make use of it.”

    For the web, every HTML element has a role, states, and properties that are defined in the technology specification–“What it is, what it does, and where it’s at, at this point in time.” That information is expressed by the accessibility API in the browser, so that assistive technology can make use of it. “For example, with a heading, one of the properties might be its level, and whether it’s editable, visible, or linked.” The role, state, and properties information in the accessibility API allow assistive technology to, for example, create a list of headings or move keyboard focus to the main heading of a page.

    Unfortunately, browsers and assistive technology don’t always make use of the accessibility API. “We’re always told to use <strong> and <emphasis> rather than <b> and <i> because they have semantic meaning, but the semantic meaning is not consumed by anyone” because browsers and assistive technology don’t make use of the information.

    An accessibility API needs more than HTML

    There are gaps in how native HTML elements support the accessibility API, because of how they are specified and how they are used. “Some decisions about what goes into HTML and what doesn’t don’t take into account accessibility requirements.”

    For example, the role “main” is not represented in the HTML5 specification as an element, despite the expressed need for AT users to move cursor focus to the main content area. Other roles are defined, such as header, footer, and navigation: “I guess the thinking was, anything that’s not something else must be the main content.”

    Also, HTML elements are not always used correctly. As an example, Steve explains that HTML buttons have been part of the specification for 15 years. However, developers build custom buttons using elements like images and links that are coded to behave like buttons. Typically, this is because of constraints imposed by visual design requirements. “They have to please whoever makes the design decisions. To achieve a certain visual effect across different browsers and platforms, they can’t always use standard controls.”

    In these cases, HTML cannot provide the necessary information to make the interface accessible. “WAI-ARIA is the only way to supplement the necessary information for assistive technologies.”

    WAI-ARIA fills the gaps

    WAI-ARIA fills out the accessibility API, enhancing the descriptive information contained in native HTML controls and back-filling information for elements that are used for other than their intended purpose.

    For example, ARIA provides explicit roles and properties to assist in wayfinding for users of assistive technology. Like “stepping stones,” ARIA landmark roles allow assistive technology users to step through the content of the page to find the content area of interest.

    As with most accessibility features, information provided for accessibility could be of use to all users. “ARIA landmark roles would be of great use to users who navigate by the keyboard, but the roles are not exposed as navigable elements by browsers.” Assistive technology makes use of the roles, but as of this writing, no browser does. Another possible application would be to dim regions of the page that do not have focus in order to reduce distractions. Landmarks could also be used in the print view of a document, providing users with the option to hide elements like navigation that have little use on paper.

    Accessible code in the real world

    Steve is editor of four W3C specifications: HTML 5.1, Using ARIA in HTML, HTML5: Techniques for Providing Useful Text Alternatives, and HTML to Platform Accessibility APIs Implementation Guide. To inform his work, he started a data-mining project in which he downloaded the home pages of the top 50,000 websites and began analyzing how designers and developers were using elements, specifically HTML5 and ARIA code. “Those of us who develop standards define how things should be used and hope that developers follow the guidance so users get the benefit. But unless we actually look at the way they are being used, we can’t know whether they are actually being used in the right way.” His hope is that, by analyzing and identifying patterns of real-world code, he will be able to provide more practical guidance.

    For example, in HTML5, there’s a new “placeholder” attribute that allows you to display a hint in a text field, such as “Enter your first name.” Some sites use “placeholder” as a field label, in place of the <label> element. In this case, Steve can recommend that browser’s use “placeholder” in “accessible name calculation” to convey information to assistive technology users about form fields.

    Steve is also learning how much and how effectively HTML5 and ARIA are used in mainstream websites: for example, how ARIA landmarks, such as role=”main”, role=”banner”, and role=vcontentinfo”, are implemented. While he found that usage was low, he was “both surprised and pleased” to find that landmarks are being used correctly. “The specification says, for certain landmarks, you should have one per page, and overwhelmingly they are being used per specification, with one per page.”

    HTML5, ARIA, or both?

    In general, support for ARIA is more robust than accessibility support for new HTML5 features, due to its age and attention paid to getting ARIA support in mainstream tools. While ARIA has been providing landmark support since 2006, as of this writing, the HTML5 spec is still in the works. In addition to maturity, ARIA has benefited from successful collaborations between accessibility experts, such as IBM, and browser and AT vendors, such as Firefox and Freedom Scientific.

    As a result, ARIA support is strong in most software. “I’m not saying that it’s good across the board, mainly due to some AT vendors just putting their heads in the sand, which has the effect of doing a disservice to their users.” And you can count on support for ARIA into the future. “As far as ARIA is concerned, it will remain relevant for many years to come. As new issues and technologies emerge, there will be new related updates to the ARIA specs to fill in any gaps.”

    It’s best to think of ARIA as complementary, with HTML providing the core elements and ARIA filling the accessibility gaps as needed. “A good rule of thumb is, when there’s a native HTML structure, element, or attribute that’s well supported, use it. If that’s not enough, use the appropriate ARIA semantics.” But Steve also points out that there’s no harm in using both HTML5 roles and ARIA landmarks, such as <nav role=”navigation”>, where <nav> is an HTML5 element and the attribute role=”navigation” is an ARIA landmark role.

    Advice for project teams

    Steve encourages developers to go ahead and add ARIA landmark roles to current projects. “The good thing about landmarks is that you can add them to your current code, and they don’t have any design effects.” For interactive widgets that provide complex interactions, he recommends looking to existing libraries, such as JQuery or Dojo–code with WAI-ARIA already built in.

    But he also sees the need for a change in mindset in how designers build websites and applications. “You tend to find back-end coders developing front-ends without understanding what makes a user interface usable, let alone accessible.” This is because project efforts often focus on the business transactions that occur on the back end, with little thought given to the user interface. “HTML development is often seen as monkey work that’s given to junior developers, or given to back-end developers who tack the front end on, and they don’t understand how to develop a user interface correctly, they don’t understand how to use HTML correctly, and then you see applications built without semantics.”

    On the design end, Steve urges designers to understand that design elements are not just “pixels on a page,” but rather semantic containers for information described in code. “I don’t think designers need to know how to code. They do need to understand that there’s a give and take between what can be done given the requirement to actually code.”

    Overall, he believes that project teams must include user interface expertise. “What’s needed is the realization within a team of the value of having people who understand usable UI design and can bring it to fruition using the code.”

    Meet Steven

    Posted on

    Steven is one of the personas from our book, A Web for Everyone. Including people with disabilities in your research is not as hard as you thing. If you open up your recruiting, you may find people with a variety of abilities who are already part of your audience.

    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.

    Steven: Deaf graphic artist and ASL speaker

    A man signing to someone on his phone. Drawing tools are on the table in front of him
    My only disability is that everyone doesn’t sign.

    The nice thing about being a graphic artist is that most of the time his work can speak for itself.

    When he first started working, most reviews were done in meetings, but more and more his agency works with clients using online workspaces. He’s had some projects recently where all of the communication was through the web. Although he likes seeing live reactions, it’s easier for him to participate in the project forum discussions using text rather than audio. His iPhone has also been important. It was his first phone with a good way to do video chat so he could talk to his friends who sign.

    It’s annoying when videos on the web aren’t captioned. How is he supposed to learn about a new app if the only information is an animated video? Or if he’s the only one in the office who doesn’t get the joke?

    Like many people who learned ASL as their first language, Steven prefers sign, but reads text, since that’s most of what the web is. If a site is just a big wall of text, he’s likely to leave unless he knows it’s got the information he needs.

    Without captions, it’s meaningless to me

    There’s not much more to say about audio without video. Steven explains in Chapter 9 why captions are so important to him.”I love that there is so much visual information on the web, but when it comes to videos, why can’t people take the time to include me? For example, I was trying to learn how to use a new application, and the only instructions were in a screencast. I could sort of follow what they were doing, but when someone interpreted for me, I found out that I misunderstood an important point. It makes me so frustrated. I’m good at what I do, and don’t like being left out or having to ask someone to interpret information for me.”

    Snapshot of Steven

    • 38 years old
    • Art school
    • Graphic artist in a small ad agency
    • iPad, iPhone, MacBook Pro; good computer at work

    The A’s: Ability, Aptitude, Attitude

    • Ability: Native language is ASL; can speak and read lips; uses SMS/IM, Skype, and video chat
    • Aptitude: Good with graphic tools, and prefers visuals to text; poorspelling makes searching more difficult
    • Attitude: Can be annoyed about accessibility, like lack of captions

    Assistive Technology

    • Sign language
    • CART—Communication Access Real-Time Transcription—captions for meetings and phone calls
    • Captions
    • Video chat

    The Bigger Picture

    Source: Gallaudet University/U.S. Census, audio-accessibility.com, Hearing Loss Association of America

    • 10.5 million (3.5%) people in the U.S. are deaf or have a significant hearing loss and 48 million people in the U.S. report some degree of hearing loss.
    •  500,000 to 2 million people use American Sign Language (ASL).
    • Sign is not a universal language. There are national versions around the world, such as Auslan (Australian Sign Language) and three different sign languages in Japan.


    Accessible Interaction: An interview with Derek Featherstone

    Posted on

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

    Photo of DerekDerek Featherstone is founder and lead of Simply Accessible, a consultancy that works to bring accessibility into organizations through consulting, training, workshops, and support. Derek is a well-known and well-respected advocate for accessible user experience, moving beyond technical accessibility to support good and successful experiences for everyone.

    Interactivity is a complex challenge for accessibility, making sure sites and apps are operable in different ways on different devices. We wanted to learn from Derek how best to approach a moving target like accessible interaction.

    People are the starting point

    Concern for people is the primary driver for Derek and his colleagues at Simply Accessible. They approach projects from the user’s perspective, starting with questions such as: What do we already know about people who use the site? What are their goals and motivations? What is this page or screen here to help them accomplish?

    From there, they consider how the design and flow impacts the success of people with and without disabilities. “It has to be about the people who are actually using the site or application to accomplish something. If it’s not about them, then what’s the point?”

    Best accessibility techniques are constantly changing

    Derek’s team works from a knowledgebase of accessible techniques, built over many years of user research and usability testing, learning how people use the web. Building on those known techniques, they use observation and experimentation to come up with better techniques for coding, designing, and writing content that improves the user experience.

    A lot of our work is experimental, even if it’s not fully classified as experimentation. Every technique that we come up with is our best technique at the time, until something better comes along. There’s a constant iteration that happens in the techniques we use.

    This iteration is core to their practice because there is always room for improvement when it comes to accessible user experience, particularly with interaction, where new widgets and modules regularly appear on websites and apps.

    We see a problem, we find an issue, and we pop a message into the team Basecamp: ‘Here’s an issue we found today, here’s the behavior of the form or link or whatever, and here’s how we think we can solve it. Can you code it up?’ Then we’ll put it through technical testing to make sure it’s compatible with different assistive technologies. And then we’ll roll it out and test it with users with disabilities. A lot of what we do is that kind of iteration, trying to explore different techniques.

    Technical remediation can help make interaction accessible

    Most often, Derek’s team is called on to take an existing website or app and make it accessible. Often, the designs are visually rich and appealing, and they convey information and relationships among elements in a visual way. However, those visual details are not always in the code. “The designs don’t convey the same information under the hood as they do visually.”

    Take, for example, social media sharing badges. Most are embedded within a page using iFrames, and can be difficult to understand and use for someone who can’t see what’s displayed on the screen. For instance, many don’t have alt-text that accurately reflects the contents of the badge, such as the state and status of different buttons. Visually, you can tell whether an item has been liked or shared, but the code doesn’t contain the same information.

    Derek and his colleagues have been working on a script for making social media buttons and badges accessible, one that would make state and status information available in the code where it’s available to assistive technology. This accessibility add-on then becomes part of their toolkit, to use on projects that include social media buttons and badges. But they also hope to influence the makers of these elements to incorporate their techniques directly into the elements.

    We know it would be better if these elements were natively accessible. We also know that change doesn’t happen right away. Both solutions are needed. We keep our fixes on file so we can use them while the people in charge of social sharing badges work on making them more accessible.

    Derek prefers to build in accessibility rather than provide technical remediation. “Our entire team views accessibility as part of the overall user experience and not as a separate thing that needs to be done afterwards.” However, in practice, clients very often come to accessibility late in the process, when there is little hope of changing the course of the design to produce a more accessible outcome.

    Quite often people come to us with a completed site that has already been approved by management. For us to look at something and suggest a design change ends up being quite difficult to do. What we usually do is say, given what you’ve designed, here’s what you need to do to make it work in a more accessible way.

    Integrated accessibility produces the best outcomes

    But in some projects, they are brought in early and remain part of the team throughout the project, through implementation and execution. Projects handled this way are the most successful.

    “What it comes down to is having people switched on right from the beginning of the project. They understand accessibility as more than a technical checklist.” With an early commitment, accessibility becomes part of the well-established user experience practice, integrated into defining requirements, user research, and carrying through to design iteration and execution. “One of the most important things to achieve success is to have all accessibility touch points built into the process right from the beginning.”

    Tools help teams integrate accessible components

    Derek and his colleagues have worked on several large-scale projects, and have had good success providing teams with tools that made it easier to build accessible products.

    Everybody is overwhelmed with work that needs to be done, the amount of work that needs to be done, and how soon it needs to be done. Everybody wants things yesterday. Our strategy is to give everybody the tools they need to get the job done.

    Simply Accessible gives teams an accessibility guide, integrated into the organizational style guide or branding guide. They create a code repository and pattern library containing elements such as modal dialogs or tool tips that can be easily dropped into code. The interactive elements are reviewed and validated for accessibility from a code, design, and testing point of view, including testing with people with disabilities.

    One of our goals is to eliminate excuses. On projects, somebody makes choices about the timeline, and that means somebody else has to say, “We don’t have time for accessibility because we have this deadline of ‘x’.” We think about all the different pressures people feel when building a site and try to address them.

    With this approach, communication is the greatest challenge. People working on the project need to know the requirement to use the library and other resources, and understand the implications of not using the tools. Otherwise, these resources may be overlooked or elements modified in such a way that the accessibility benefits are lost.

    The most influential tool for accessibility is clear purpose

    In cases where Derek has been able to influence design, the best tool in guiding an accessible process has been clear purpose–“Asking the original question, what is the purpose of this page and what are we trying to help people do.” In practice, we often use patterns and designs the way they’re always used, and add in expected features, without considering the goals and the necessary actions to support the goals. “That’s our most influential technique. And once we get answers, we can start asking questions like, how does somebody who uses voice recognition software because they don’t have the ability to use their hands, how are they going to activate that particular type of control?”

    The #1 reason for them to use the site is to work with this widget, but they can’t because they’re using voice recognition software, and the widget is designed in such a way that the voice recognition software user won’t know what to do to activate it in the first place.

    Starting with clear purpose and specific goals, the task is to design a solution that everybody can use to accomplish the tasks.

    Solutions come from different places

    Solutions aren’t always directly supported by design. In some cases, it’s the access technology that makes a design accessible.

    Derek tells a story of a woman who needed a very specific design approach for accessible interaction. She was a quadriplegic, but had enough strength in one arm to lift her hand and operate a large touchscreen. “She didn’t have dexterity in her fingers, but she could make a fist and use the middle knuckle of her index finger to tap the screen.” Her greatest challenges in using websites were radio buttons and checkboxes, which were too small for her to activate accurately. Derek created a user stylesheet she could install in her browser that would resize radio buttons and checkboxes 10 times the size they normally appear.

    “No designer would ever allow or think to include in their designs such large controls. It’s a solution that was only necessary for her.” But the story illustrates that accessible interaction isn’t about finding the one solution that works for everyone. “We can create one solution that works for most people’s abilities, but there are some people that need accommodation for their disabilities that a designer or developer can’t take into account in their work.” In these cases, the work of the designer and developer is to make the design flexible and adaptable. That way browsers and assistive technology can take elements of the design and adapt them to meet the specific needs of the user.

    Finding the “right” statistics

    Posted on

    The personas in A Web for Everyone, like all personas, put a face on data and user research, showing examples of how real people with real disabilities use technology and the web.  But we also wanted to show how these personas fit into a bigger view of the audience for a web site or mobile app, so we also included statistics about how many people are similar to them.

    When we started our research, this seemed like a pretty simple task. All we wanted was some quantitative statistics on disability from a reliable source. It didn’t turn out to be that easy.

    Different methods, different numbers

    First, it turns out that different countries collect disability statistics in different ways, making them difficult to compare and consolidate. We decided to concentrate on the United States, both for consistency and because we could find resources easily.

    The U.S. Bureau of the Census seemed like a pretty solid source. We used the annual Facts for Features  issued on the anniversary of the Americans with Disabilities Act. In 2011, it reported 36 million people with a disability (12% of the population) including:

    • 10.2 million people with a hearing difficulty
    • 6.5 million people with a vision difficulty
    • 13.5 million people who have difficulty concentrating, remembering or making decisions
    • 19.4 million people who have difficult walking or climbing stairs

    Then, we learned that the way the Census reports disability has changed over the years. For example the total number of people with a disability in the U.S. has varied from 33 million to 57 million. Apparently it’s not a simple question to ask, even when experts are asking the questions.

    And it gets even more complex. Advocacy groups use other research sources to estimate the number of people with specific disabilities. The Hearing Loss Association of America, for example, estimates that 48 million adults in the U.S. report some degree of hearing loss. That adds up to 19% of the population.

    How does this apply to UX?

    The simplest lesson is that these numbers are very big. Even if only 10% of the overall population has one type of disability, that’s a lot. Are you prepared to tell your company that an accessibility problem might be making it impossible for 10% (or even 20%) of the audience to use your site? That could be a lot of lost business.

    A more nuanced answer is that disability is not a clear bright line. Like so many other things about human beings, it’s a spectrum.  People not only have different degrees of disability, but are equally diverse in other ways, like how well they use technology to make the web easier to use or their preferences for how to get information. Maybe broader definitions are more valuable in thinking about the audience for a web site or app because it makes a better case for paying attention all the ways a site should support accessibility:

    • Some things are like an on-off switch: your site either has them or it doesn’t. If images do not have alt text, they are invisible to people who can’t see them. If video doesn’t have captions, the greatest audio track in the world is useless to someone with hearing loss.
    • Some are the kind where improving usability and the user experience helps everyone. Clear communication is easier for everyone to understand and can make all the difference to someone who doesn’t read well. Minimizing the effort it takes to interact with a form helps people with limited dexterity or who live with chronic fatigue and pain, and people using mobile phones on the go.

    We shouldn’t minimize the importance of statistics. They are the analytics of public policy and the numbers can matter.  But it’s easy to get caught up in quantifying a problem precisely when the real message is, “It’s big.”

    What we really need to do is start designing for everyone. So no one is left out.

    Meet Lea

    Posted on

    Lea is one of the personas from our book, A Web for Everyone.  Personas are used as stand-ins for all of the real users during the design process so that we remember to put people first, considering how we can make their experience an excellent one.

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

    Lea: Editor, living with fatigue and pain

    A woman sits at a desk. She's wearing a mic and earphone and leaning on her arm.
    No one gets that this really is a disability.

    Lea was on track to become the editor of the magazine she worked for when she started having numbness in her hands and feeling completely fatigued by the middle of the afternoon. She tried medications and exercise and getting enough sleep, but finally she had to make a change in her life.

    She found a job where she could work from home, on her own schedule. When she has good days, it’s like nothing is wrong. But on bad days, she measures every action so she can make it through the day. Sometimes that important editorial meeting is all she can manage.

    She had to adjust her computer: a new keyboard and trackball make it easier to type, and a good chair helps her avoid tender muscles. The biggest change was learning to write and edit using speech recognition software, Dragon Naturally Speaking.

    She’s lucky: the company understands that it’s a real disability. With an invisible disability like fibromyalgia, some people just don’t get it.

    Don’t make me work so hard

    A mouse may look simple, but Lea prefers to interact though the keyboard, as she explains in Chapter 5. “I love my keyboard. I tried dozens until I found one that fits my hands perfectly, so I hardly have to move to type. Maybe you think I’m a bit over the top, but it makes a difference for me by the end of the day. Using a mouse takes more energy than you think, and I have to conserve mine if I’m going to make it through the day. So do me a favor and let me use my keyboard for everything. OK?”

    Links at the top of the page make navigation easier for me

    Little things can make a difference. Good navigation (Chapter 6) can make using the web easier for Lea. “I like pages with links at the top of the page. It’s really helpful on long pages with a lot of sections. I can figure out what’s on the page without a lot of work. When I first saw a link to jump to the content, I didn’t know what it was for, but it sure made navigating with a keyboard easier.”

    Snapshot of Lea

    • 35 years old
    • Masters degree
    • Writes for a trade publication; works from home

    The A’s: Ability, Aptitude, Attitude

    • Ability: Fatigue from fibromyalgia, trackball, and special keyboard
    • Aptitude: Average user
    • Attitude: Wishes people would understand how hard it can be for her to make it through the day

    Assistive Technology

    • Split keyboard for less strain on her wrists

    • Keyboard controls to minimize arm movement
    • Dragon Naturally Speaking

    The Bigger Picture

    Source: National Institutes of Health

    • 5 million people in the U.S. have fibromyalgia, 80–90% of them are women.
    • People with fibromyalgia and related diseases like lupus, ankylosing spondylitis, and rheumatoid arthritis have increased sensitivity to pain.

    Meet Jacob

    Posted on

    Jacob is one  of the personas from our book, A Web for Everyone. It can be hard to think about using the web in ways that are different from your own experience. These personas helped us think about all the  different people who are served by innovative, accessible, universal design.

    You can download an overview of all eight 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.

    Jacob: Blind paralegal and a bit of a geek

    A man sits at a computer with headphones and a Braille keyboard
    The right technology lets me do anything.

    Jacob is a paralegal in a large law firm. He reviews cases and writes summaries, cross-referencing them to the firm’s own cases and clients. He’s building expertise in his area of law and is hoping to go to law school in a year or so.

    As far as Jacob is concerned, it’s the technology that’s handicapped, not him. When everything is in place, he can work just as fast and just as effectively as anyone in his office.

    He’s a bit of a gadget geek, always trying out new tools, looking for a little edge and something new. The last few years have been a lot of fun with all the new apps, and VoiceOver on his Mac and phone lets him use most of them pretty well. He likes the challenge of learning new tools.

    His other challenge is running. He’s training for a 10K run, running with a club in his neighborhood and using an app to plan his routes and track his distance.

    He’s just started to use The iPhone app, Passbook, and uses it to get train tickets and other travel. The regional rail system has an app, so he can just pull up the barcode and scan it at the ticket office. No fumbling for the right printed card—total independence. Same phone as everyone. Same app as everyone, and it all just works.

    This makes it possible to do my job

    Jacob relies on sites and apps that are built well, in this story from Chapter 4. “They say that on the Internet, no one knows who you are. That’s really true for me. I think there are people in my company who don’t know I’m blind—they only see me through email or the case summaries I write. When a site works with my screen reader, I have control over my own experience. I can preview the content on the page by listening to all the headings on the page. I’m confident I know I’m putting the right information in the right field on a form. Best of all, I’m no different from anyone else—and I’m faster than some of my co-workers, if you want to know the truth.

    “When a website is not accessible, or I run into broken links or forms, it’s really frustrating. Sometimes I miss important information because it’s hidden from my screen reader. Or I have to spend a lot of time figuring out what’s going on. I just want to be able to do things for myself, and when sites are broken, I can’t.”

    “Seeing color”

    A good app can provide information Jacob need. Like color. “You might wonder why a blind person needs to know about colors. I can put labels in my clothes so I don’t end up with clashing colors, but sometimes I need to know what color something is, like when someone tells me to get the “red folder.” One of the coolest apps I’ve found recently lets me point my phone’s camera at anything and then it reads the color name back to me. Is that a red pepper or a green pepper? It’s a whole new kind of independence. That’s a practical use, but I learned about this app from an article that had this poetic description of walking around a garden hearing all the different colors described. He called it mind-blowing. I agree.”

    Snapshot of Jacob

    • 32 years old
    • College graduate, legal training courses
    • Shares an apartment with a friend
    • Paralegal, reviews cases and writes case summaries
    • Laptop, braille display, iPhone

    The A’s: Ability, Aptitude, Attitude

    • Ability: Blind since birth with some light perception
    • Aptitude: Skilled technology user
    • Attitude: Digital native, early adopter, persists until he gets it

    Assistive Technology

    • Screen reader (JAWS on his laptop, VoiceOver on his phone)
    • Audio recorder (to take notes)
    • Braille display

    The Bigger Picture

    Source: World Health Organization, Census

    • People with visual disabilities make up about 2.6% of the world’s population (about 0.6% are blind).
    • In the U.S., about 1.8 million people can’t easily see printed words.
    • Only about 10% of people who are blind can read and write braille.

    Accessibility Standards: An interview with Mike Paciello

    Posted on

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

    Photo of MikeMike Paciello has been a leader in promoting information and communication technology accessibility since the 1980s. He helped launch the Web Accessibility Initiative (WAI), was an author on the first version of the Web Content Accessibility Guidelines (WCAG), and co-led the 2008 rewrite of the Section 508/Section 255 standards.

    He’s also the founder and president of The Paciello Group (TPG), a consultancy working with software companies to make their products accessible, which means he’s also Sarah’s boss.

    We wanted to learn from Mike about the making of accessibility standards, and whether future iterations might be more “user-friendly.”

    An early commitment to people and technology

    Michael Paciello is founder and president of The Paciello Group (TPG), a software consultancy concerned with web and software accessibility. Mike has been closely involved with information and communication technology accessibility since the 1980s and played a lead role in developing accessibility standards for industry and government. He helped launch the Web Accessibility Initiative (WAI) within the Worldwide Web Consortium, was an author on the first version of the Web Content Accessibility Guidelines (WCAG), and co-led the 2008 rewrite of the Section 508/Section 255 standards. From early in his career, Mike saw technology as a powerful enabler, and was compelled to make that potential available to everyone. “I feel an incredible obligation and responsibility to people—particularly, people with disabilities—and to technology.” His commitment is evidenced by his work.

    Mike began his technology career in the stockroom at Digital Equipment Corporation (DEC). At the time, DEC still had a paper-based process for managing stockroom transactions, which was somewhat ironic for a technology company. Curious and industrious by nature, Mike taught himself enough programming to design and build a stockroom inventory database, and he moved the stockroom processes online.

    Beginning to explore accessible electronic documents

    Mike’s talents were quickly recognized, and Mike moved to a new position as technical writer. As part of DEC’s documentation team, Mike was responsible for preparing technical guides for operating systems such as RSX, RT-11, and VMS, and software products written in COBOL, FORTRAN, Basic, and C. In this role, Mike became involved with making electronic documents accessible to blind and low-vision users.

    DEC had a long-standing relationship with the National Braille Press. DEC provided NBP with technical guides, which they converted to braille. This was before Graphical User Interfaces (GUIs), and computer interaction was text based. Text-to-speech was a relatively common and usable interface for blind and low vision users, and there was a demand for braille versions of operating system and software guides. At DEC, Mike volunteered as the liaison with the National Braille Press, and with this task, he began his quest to make information and communication technologies accessible for people with disabilities.

    “The moment I take something on, I want to really understand it and figure out what it’s all about.” What he learned in visiting the braille production facilities at National Braille Press was astounding. To convert the documentation, people retyped the text into a “braille typewriter” of sorts, and the text was then output to braille. Bear in mind that a single page of text equals about three pages of braille. “It would take them a year to produce one book.” The typical DEC documentation usually spanned several volumes and was regularly updated. “I asked, why not convert everything electronically? But they said there was no way to do that.”

    Mike’s interest was piqued. How to make large, complex documents usable and accessible generally, and specifically, how to provide usability to blind and low vision users? Fortunately, his timing was good. Mike started to explore electronic document accessibility right around the birth of the web.

    Markup languages bring meaning to electronic documents

    In the late 1980s and early 1990s, Mike started working with SGML. “I thought, how about we use a markup language on an electronic document, and then a braille translator can read the markup language and produce braille?” He also realized that accessibility for blind and low vision users meant more than braille—that large text and listening to text were also commonly used, and a markup language had the potential of providing accessibility in those contexts as well.

    Others concerned with accessibility were also exploring SGML. “Markup languages such as SGML were starting to become a common denominator for designing electronic documents for the blind and low-vision community.” At the first World Congress on Accessibility in 1991, Mike joined forces with colleagues to create the International Committee for Accessible Document Design (ICADD). This group created the first international specification for accessible electronic documents: ICADD-22. An “annex” to the ISO 12083 standard, it included 22 tags that could be used to map information elements in any document. ICADD-22 was to become an important contribution to the Web Content Accessibility Guidelines and accessibility elements in HTML.

    Accessible electronic documentation helps everyone

    Back at DEC, Mike was getting good support for his efforts. “Digital [DEC] was a fantastic company to work for because they encouraged that kind of emerging technology involvement.” Mike started a new program called the Vision Impaired Information Services. VIIS produced the first mass-produced CD-ROM of electronic documentation, built using SGML and the ICADD-22 standard. The documentation could be read by screen readers, magnified on the screen, and output to braille. He had come full circle, solving the challenge of converting DEC’s technical guides to braille that had set him out on this path.

    Interestingly, the VIIS CD-ROM also became popular in the sighted community. DEC’s standard documentation was available in a propriety format that could only be read using their Bookreader software. Since the VIIS documentation was built using SGML, an open, nonproprietary format, people soon realized they could read the guides using their preferred software. Sales for the VIIS documentation went up and began to adversely impact sales for DEC’s Bookreader version—another instance of design for disabilities benefitting everyone.

    A pioneer for web accessibility

    In 1995, Mike launched WebABLE, the first website dedicated to web accessibility for people with disabilities. The Worldwide Web Consortium had started up in 1994, and Mike got involved, creating the accessibility web pages for the W3C. He and other accessibility colleagues started an informal W3C working group called the Web Accessibility Project, focused on integrating accessibility into HTML. “The groundwork we started back then, in 1994 and 1995, ultimately became what most people know as the first Web Content Accessibility Guidelines.” They used the ICADD-22 specification and several documents including the University of Wisconsin-Madison’s Trace Center and WGBH’s National Center for Accessible Media (NCAM) web accessibility guidelines as the basis for extending HTML for accessibility. Since HTML derives from SGML, key elements were in the standard. However, none was connected to accessibility. “The alt attribute didn’t come out until later versions of HTML.”

    In 1995, Jim Miller and Tim Berners-Lee at the W3C asked Mike to help create a more formal and extensive accessibility effort within the W3C. “The conversation went something like, ‘We’ve been contacted by the federal government and asked to consider creating a formalized program in the W3C to deal with accessibility and disabilities. We would like you to do it. Are you interested?’” Mike, Jim Miller, and Daniel Dardailler of the W3C designed the program and named it the Web Accessibility Initiative, or WAI. In April of 1997, the initiative was announced at the Worldwide Web Conference in Santa Clara, California. By this time, Mike had been asked to direct the Yuri Rubinsky Insight Foundation (YRIF). Yuri Rubinsky, a well-respected advocate of SGML and accessibility, had been a close colleague and a key collaborator on ICADD-22 and the Web Accessibility Project. With WAI designed and launched, Mike continued his work with W3C on HTML specifications and the Web Content Accessibility Guidelines as Executive Director of the Yuri Rubinsky Insight Foundation.

    During the next years, Mike was involved with several accessibility initiatives, including the Section 508 working group in 1998, his own WebABLE site and consultancy, and the first book on web accessibility, Web Accessibility for People with Disabilities, published in 2000. In 2002, Mike launched The Paciello Group (TPG), a business specializing in web and software accessibility. He could see the lines blurring between the web and software and wanted to improve accessibility for both. “I was convinced that eventually everything on the desktop was going to move to the web—imagine that.”

    Helping set standards for web accessibility

    In 2006, the Access Board asked Mike to co-chair a new Section 508/Section 255 Advisory Committee. He and Jim Tobias led the effort to create a series of recommended guidelines that encompassed both Section 255, or the Disabled Persons’ Telecommunications Access, and Section 508. They also broadened involvement in the process to include international participation. The committee was composed of 41 organizations, from disability groups and technology companies, and included participants from Canada, Europe, Asia, and Australia.

    They took a different approach with the new guidelines. “We turned it from a product-based standard into a characteristic-based standard, so it would be completely platform neutral.” In addition, they broadened the guidelines to include themes from usability and interoperability, and to address concerns of other disabilities, including issues around cognition. The group benefited from the work on version two of the Web Content Accessibility Guidelines. They were able to incorporate WCAG standards in areas of Section 508 that pertain to the web. In April 2008, the group presented the new, improved Section 508 to the Access Board. As of this writing (in 2013), the new rules are (still) working their way through the federal rule-making process.

    From Mike’s perspective, the current process of creating technology and legal standards is flawed. “It takes years for the formalization and acceptance of standards.” He advocates a rolling process, where elements can be added and changed more readily to keep the standards viable. But Mike is hopeful about the potential impact of the new Section 508. Awareness about accessibility is at an all-time high, as is government recognition of the need for accessibility standards. Mike predicts that once the Section 508 standards become law, they will be used as “the model for all other major government mandates worldwide.”

    Meet Emily

    Posted on

    Emily is one of the personas from our book, A Web for Everyone. Personas combine research data from many sources into a fictional but realistic character. They are a great way to make sure your team considers the diversity of needs among visitors to your site.

    You can download an overview of all eight 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.

    Emily: Cerebral palsy, living independently

    A young woman in a motorized wheelchair, walks with a service dog.
    “I want to do everything for myself.”

    Emily is determined to do things for herself, so she’s tried a lot of different keyboards and joysticks over the years, looking for the right kind of interaction. Speech is difficult for her, so she uses a communications program with speech output.

    It’s slow for her to type with limited use of her fingers. She has stored many phrases and sentences, and can make the program speak for her more easily.

    The iPad turned out to be one of the best solutions. Mounted on the scooter, it’s always within reach, and touch works better than a keyboard and a joystick. In some situations, it can replace her older communications program.

    Instant messaging and social media have also been great. The short formats work well for her, and text can be a more comfortable way to communicate than speech. Her latest discovery is an app that scans the area to show her what shops and restaurants are in each direction. “I look like a dancing fool spinning my scooter around, but it saves me a lot of time finding someplace new.”

    Simpler screens are easier screens

    For Emily, simplicity isn’t just a nice-to-have, as she explains in Chapter 3. “I love having a tablet computer. It’s small enough to go everywhere with me. However, being small can also mean that the whole page gets small and crowded, and that makes it harder for me to use the site. I can’t tell you how often I’ve gone zooming off to the wrong link or couldn’t hit the right button. The ones I like seem to have everything in the right place. It’s like they read my mind and put the things I need on the screen when I need them.”

    Tell me what I need in advance

    It’s not that hard to delight Emily. Just don’t disappoint her, as happened in this story from Chapter 9. “When I go online, I just want to do things like everyone else. Most of the time, my disability doesn’t slow me down, but when you mix having to get around in the real world with online forms, it can be a perfect storm of annoying barriers. Today, I’m trying to sign up for a seminar at my college. Why can’t they tell me all the documents I’ll need before I start this process? I got the form filled out, but when I went into the office this morning, I discovered that I needed to bring other documents with me. The online form didn’t say anything about it. The whole trip was a big waste.”

    Snapshot of Emily

    • 24 years old
    • Graduated from high school and working on a college degree
    • Lives in a small independent living facility
    • Works part-time at a local community center

    The A’s: Ability, Aptitude, Attitude

    • Ability: Cerebral palsy, difficult to use hands and has some difficulty speaking clearly; uses a motorized wheel chair
    • Aptitude: Uses the computer well, with the right input device; good at finding efficient search terms
    • Attitude: Wants to do everything for herself; can be impatient

    Assistive Technology

    • Augmented & Alternative Communication (AAC) with speech generator
    • iPad
    • Scooter with joystick control

    The Bigger Picture

    Source: Harris Interactive/National Association on Disability, “The ADA, 20 Years Later” July 2010, United Cerebral Palsy/National Institute of Neurological Disorders and Stroke

    • 800,000 children and adults in the U.S. have one of the forms of cerebral palsy.
    • People with disabilities are often unemployed or underemployed. Among all U.S. working age (18–64) people with disabilities, only 21% are employed full- or part-time.


    Simple and Usable: An interview with Giles Colborne

    Posted on

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

    Photo of GilesGiles Colborne is co-founder of cxpartners, a design consultancy specializing in strategy- and research-driven approaches for designing websites and web applications. With a rigorous practice of user research and usability testing, cxpartners creates simple, easy-to-use designs, paying particular attention to global accessibility.

    In his book Simple and Usable: Web, Mobile, and Interaction Design, Giles teaches the art and science of achieving simplicity in interface design. We wanted to learn from Giles how accessibility can impact a simple, purposeful design approach, and vice versa.

    Simplicity is good science, and good interface design

    Giles comes to interface design from a background in science. As a physics student, simplicity was impressed on him as the mark of good science. “The whole purpose of the scientific endeavor is to pack reality back down into a handful of equations.” He credits his background for his enthusiasm for approaching a seemingly complex interface challenge and seeking the path to the simplest solution. “It doesn’t strike me as paradoxical, it strikes me as rather beautiful that you can do that.”

    In practice, most interfaces we encounter don’t reflect Giles’ enthusiasm for simplicity. “People make software very difficult to use by loading on features.” The result is software that requires its users to practice and reuse the tool before they are able to become proficient.

    Giles uses kitchen gadgets to illustrate the simple and usable spectrum:

    On the one end you have a kitchen you need to wade through because you have a specialist tool for every task. On the other, you have a powerful, flexible, general-purpose tool, but you have to put in thought and time to become proficient with it. When people design software they tend create specialist tools or general-purpose tools. What we need are tools that fall into the happy medium.

    Simple designs put complexity in its place

    In one project, Giles worked on improving the interface for a travel planner. The software tapped into a vast store of data, of places to see and things to do. Each item had layers of related and potentially pertinent information, such as location, time to get there, time needed to visit, hours of operation, and more. The wealth of data powering the travel planner would allow for incredible accuracy, allowing users to plan their travel down to the minute. “When we put the interface together, it totally bombed. The app was constantly saying, ‘You can’t do this, you can’t do that, you haven’t done enough of this.’ It was so hard to use, and so unforgiving.”

    Giles went back to the drawing board and reworked the fundamental approach. Rather than have the software identify possible options, he had users create lists of locations and places that were of interest to them. The computer didn’t try to work out whether or not the itinerary was practical—though it did give people enough data to figure that out for themselves, if they wanted to. “People are good at imagining the future. Computers are good at remembering stuff. By handing off the task of imagining to the user and the task of remembering to the computer, it all worked out.”

    The initial software approach was feature rich, and resulted in what Giles calls “a magnificent soufflé” of an interface, in keeping with his kitchen metaphor. In seeking the happy medium of simple and usable, he needed to adjust the overall approach to better fit the nature of the task. “The process taught me a powerful lesson about where complexity belongs, who should own it.”

    Observe real people to learn what’s needed

    Giles’ practice is informed by user research. From his perspective, it’s not possible to create effective designs without learning from people. “You can’t make safe predictions about how things are going to work until you engage with the audience.” And engaging with real people, not through imagined personas or user stories.

    People fall in love with pen portraits of their users. Not their real users—the users they’d like to have: young, attractive, happy, active, outdoorsy, not distracted, completely able-bodied. When you bring real users to the testing and design process, the reality is that there’s much more variability.

    Giles finds that some of the greatest insights come from studying how people work in extreme circumstances. For one project, Giles investigated how people with ADHD manage their condition as a way of understanding more broadly how to design for distracted users. “Everyone operates under some kind of duress that degrades their performance, and yet we design stuff in nice quiet offices and reflect on the design and interface and take a long time discussing something that a user needs to do in a fraction of a second.” By asking therapists how people with attention issues manage to keep focus, Giles generalized simple and usable designs that would work for anyone who was distracted when using the software.

    Giles also does a great deal of testing with users across the globe. “We haven’t tested in Antarctica yet, but we’ve tested pretty much everywhere else.” Testing with global users yields insights that also resonate with accessibility. For example, creating a design that can adapt when changing the language from English to Chinese. The design must be flexible enough to enlarge the Chinese characters about 20 percent, so the many small details in the characters are legible. “That sense of flexibility in presentation is at the core of what you’re thinking about when you’re thinking about designing for accessibility.”

    Designing for multiple devices supports accessibility

    Given all he has learned from observing global users with a wide range of abilities, Giles does not believe it’s possible to create a single design that works for everyone. “Everyone who has a disability comes up with their own method for accessing technology. You can’t say, ‘Disabled people do this’, or, ‘This is what’s happening.’ In the end, we need to fall back on generalities, and design solutions that work for the maximum number of people.” However, new design approaches might change his thinking.

    In the past years Giles has seen significant change in how design is done, in large part due to the diversity of devices and platforms. In the past he would have done detailed wireframes and mockups before handing the design over to be coded. Now, to accommodate the full range of devices, design involves creating information hierarchies rather than layout of pages. Instead of Photoshop mockups, prototypes are done in code, with designs and layouts that respond to different viewports. He believes this change in practice may move us closer to designs that are simple and usable, for everyone.

    As soon as you start to think about how navigation appears on a small screen, you start to focus on information hierarchies that also work well for accessibility. On a small screen you don’t want navigation, and then you scroll down and there’s content. You want content and then scroll down and there’s navigation. And of course that’s what you want for a screen reader as well.  This discipline of designing for multiple platforms and environments makes you start to think in useful ways about accessibility.