A Web for Everyone: Designing Accessible User Experiences (2013)
Sarah Horton & Whitney Quesenbery
▪ No matter your title or skills, you are probably a member of a team that brings together many skills and roles to the task of building products. And you are thinking about accessibility. For accessibility thinking, you need to understand how your work fits with the work of others on your team, and how your decisions and actions affect millions of people around the world who use the web.
▪ It offers a framework composed of accessible user experience principles and guidelines that will help you create websites and web applications that are accessible for everyone.
▪ It’s difficult to imagine a context in which one person could take a product, from soup to nuts, and make it accessible. There are so many decisions to be made, and accessibility must be considered at every step along the way. A designer or developer can’t make accessibility happen alone.
▪ If the decisions you make as part of your work impact someone’s experience of a digital product, you need to know how to make decisions that will not result in accessibility issues.
▪ Design includes all of the disciplines of UX and web design: information architecture, interaction design, information design, graphic design, and content strategy.
▪ The U.S. Census Bureau says that over 47 million Americans have a disability of some kind. The UN and the World Bank say this adds up to 650 million people worldwide. That’s around 10% of everyone in the world.
▪ At some point in our lives, disability will affect most of us, no matter who we are, especially as we get older. By the time we retire, over 30% of us will have some disability, even if it is minor.
▪ Working to standards and responsive design are both important criteria for accessibility. One way to think about accessibility is that assistive technologies, such as screen readers and alternate keyboards, are just another kind of device. When a site is designed to be flexible, it works better on all devices. C
▪ It sure is! There are many reasons why people have trouble reading: cognitive problems like aphasia or dyslexia, physical or vision disabilities, low literacy, or reading in a second language. But even skilled readers can have problems when they are rushed, tired, stressed, or reading on a small screen. Accessible content is written in plain language (Chapter 8) and presented clearly and flexibly (Chapter 7).
▪ WCAG 2.0, the Web Content Accessibility Guidelines, is a standard published by the W3C. That means it was created with input from people around the world and reflects the best international consensus.
▪ Section 508 is a national regulation in the United States. Other countries and the EU have their own laws and regulations.
▪ But if you are thinking about accessibility for other reasons, WCAG 2.0 is the place to start. It’s a robust standard that is flexible enough to apply in different contexts—websites, desktop apps, mobile apps, even web-enabled teakettles can be measured against the WCAG success criteria.
▪ The good news is that most standards are very similar. The even better news is that the U.S. Access Board (the folks who manage Section 508) has proposed that the next version of Section 508 will use WCAG 2.0 Level AA as its requirements for web content.
▪ The EU is also working on new accessibility regulations, and we’ve been told that they, too, will be based on WCAG 2.0 Level AA. We have our fingers crossed, because in today’s global technology world, it would be great to have one standard for web accessibility.
▪ Design isn’t simply about how something looks. A good design is visually appealing but also meets real needs, has substance and depth, and works well and intuitively.
▪ Designing is an activity. When you make decisions about a product, and your decisions impact the lives of its users, you are designing—whether you think of yourself as a designer or not.
▪ The strategist defines the purpose and goals, the interaction designer focuses on how users will interact with the product, the visual designer creates the look, the content strategist gives the product a voice, and the developer makes everything work. Whatever the title and task, all of these roles are engaged in the activity of design.
▪ When we talk about design, we mean it in this larger sense: the umbrella over all the skills and disciplines that contribute to the user experience.
▪ No matter what your roles or skills are, it’s important that you—that all of us—own the term “design” because it comes with incumbent responsibilities, which we need to own as well.
▪ Like usability, accessibility is a quality—in this case, it means how easily and effectively a product or service can be accessed and used. Physical and cognitive ability occur along a spectrum. Everyone has a limit as to what they can physically accomplish and intellectually comprehend. Good accessibility is designed for the full range of capabilities, as well as for the context of use or environmental constraints.
▪ As Ben Shneiderman put it in his book, Leonardo’s Laptop, technology must be designed to include people with “new or old computers, fast or slow network connections, and small or large screens, ... young and old, novice and expert, able and disabled, ... those yearning for literacy, overcoming insecurities, and coping with varied limitations.”
▪ The terms universal design, inclusive design, barrier-free design, humancentered design, and design-for-all are all concepts that strive toward a common goal: to make the user experience the first concern in making design decisions and to expand the description of users to include a wide range of human ability.
▪ Our goal with this book is an approach that encourages design for everyone, where accessibility is not approached as a last-minute checklist of additions that are piled onto the product, but rather a set of features that are designed in place from the start.
▪ To construct this framework, we stand on the shoulders of giants, building on three important bodies of work: the Web Content Accessibility Guidelines, the Principles of Universal Design, and design thinking.
▪ The W3C Web Accessibility Initiative (WAI) develops web accessibility standards and guidelines for web and software developers. The two most important are the Web Content Accessibility Guidelines (WCAG 2.0) and the Accessible Rich Internet Applications (WAI-ARIA) standard.
▪ The WAI also provides guidelines for developing web authoring tools (ATAG) and software, like browsers and media players (UAAG).
▪ The WAI also hosts a great number of educational resources, including the very helpful document, “How People with Disabilities Use the Web” (www.w3.org/WAI/intro/people-use-web/).
▪ The Web Content Accessibility Guidelines (WCAG 2.0) are organized under four foundational principles, which conveniently form the acronym POUR:
• Perceivable: Information and user interface components must be presented to users in ways they can see or hear.
• Operable: User interface components and navigation must be designed so that users can interact with them and they can support assistive technologies such as screen readers.
• Understandable: Information and the operation of user interface must communicate clearly and consistently so that the content is readable.
• Robust: Content must be written so that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
▪ Principles of Universal Design
In 1996, a group of designers, architects, and rehabilitation engineers developed a set of principles to support the universal design approach. The approach was based on a philosophy articulated by Ron Mace, an architect, disability rights advocate, and founder of the Center for Universal Design at North Carolina State University.
▪ Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.
▪ You can read the complete universal design principles and supporting guidelines at the Center for Universal Design at http://tinyurl.com/the-principle-of-universal-des.
▪ Divergent thinking: Imagine possibilities without constraints. All too often, accessibility solutions come down to code, without consideration of whether the overall design approach is the right one.
▪ In many cases, accessibility is often considered only at the end of the development process, typically during quality assurance or even after launch. Resolving accessibility issues on a finished product often yields unsatisfying solutions, for the designer and the user—the digital equivalent of a wooden ramp stuck on the side of a beautiful building.
▪ The principles in this book are built on:
• The World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG) 2.0, a standard for coding accessible websites. WCAG 2.0 is also the basis for national regulations in the U.S., the U.K., the European Union, and elsewhere. WCAG 2.0’s POUR principles provide the foundation for web accessibility guidelines and best practices.
• The Principles of Universal Design, seven principles for creating architectural spaces, industrial design, and digital products that work for the widest range of human abilities
▪ It can be hard to think about using the web in ways that are different from your own experience. Your assumptions about use are based on your own experiences with social and work contexts, cultural norms, individual preferences, and your physical abilities.
▪ User experience—including usability and accessibility—starts with users. As Whitney Hess eloquently put it in her blog, Pleasure and Pain, “If you design entirely based on intuition without ever gathering intel from a single human being who might at some point in their life come into contact with your business, I’m sorry, but you just aren’t a user experience designer.”1
▪ Those are strong words, but this can’t be said strongly enough: You have to know the people you are designing for. And that includes people with disabilities.
▪ User research or usability testing is not just something you do once and check off your list. Keep users in mind throughout the project, using all the UX techniques at your disposal, from early interviews, personas, scenarios, and usability testing.
▪ People with disabilities are as varied as any users; they come from a variety of backgrounds and have varied interests, likes and dislikes, goals and skills. They have different experiences, different expectations, and different preferences. They use different interaction techniques, different adaptive strategies, and different assistive technology configurations.
▪ 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.
▪ Screen reader (JAWS on his laptop, VoiceOver on his phone)
▪ 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.
▪ 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.
▪ Assistive Technology
• Contrast adjustments
• Screen magnification software
▪ To see what the world looks like with one of nine degenerative eye diseases, download VisionSim from the Braille Institute (for iPhone, iPad, Android) http://brailleinstitute.org/MobileApps/VisionSim.aspx
▪ 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.)
▪ Not many products are able to stick to a singularity of purpose—it takes restraint on the part of the designer and the consumer. It’s easy to fall into the trap of creating multi-featured tools, like the Veg-O-Matic: “It slices, it dices! But wait, there’s more!”
▪ Sites can be less complex and confusing. Pages with many different “calls to action” and competing content can be especially difficult for people who have difficulty focusing or an attention deficit disorder.
▪ Design for universal usability is an excellent way to arrive at a clear purpose. You can focus on necessary features, avoiding elements that are not essential to the product purpose.
▪ All too often, teams dive into a project without a clear idea of its purpose and goals. They start knowing the site will have a shopping cart, video, or social media, and then dive into designing the site without first knowing its core mission.
▪ When considering the purpose and goals, focus on audience goals rather than business goals. In most cases, using a product isn’t a goal in itself, so dig deeper and see what needs it will meet. For example, “use social media,” is not a user goal, but rather “connect with my friends,” or “let the world know what I’m doing,” or even “tell my family that I’m on my way home.”
▪ It’s easy to get excited about technology ideas or get bogged down in lists of features. But teams that work from a shared understanding of the clear purpose for a product make better decisions about features and functionality
▪ In his book Simple and Usable, Giles Colborne identifies four strategies for simplicity:
• Remove: Get rid of unnecessary elements until the product has only the essentials.
• Organize: Arrange the elements on the screen so that they make sense.
• Hide: Move any elements not essential for mainstream use so that they do not clutter the screen.
• Displace: Consider whether any elements or features can be handled offscreen, either in a different part of the site, on a different device, or by users themselves.
▪ You can see a video of Luke’s talk about his approach from the LinkedIn Tech Talk series at www.lukew.com/ff/entry.asp?1137 or read his book, Mobile First.
▪ Designing for Mobile Helps Focus on What Matters
As the web moved to smaller mobile devices, designers like Luke Wroblewski saw an opportunity to shift the paradigm and make a move toward simplicity. Websites can be flexible. You can add menus, link in new pages, and add more widgets pretty easily, especially compared to older software engineering. As screens got bigger and the Internet got faster, optimizing a site was not as big a problem. That led to feature creep. Instead of being even more rigorous about what is important enough to get space at the top of the page, pages got bigger and the text got smaller, to cram more onto the screen. Something had to give.
▪ Luke suggested that design start with “mobile first.” Instead of trying to cut down a large website, you can use the constraints of a small screen to make the hard decisions about how to use the precious real estate on a mobile screen. The discipline required to build a good mobile experience also forces you into a simpler approach overall, without unnecessary complexity and with important information first.
▪ added a few features to make the site accessible:
• Accessible color contrast meeting WCAG AAA
• Better keyboard handling with visible focus
• Link hover and active states so it’s easier to see
• Skip to content links at the top
• Headings for sidebars to help identify the content
▪ Accessibility is not black and white, on and off.
▪ You should aim for full accessibility, but when you hit roadblocks, it’s helpful to think about a range of approaches, listed here from most to least desirable.
• Universal (or inclusive) design—one site. Everyone has the same means of use, with elements that work for everyone, no matter what interaction mode is chosen. The goal of this book is to help you create universal or inclusive websites and apps, so no one is left out of the experience. For example, a video with captions and video description and an accessible video player lets everyone watch the same video.
• Equivalent use—includes alternatives. Products contain similar ways to meet the same goals but present them in different ways. For example, a transcript for an audio file has the same information, but someone reading the information has a different experience than someone listening to the audio.
• Accommodation—a separate “accessible” version. Accommodation is disability-speak for working around a barrier without removing it—“separate but not equal.” Accommodations like a “text only” version are not acceptable. It’s not okay to create a separate design—one that delivers a separate and degraded experience—for people with disabilities.
▪ But you can also look at the fact that there is a robust API. There are many programs that help people work with Twitter in their own way. In this view, Easy Chirp is just another variation for people with particular needs.
▪ Thinking about accessibility from the beginning—“Accessibility First”—is similar to the approach of thinking “Mobile First” to ensure that the design works as well in a screen reader as it does on a small screen.
▪ There are three approaches to accessibility:
• Universal design aims for a website or app in which the same design and content elements work for everyone, no matter how they interact with the web.
• Equivalent use focuses on ensuring that each mode of interaction—visual or auditory, tactile or keyboard, for example—has an equally good experience.
• Accommodation is the least desirable, because it creates a separate—and usually unequal—experience.
▪ 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, with supporting details about location, time to get there, time needed to visit, and hours of operation. “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.”
▪ The computer didn’t try to work out whether or not the itinerary was practical—it gave people enough data to figure it out themselves.
▪ 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 process taught me a powerful lesson about where complexity belongs, who should own it.
▪ Giles’ practice is informed by user research. “You can’t make safe predictions about how things are going to work until you engage with the audience.” And that means 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.
▪ For one project, Giles researched 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.
▪ Giles does international testing, which also yields insights that resonate with accessibility. A design that can adapt from English to Chinese must handle enlarged text, so small details in the characters are legible.
▪ “That flexibility in presentation is at the core of what you’re thinking about when you’re thinking about designing for accessibility.”
▪ Giles has seen significant change in how design is done, due to the diversity of devices. Instead of detailed wireframes and mock-ups, now he starts with information hierarchies.
▪ Instead of creating Photoshop mock-ups, prototypes are done in code, with designs and layouts that respond to different viewports.
▪ This change in practice may move us closer to designs that are simple and usable, for everyone.
▪ The digital environment does not currently have an equivalent to the rigorous building codes and legal requirements of civil engineering and architecture.
▪ As we all come to appreciate the impact of digital products on health, safety, and general welfare, we are likely to see more interest in standards and certification in this area.
▪ For websites and applications, “structural integrity” means software that does not break or have system failures. It also means a site that does not break in all its different contexts of use, including all the ways that users can customize their own experiences.
▪ Although websites are created for people, every web page requires code. Tim Berners-Lee conceived the Internet as “a web of data that can be processed directly or indirectly by machines.”1
▪ Machine-readable data is what makes the web so powerful.
▪ People routinely use websites on different devices—from large screens to tiny ones, and on different operating systems—from Windows to iOS. Assistive technology is just another device.
▪ People also interact with sites in different ways. Touch, keyboard, audio, and speech are all useful at different times. A strong structure allows consistency and flexibility across devices and interaction modes so that everyone has an equitable experience.
▪ No matter how well you do your design research, you cannot design for every person in every situation. When the product is designed to be flexible, it allows users to customize the display and interaction without breaking the design.
▪ Web accessibility relies on the software’s ability to read and understand the content and instructions contained in web pages. When the code includes all the markup and tags to communicate meaning accurately, the information on the page is programmatically determinable, and a browser or other device can read and act on it.
▪ Elements in a web experience that the software cannot read produce barriers, which are indecipherable and therefore inaccessible. The more “meta” information you can provide, the better the user experience will be, since software can do more with information it can parse and act on (see Figure 4.1).
▪ There are two organizations that provide important support and guidelines and best practices to help ensure that sites have a solid structure.
▪ HTML (Hypertext Markup Language) Language for describing the structure of a page, including semantic information, for including interactive links and forms, and for embedding media elements such as images and video. www.w3.org/html/
▪ CSS (Cascading Style Sheets) Language for describing the presentation aspects of a page, including color, type, and layout. www.w3.org/css/
▪ JavaScript (officially known as, ECMAScript) Scripting language for providing interaction and dynamic content. www.ecma-international.org/
▪ WCAG 2.0 (Web Content Accessibility Guidelines) Guidelines and techniques for making websites and web applications accessible to people with disabilities. www.w3.org/WAI/
▪ WAI-ARIA (Accessible Rich Internet Applications Suite) Framework for adding attributes to web documents in order to make actionable elements accessible to people using assistive technology. www.w3.org/WAI/intro/aria
▪ However, accessibility has many subjective aspects that cannot be fully tested by software. You can use accessibility checkers as a tool, but you should not rely on the results to ensure accessibility. (See the list of validation tools in Appendix C, “More Reading,” and in Provide tools and assistive technology for ongoing evaluation in Chapter 11, “In Practice.”)
▪ Web Accessibility Initiative (WAI): A project of the Worldwide Web Consortium (W3C). WAI produces guidelines for accessible websites and web applications, notably:
• Web Content Accessibility Guidelines (WCAG)
• WAI-ARIA, the Accessible Rich Internet Applications Suite
▪ WAI also produces guidelines for software that accesses websites and web applications, and for software used to build sites and apps:
• User Agent Accessibility Guidelines (UAAG) for web browsers and media players
• Authoring Tool Accessibility Guidelines (ATAG) for software that creates websites
• A new WAI project, IndieUI (Independent User Interface), is working to create a device-independent way to communicate user actions, such as scrolling, to a web application.
▪ Using W3C and WAI guidelines and techniques is a roadmap for building accessible websites and web applications (www.w3.org/wai).
▪ The Web Standards Project (WaSP): An advocacy group of leading designers and developers “fighting for standards that ensure simple, affordable access to web technologies for all.” For its 15 years, WaSP had a significant impact in getting browser software to do away with custom code and instead support standard technologies, which in turn has allowed developers to code to standards. This project shut down in March 2013, saying that its work was done, and it was time for everyone to ensure that the web remains free, open, and interoperable (www.webstandards.org).
▪ In visual design, pay attention to where elements appear, featuring important information prominently, near the top, and putting more incidental information at the bottom of a design. Location matters in visual communications, along with other factors such as size, color, and alignment.
▪ In source code, order, or the sequence of elements in the code, influences how software reads a page and, in turn, how well software conveys information to the user. Web browsers generally—and screen readers, in particular—start reading at the top of a page and read through the code sequentially. The order of the source code makes a difference to search engines, too.
▪ You should also make sure that the sequence of related elements is not broken by unrelated elements.
▪ Consider how elements that are closely related are sequenced. For example, a label for a text input field should appear in the code before its input element (as well as being connected to it by using the label tag), and an image caption should appear in the code after its image.
▪ Wikipedia puts the page content in the code before the top and side navigation, where assistive technology can read it first. http://en.wikipedia.org/wiki/Jelly_bean
▪ You can use sectioning markup for main sections of the page, such as the HTML5 tag or the ARIA attribute role=”navigation” to mark site navigation. Be sure to use sectioning markup wherever possible to improve the readability and navigability of your code. (Table 4.2 and Provide clear landmarks within the page in Chapter 6, “Helpful Wayfinding,” have more details on using sectioning markup.)
▪ The architecture of a web page has two layers: content—the text, images, tables, lists, and so on—and presentation, which includes the color, font, layout, and so on. The content layer is typically contained in the HTML code.
▪ The correct standards way of specifying the presentation layer is with Cascading Style Sheets (CSS). Using CSS, all of the information about how to present the page is stored in a separate file, which can be used by many web pages.
▪ The site can adjust to different displays or screen sizes, either with alternative presentations in the stylesheet, or by substituting one that is more appropriate for the display. Print stylesheets, for example, can set up a page for printing. Using a stylesheet also makes it possible to customize the presentation without breaking the site. Users can set their own colors, font size, or layout to match their own preferences or visual needs.
▪ The customization enabled by using CSS can be as simple as making the text larger, or as extreme as a whole new look. Figure 4.3 shows how one site can have very different looks.
▪ Search engine software reads and catalogs a document based on determinations about subject and focus. It reads the title as a strong indication of the topic of the page, and it gives text tagged as headings more weight than other text. The inclusion of these semantic tags, and , improves the software’s accuracy in cataloging, which, in turn, improves your ability to find what you are looking for when using search.
▪ In the 2012 WebAIM survey of people who used screen readers (webaim.org/projects/screenreadersurvey4/), 61% reported that the first thing they did on a page was to scan the headings using the navigation tools in their assistive technology
▪ As the design begins to take shape in the form of sketches, models, and wireframes, take the time to consider whether the emerging user experience concepts lend themselves to coding to standards, and thus to good accessibility for your users.
▪ Taking the time at the beginning to consider the impact of technical decisions will result in fewer problems later in the project when structural flaws are more difficult and costly to repair.
▪ A site with solid structure meets Guideline 4.1: Maximize compatibility with current and future user agents, including assistive technologies.
▪ 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.”
▪ Many people use these Amtrak ticketing machines and never notice the EZ Access options, but they are there for those who need them. Source: http://trace.wisc.edu/ez/
▪ By adding tactile buttons and an audio interface, EZ Access makes touchscreens easy to operate for everyone, including people who can’t see.
▪ Even better, the EZ Access features are unobtrusive—they are available for those who need them, but do not get in the way of those who don’t.
▪ Creating websites and web applications that people can use might seem like a no-brainer, but it’s not an easy task. With the myriad technologies that can be used for building, different devices and software for accessing, different modes of interaction, different user needs and preferences, it’s a complex environment for creating sites and apps that don’t break. And then there’s the pace of change!
▪ In Chapter 4, “Solid Structure,” we talked about the importance of producing websites and web applications that software, including assistive technology, can read. Now, we’ll look at how people interact with websites, and what is needed for accessibility.
▪ Sites don’t create barriers, or sites make barriers easy to overcome. The worst barriers keep someone from using a site at all.
▪ Designs work for people. When things work well, we hardly notice them. That’s why bad designs are so annoying and frustrating. CAPTCHA1 is an example of a perfect storm of bad interaction—hard for everyone to use, not just people with disabilities. CAPTCHAs try to make sure that a real person (rather than software) is filling out a form, so they display a code word in distorted letters. The idea is that robots or other software can’t read the letters, even using character recognition. To make them accessible, CAPTCHAs can include a distorted audio version that is also supposed to be undecipherable by software. Unfortunately, both the visual and audio distortions are difficult for many people, even with good eyesight or hearing. People may have difficulty separating sounds from background noise or spelling words with difficult letter combinations. Ironically, CAPTCHAs aren’t even very effective—a spammer can pay for keys to break them for under a penny each.
▪ People can choose their own way to interact with a site. Some disabilities impact dexterity, making it difficult to respond quickly or to operate some kinds of controls. For example, some people work best with tactile controls—buttons and other controls they can feel—while others work best with pointing devices. All of this adds up to giving people the ability and means to control their own environment, the time and space to work at their own pace in their own way, and the software and hardware that works best for them.
▪ Success in interaction design is largely a matter of following established patterns, so people can apply what they already know to new contexts. Using known and well-established interactive controls goes a long way in designing for easy interaction.
▪ There are specific considerations that will help make controls more usable for people using assistive technologies. And there are design considerations that make interaction more usable and enjoyable for everyone, including people with disabilities.
▪ Interactive elements should be easy to distinguish from other elements on the page. For example, links and buttons can be identified in the following ways:
• Visually. Links are often colored and underlined, and buttons are identifiable by shape.
• In code. Link and button markup codes distinguish these elements, making it possible for browsers to identify them.
• Through interaction. Links and buttons can show their state, such as when they are active, through changes in their appearance. They can also be accessed through the keyboard or in lists of interactive elements constructed by assistive technology.
▪ ARIA provides codes you can use to identify and describe interactive components like an accordion widget programmatically so that assistive technology can communicate information about the component to users. For example, in the case of an accordion widget, the “aria-expanded” attribute can be set programmatically to “true” or “false,” depending on the state of the component.
▪ The OpenAjax Alliance (www.oaa-accessibility.org) provides examples and downloadable code for many common design patterns, including an accessible accordion widget. (www.oaa-accessibility.org/examplep/accordian1/)
▪ ARIA is helpful for other interactions as well. For example, in the sample sign-up form, shown in Figure 5.3, error messages are coded with the attribute role=”alert” so that the helpful in-line error messages can be announced to screen reader users.
▪ FIGURE 5.3 In this sample account sign-up form, alerts are identified programmatically using the ARIA role attribute.
▪ The websites for financial service companies often include complex financial information, including real-time data, price charts, and information to help investors manage their money. The guidelines below are excerpted from Ann Chadwick-Dias and Marguerite Bergel’s work with product development teams to make sure that their applications are accessible, especially for older customers managing their retirement funds.
▪ 1. Clearly indicate and manage focus.
• Ensure users can visually track their focus when keyboard navigating.
▪ 4. Progressively reveal content.
• Draw attention to changes (fading colored backgrounds, data loading indicators).
▪ • Change content downstream of users’ focus.
▪ • Use large click, grab, tap, drop targets. Wrap supporting icons in adjacent text links.
▪ • Don’t make controls too sensitive, requiring fine motor control.
▪ • Don’t auto-play A/V content or loop animations users can’t control.
▪ • Warn users in advance if links launch A/V content.
▪ 7. Respect users’ settings
▪ • Make fonts responsive to browsers’ text size controls (e.g., IE’s View>Text Size).
▪ • Ensure that content wraps and containers adjust as font sizes scale.
▪ It’s not the details of the interaction itself that create the barrier, but how it is structured in the code and presented to users. A simple rule of thumb is to design the page so that any changes made after it loads the first time happen “downstream” of the cursor.
▪ The location in the code makes a real difference to the accessibility of forms and error messages. For example, as a user fills in a form, the code checks each entry to be sure it is valid. It might check to see if a username is available. But, if feedback is displayed above the field, the assistive technology doesn’t see the change, and it simply proceeds to the next field.
▪ So as you are designing forms, you should make sure that any interactive feedback appears both in the code and on-screen in a way that makes sense when linearized.
▪ Sequencing also matters for instructions. Sometimes, forms are coded so that instructions and labels appear after the form fields and buttons. Users (and assistive technology) have to read ahead to determine the purpose of each field and then backtrack to fill in the field.
▪ Be sure that the elements in a form follow a logical sequence: identify and describe an element before the interaction, both visually and in the code.
▪ Instructions and labels that appear inside the field are problematic because they disappear when the field is activated. Users who need to look at the keyboard as they type will miss the hint entirely
▪ The point-and-click interaction model popularized by the mouse is not universally usable. Nonvisual users cannot see to point the mouse. People with dexterity issues may find mouse operations awkward and cumbersome. Some alternative input devices work by activating keyboard commands instead. Also, some people find keyboard control easier, more comfortable, and more efficient than pointing.
▪ In Chapter 4, we talked about how the code order affects linear access to web pages in Organize code for clarity and flow. Code order has a significant impact on keyboard navigation, especially when using the tab key to cycle through actionable elements (interactive controls like buttons and links) on the page.
▪ Tabbing is a common navigation approach for keyboard users, similar to how mouse users will look for and click on links and controls. Keyboard users will press the tab key repeatedly until arriving at the desired element and then press Enter to activate the control.
▪ With standard web pages, tab order is based on the sequence of elements in the code order
▪ Hover: Some devices do not support hover, such as touchscreens—hover all you want over a touchscreen, and nothing is going to happen! Hover actions can also be annoying when they are triggered inadvertently, such as when a menu is displayed simply because the mouse pointer crossed it on the way to another part of the screen. Hovers can also be distracting to people with cognitive or attention disabilities.
▪ Supporting keyboard interaction doesn’t mean that you can never use complex interactions like drag and drop. Just make sure that all interactions have an option that does not require pointing.
▪ With the success of VoiceOver, other companies are also building accessibility into their devices, although none have reached the level of VoiceOver. What’s new, even revolutionary, about these features is that they are built into the platform operating systems, so they can be turned on and off without any special hardware or software.
▪ When accessibility features get this easy, they start to become universal design. Both VoiceOver and Explore-by-Touch allow eyes-free use of the device for anyone whose eyes are otherwise occupied. Siri and other voice activation features are innovative uses of voice technology that let everyone interact with their devices easily.
▪ FIGURE 5.5 This feature, collecting bookmarks for related items, requires a mouse to drag and drop items into the list. A simple Add button would make this more accessible.
▪ Keyboard users also benefit from a clear indicator showing which element currently has focus. Browser software supplies a default focus indicator—typically a dotted outline around the element. However, keyboard usability can be improved by using CSS to provide stronger visual cues to help users make deliberate choices about which elements to interact with.
▪ Controls on-screen may not be three dimensional, but users still need dexterity to operate them. Physical issues from arthritis to tremors can make it hard to accurately use a control, but so can context like working on a crowded airplane without enough elbow room, or even wearing gloves.
▪ People navigating the web using a touchscreen mobile device can run into difficulty trying to, for example, select one of a set of radio buttons, or click a submit button.
▪ Even responsive sites may not take into account the differences in size between a pointing device and a fingertip.
▪ Minimize the fine-motor skills needed for interactive elements. Make buttons and touch points large enough.
▪ Space controls. Put enough space between controls so that users don’t accidentally activate the wrong one.
▪ Minimize the complexity of the action required. Choose controls that do not require timing or managing multiple actions when possible. Watch out for controls like multi-level menus that require a steady hand to operate.
▪ Try to avoid making changes that are not triggered by an explicit user request. For example, the “carousel” of highlighted stories on a home page typically advances automatically, based on an estimation of time needed to get through the content.
▪ A better approach is to load the first image and provide clear controls for advancing through the stories. This applies to all moving elements, including media such as video and audio. Don’t play media automatically. Instead, wait for users to elect to play the media. Autoplay is not only distracting, but can also cause problems for people in a quiet setting or using a low-bandwidth connection to the web (such as a weak mobile phone signal).
▪ Like the fire protection and emergency exit systems of a building, digital products must also be built so that when something does go wrong, harmful effects are minimized or prevented through error response and recovery.
▪ Defensive Design
37signals defines defensive design as “design for when things go wrong.” In their book, Defensive Design for the Web, they define four ways defensive design supports users and helps them recover:
• Validates data to check for mistakes before they frustrate the user.
• Expands available options based on the user’s implied intent.
• Protects site visitors from server errors and broken links with informative messages.
• Assists the user before mistakes happen.
▪ There is no such thing as a fail-safe system. No interface is intuitive to every user, and no user is on target every time.
▪ Designing for contingencies is about using design to minimize the impact of errors and system failures when they can’t be avoided.
▪ For example, you should support users who are submitting information, ordering a product, or posting a comment.
• Provide a review page. Allow users to review their input before submitting.
▪ Provide a confirmation page. When the information is submitted, confirm the transaction and provide instructions about making any additional changes. Confirmation pages not only provide a nice ending to the interaction, but they also work as conversation:
User: I’d like to place an order. Here’s all my information.
Your site: Thanks. Got it. We’ll send this to you within three days.
▪ Good communication can also make the system easier to operate and to avoid errors. For example, if the system requires a specific date format, provide an example date right before the input field.
▪ If an error does occur, provide helpful and accessible feedback in response to input errors. The feedback should appear with the element containing the error, and should provide clear instructions for how to correct the input, as shown in the sample sign-up form in Figure 5.3.
▪ Design and development collaborate on easy interaction. It is possible to create interactions that are both innovative and accessible, but it takes coordination. Working together to come up with ideas and ways of coding the design can take experimentation, prototyping, and cleverness in solving problems.
▪ When the design team understands what’s possible within the constraints of the medium, and the developers understand what’s required for universally usable interaction, the results are more likely to be accessible for everyone.
▪ • 2.1 Keyboard Accessible: Make all functionality available from a keyboard (Guideline).
▪ • 2.4.3 Focus Order: Elements on the page receive focus in a meaningful order (Level A).
▪ • 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible (Level AA).
▪ • 3.2.1 On Focus: The context does not change based only on a component receiving focus (Level A).
▪ • 3.2.2 On Input: The context does not change when a setting is changed, unless the user has been advised of the behavior before using the component (Level A).
▪ • 3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes (Level AAA).
▪ • 3.3.1 Error Identification and 3.3.3 Error Suggestions: An item with an error is identified and the error is described to the user in text (Level A) and with a suggestion (Level AA) when possible.
▪ • 3.3.2 Labels or Instructions: Labels or instructions are provided when content requires user input (Level A).
▪ • 3.3.4 and 3.3.6 Error Prevention: Actions that submit information are reversible and checked for all (Level AAA) or for legal and financial transactions (Level AA).
▪ The full text of the WCAG 2.0 requirements can be found in Appendix B.
▪ Making the interaction easy for people with disabilities is an extension of making interaction easy for everyone. Interactive elements are identified clearly and are designed to be easy to use.
▪ “Our entire team views accessibility as part of overall user experience and not as a separate thing that needs to be done afterwards.”
▪ However, in practice, clients 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. “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.”
▪ One of the most important things to achieve success is to have all accessibility touch points built into the process right from the beginning.”
▪ Derek and his colleagues have had good success providing teams with tools that make it easier to build accessible products. One tool is an accessibility guide, integrated into the organizational style guide or branding guide.
▪ Another is a code repository and pattern library containing elements like modal dialogs or tool tips that can be easily dropped into code. “One of our goals is to eliminate excuses. We think about all the different pressures people feel when building a site and try to address them.”
▪ 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. Her greatest challenges were radio buttons and checkboxes, which were too small for her to activate accurately. Derek created a stylesheet she could install in her browser that would resize radio buttons and checkboxes ten times the size they normally appeared.
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.
▪ In both the online and physical world, people rely on familiar patterns to help them find their way more easily. A mix of conventions and experience helps everyone locate cues in either the physical environment or an online interface, using the design of directional signs or interaction features like menus, buttons, and links. When these features are easily found where they are most expected, it takes less effort to use them. Table 6.1 compares the tools for wayfinding in the online and real worlds.
▪ Conventions for the placement of signs help people find them easily. There are often local standards, but they may vary. Conventions for the placement of types of links or features help people find them easily, but there are no global standards.
▪ Wayfinding includes both navigation (features that let users move around the site) and orientation (identifying the current location). A site with way-finding that works well for both visual navigation and all kinds of assistive technology makes the online environment usable for everyone.
▪ With helpful wayfinding, people can navigate a site, feature, or page following self-explanatory signposts.
▪ People tend to navigate partly by using the cues they experience in real time and partly by using a cognitive map, or mental construct, of the space (real or digital) they are navigating. Even small variations can be disorienting.
▪ One way to help users find their way around a site is to be consistent in how elements of the site are presented and labeled, which doesn’t mean that the site must be boring with no variation or texture. However, elements of the site that form important landmarks should be consistent:
▪ Describe or label the same thing in the same way each time.
▪ Research with older adults found some distinctly different patterns in how they interacted with websites.
• They were “cautious clickers” who spent more time reading before deciding to click on a link.
• They were more likely to try to click on text that was not linked, hoping that it would let them find the information they wanted.
• They had more difficulty understanding where they were within a site. For example, they would click on the current page link in the left menu.
▪ Web Usability and Age: How Design Changes Can Improve Performance” by Ann Chadwick-Dias, Michelle McNulty, and Tom Tullis. http://dl.acm.org/citation.cfm?id=957212
▪ • The text of the link and the title of the target page should be similar, if not identical.
▪ Highlight the current location. There are many ways to identify where a page fits into a site, from the page title to highlighting the menu item for the section to breadcrumb navigation.
▪ When describing the interface, avoid using details like color or even location on the screen as the only cues in the instructions. Directions like “in the upper-left corner” don’t mean much to someone navigating by audio. It’s okay to use color and location along with other nonvisual cues: “The blue link labeled ‘Contact Us’ in the upper-left corner.”
▪ One way to provide a navigation map of the page is to use links that jump to specific areas of the page. These are often called skip links because they let a site visitor skip over sections of the page to go directly to key locations on the page. This is especially important as a way to skip over repeated blocks of content, like the links and logos in the heading of the page (see Figure 6.1).
▪ For example, screen readers provide controls to move focus among the sections, which lessens the need for skip links as a way to bypass blocks of content. By coding boundaries around elements, you create clear landmarks that do not rely on visual properties, such as outlines or background color.
▪ It’s important to reiterate: there is no one way to provide accessibility. The solution instead is to provide alternatives. For helpful wayfinding, this means offering different navigational options.
▪ Most sites include more than one way to move around the site: menus, links, a sitemap, or search. Providing alternatives improves the chance that people will find what they are looking for.
▪ • 2.4.8 Location: Information about the user’s location within a set of web pages is available (Level AAA).
▪ Wayfinding relies on being:
• 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are (Guideline).
• 3.2 Predictable: Make web pages appear and operate in predictable ways (Guideline).
▪ • 2.4.1 Bypass Blocks: Users can bypass blocks of repeated content (Level A).
▪ You tend to find back-end coders developing front ends without understanding what makes a user interface usable, let alone accessible.
▪ 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.”
▪ “Clean,” “elegant,” and “simple” are all words that describe the impact of a design with a clean visual presentation. By contrast, designs that are “cluttered,” “busy,” or “garish” don’t seem as easy to understand and use.
▪ A clean, clear visual design helps everyone make sense of the information and functionality of a website or web application. Cluttered or complex pages are difficult for everyone to use effectively, but pose extra challenges for people with disabilities.
▪ For example, people who use assistive technology, such as enlarged browser displays or screen magnification software, only have access to a small viewport at any one time. Some cognitive disabilities affect concentration and attention, making distractions even more disruptive.
▪ To design simply is to design with restraint. Unfortunately, there are many competing factors that must be considered in a design, and business concerns can too easily win over user needs. Clients may request “flashy” designs that “pop” as they look for ways to stand out from competitors. But simplicity can be a great differentiator, where important elements stand out and the site stays true to purpose (see Chapter 3, “Clear Purpose,” Design for clarity and simplicity).
▪ In addition, simple designs are easier to make responsive to different devices and display formats.
▪ Consistent designs are easier to use because, once learned, the interaction model can be applied throughout the product. For example, websites that have the same functional element, like the search field, in different locations through the site require that the user relearn the interface on each page.
▪ Unfortunately, business requirements and client expectations often lead to cluttered designs. When adding a new feature to a design that is already cluttered, one way to draw attention is to add motion of some sort. And with the next new feature, more motion, and so on.
▪ For designers who want to be able to control the visual presentation precisely, flexible designs are harder to embrace. One approach to designing for different devices has been to create fixed designs that display well in different contexts. However, it’s costly to have several versions to maintain.
▪ Flexible designs start by separating content from presentation (see Chapter 4, “Solid Structure,” Use semantic markup for content). This separation allows the content to adapt to different displays because the design instructions are in a stylesheet rather than embedded in the content. This separation allows browsers to use different instructions for different contexts and user needs.
▪ A customizable design is the most effective approach for people with vision disabilities, as their needs are diverse and cannot be addressed with any one design. Instead, try to create a design with flexibility in mind that retains its integrity, functionality, and content while allowing users to make necessary changes to its visual display.
▪ Some websites include customization features to allow users to adjust the display directly on the website—for example, by enlarging the text, changing color settings, and adjusting page width and number of columns. To some extent, these are helpful, although it’s a bit like providing reading glasses along with a book. People visit many websites and will likely arrive at yours with their glasses in place—that is, running necessary software and with their browser and operating system settings configured to meet their needs and preferences.
▪ Recently, leading sites like the BBC (www.bbc.co.uk/accessibility) have taken a different approach. First, they build their sites to standards, so they work with all the built-in features of the browsers. Then, instead of building custom controls for flexibility, their accessibility Help pages teach users how to use those features to adjust the display for all sites.
▪ In 2003, Mary Frances Theofanos and Ginny Redish conducted a research study with a group of users whose vision was impaired enough to require screen magnification software. Vision disabilities varied among the participants, from congenital to those types that come with aging. An important outcome from the study was the following insight: “The needs of low-vision users are too diverse for simple solutions to web accessibility and usability.”
▪ They found that flexibility is key, creating designs that respond to customizations and configurations that are tuned to individual needs. And while they stressed that simple solutions were not possible, their design guidelines for low-vision users provided a good starting point:
▪ Never rely on color alone to convey functional meaning—that includes not relying on background color alone to define different sections of a web page.
▪ Outline tabs with a black border so that they look like tabs even when their special colors are taken away.
▪ Do not use graphic images for textual elements like links.
▪ Choose colors with different degrees of lightness, such as a light color from the top half of the circle with a dark color from the bottom half of the circle
▪ Line spacing is like the three bears: it’s important that it’s not too narrow or too wide—both make text harder to read.
▪ Note that uppercase letters are effective at getting attention—often too effective, as they seem to be shouting. Also, uppercase words are not particularly legible because we are used to reading text in a mix of uppercase and lowercase letters. We read the shapes of words, as well as the letters, and uppercase words are shapeless. It’s best to avoid setting text in all uppercase. Figure 7.6 shows a dramatic metaphor for the value of mixed case type we saw in a presentation by Drew Davies from Design for Democracy.
▪ Responsible for Clean Presentation?
Information and graphic designers take the lead in the quest for clean presentation. Collaboration with others, however, is essential. The content team should also be involved in creating the stylesheet, to ensure that the styles support clear communication and provide enough variation to meet the content needs on the site.
▪ 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.
▪ In thinking about language in a universal design context, it’s important to remember that plain language is not just a list of rules for grammar. Plain language also includes information design—how the information is presented as well as how it is written. Be sure to consider the strategies for presenting text in Chapter 7, “Clean Presentation,” when designing or creating web content.
▪ As much as we would like to think that everyone reads every word we write … they don’t. People are in a hurry, get distracted, or miss a critical word in a paragraph. They may be scanning a page quickly, multi-tasking, or be interrupted.
▪ Plain language is important to accessibility because cognitive disabilities and low reading literacy are relatively common, and because people read with different levels of literacy.
▪ Literacy includes a wide range of abilities, from understanding the words themselves to being able to assemble those words into meaningful information.
▪ People also read in places that make reading more difficult. We are often in motion when we read direction and wayfinding signs, even if only at walking speeds. We read websites in places with poor lighting, in bright sunlight, and on mobile devices with tiny screens (and tiny text). All of these situations create contextual, temporary impairment of our ability to read easily. Writing in plain language means that content is structured to support everyone, even careless, rushed readers.
▪ The site supports a global audience and people reading in translation. The web is global. Many people read websites in a second (or third) language. Guidelines for plain language support non-native readers, and also make information easier to translate.
▪ Keep pages, paragraphs, sentences short.
▪ Put the action in the verbs. Use simple, clear verbs instead of hiding the action in a noun. Write “Pay by credit card” not “Make a payment using a credit card.” (In this example, “pay” is an active verb, while “payment” is a noun form that uses the weaker “make” as the verb.) Putting the action in the verb uses fewer words, emphasizes the action, and is just plain clearer.
▪ Make link text meaningful. The text of a link should clearly and unambiguously tell the reader where the link points.
▪ If the link points to anything other than another web page—to PDF, Word, or other files—say so in the text of the link (“My Presentation (PPT)”). Some sites suggest adding the file size as well (“My Presentation (PDF 645Kb)”).
▪ “Read more” links. Watch out for links that repeat the same word over and over. It’s tempting to add a link that says “Read more …” at the end of a summary, but it’s just as easy, and clearer, to link the headline instead. Your goal is to make the linked text be clear enough for users to understand it, even out of context. Screen reader users will often review a list of the links on the page even before reading the page to get an overview of the content.
▪ In her talk, “The Right to Understand,” at TEDxO’Porto, Sandra Fisher-Martins says that the percentage of people who read at different levels of literacy made her realize that not being able to read is a kind of disability. In Portugal, 50% of people read at the lowest level (shown as figures in red in Figure 8.9) compared to just 5% in Sweden.
▪ Too often, we test the structure and templates for a site, but don’t test with real content, even though the “content” is often the real reason visitors come to the site. Including real content from the beginning of a project, from the first wireframe, has several benefits
▪ Remember that there is a lot of language in the interface: in the form of button labels, navigational links, section titles, and more. Those need to be written in plain language, no matter who writes them.
▪ Be sure to test for plain language through usability testing, not through reading level metrics, which do little more than count words and syllables.
▪ Secondly, real content for the site should be in place from the very beginning of the process, and tested and modified throughout the process, along with other design elements. Ginny urges, “No more lorem ipsum!”
▪ 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.
▪ Public screens, in airports or on the side of a building, are examples of the many places where closed captions allow everyone to watch televisions without sound—even when driving by.
▪ When communicating information through color, remember that the need to provide information for all senses applies to instructions, too. If you tell someone who can’t see color to “click on the green button,” or “fill in the fields highlighted in yellow,” those instructions are just not useful. Similarly, the information that a heading is on the right side of the page is not useful for someone using an audio interface.
▪ Open captions are burned into the video, so that everyone sees them.
• Closed captions can be turned on or off, so that they are only seen when needed.
▪ Depending on how the multimedia was created, you may already have a script that you can use as the starting point.
• A complete script. Videos for e-learning, screencasts, or that use an announcer or actors often have a complete script that is an effective transcript.
• A rough script. Speeches or informal presentations’ videos might have rough speaker notes that can be a good start on a full transcript.
• No script. Interviews or journalistic videos often have no script at all, so they have to be completely transcribed.
You then add time-codes, typically using a tool (like the ones shown in Figure 9.8) to help synchronize the text with the video.
▪ Search engines can read the transcript, but not the audio file.
▪ Anyone who spends time on the web will at some point encounter a website that overwhelms the senses, with myriad moving, blinking, and flashing elements all demanding attention. The experience is unpleasant at best. Distractions can seriously impede comprehension and effective use by getting in the way of focus. Some types of animation can trigger physical reactions, such as seizures and migraines.
▪ In addition, don’t include dynamic elements that engage without user request, such as a video that plays automatically when the page loads, a page that refreshes automatically, or a slideshow that advances automatically. These involuntary actions can be disruptive for all users and lead to all sorts of coping behaviors—for example, narrowing the browser window to hide ads in the right column, browsing with audio muted to avoid embarrassing audio outbursts, or waiting through a slideshow cycle to finish reading an entry of interest. We have all learned how to “tune out” design elements that we think are irrelevant in order to cope with distraction—sometimes to our detriment, when elements that appear irrelevant are precisely what we are seeking.
▪ Try to reduce distractions overall and play moving or audible elements only on user request. (See Chapter 5, “Easy Interaction,” Let users control the operation of the interface, for more on reducing distractions.)
▪ • 2.3 Seizures: Do not design content in a way that is known to cause seizures (Guideline).
▪ As technology and the web have changed from being a novelty to a part of daily life, expectations have also changed. More and more, it’s possible to assume that technology will work, at least most of the time. That expectation is as true for people with disabilities as for anyone else.
▪ Every time users have to struggle with operating a control, go into problem-solving mode to figure out where a link has taken them, or wonder what an image says, the website has taken them away from their own goal and broken the flow of the activity. Experiences such as these make products less usable and less enjoyable. They also make users feel less satisfied and successful.
▪ The guidelines in earlier chapters supported universal usability by making sure that elements in the design of websites and apps didn’t create barriers, and that content and functionality were provided in a way that was accessible to different modes of use. Like lean design or “mobile first,” universal usability requires an understanding of users and their goals to create sites that seem simple and transparently easy, even if the activity is complex.
▪ When Ben Shneiderman first coined the term direct manipulation, most software was controlled through commands, often typed into a text interface. He suggested that designs that made actions rapid, incremental, and reversible would reduce errors and encourage exploration. Many mobile apps (and web apps influenced by mobile design) now incorporate direct interaction with objects on the screen, showing the results of actions immediately.
▪ Apple’s iPhone is an excellent example of a direct manipulation interface that is accessible, whether or not you can see the controls. The VoiceOver screen reader announces and describes elements in the interface and provides feedback about interactions with the interface (Figure 10.2).
▪ Instead of dumping everything onto the screen at once, think about how much information or how many different features are needed at any point in an interaction. This technique, called “progressive disclosure,” is commonly used in software interaction to manage complexity. For example, application menus typically contain the most commonly used features, with secondary features accessible via submenus.
▪ Using progressive disclosure, or layering information, you can reveal the right amount of information at the right time, with the most important information first. There are many different ways to design for progressive disclosure.
▪ Show the most basic (or critical) information with a way to see more, for example, by using an accordion or a show/hide control. This can help make information easier to scan by making hidden content available with an easy (and easily reversible) action.
▪ • Reveal additional features only when needed, such as when a controlling field is filled in, a condition is met, or when a user requests them.
▪ What’s important for accessibility is that the disclosed content comes after the trigger that discloses it so that assistive technology will find it in the proper place in the reading sequence (see Figure 10.3). ARIA should also be used to communicate content changes that occur as the result of using interactive elements. (See Chapter 5, “Easy Interaction,” Use WAI-ARIA for complex elements.)
▪ On the National Cancer Institute search page, the secondary selection is only revealed after first choosing the type of cancer.
▪ The AbleGamers Foundation (www.ablegamers.com) estimates that 33 million people with disabilities use online games. They see games as more than a way to fill time or an amusement.
Games may be a way to make friends or socialize when other communication or face-to-face meeting is difficult. As they put it, “For many people with disabilities, games offer a window to the world.”
The group works to support gamers with disabilities and to help game developers create games that are more inclusive. Their companion website, Includification (www.includification.com), spells out guidelines for games accessibility by type of disability, with examples. A booklet puts the guidelines in a single 48-page resource for console and personal computer games.
▪ In interface design, bridging the gap comes in many forms. One is with the help information, where instructions appear in the basic interface and are available only on request. Novice users may make extensive use of a supporting help feature until they grow proficient with the site. And since the more comprehensive help is easily available, it does not get in the way of expert users.
▪ Another approach is to provide different methods for accomplishing the same task. Amazon’s “1-Click” shopping supports frequent buyers who are confident in their selection, account setup, and in the services Amazon provides. New or infrequent Amazon shoppers will likely want to go the more traditional “shopping cart” route, which offers more opportunities to review and confirm purchasing details.
▪ As a metaphor for layering information, Leslie O’Flahavan and Marilynne Rudick from E-Write (www.ewriteonline.com) talk about creating bites, snacks, and meals, and serving up just the right amount at a time. In their definition:
• A bite is a headline with a message.
• A snack is a concise summary.
• A meal is the complete information.
▪ News and shopping sites layer information naturally, allowing users to decide how much detail they want by presenting an article or product description as a heading and teaser paragraph, linked to the full detail page.
▪ Twitter is an application built around the concept of layering. Think about a super-short tweet, with a link to a short blog entry, with a link to a longer article. The tweet is the bite, the blog entry is the snack, and the full article is the meal, and users get to choose, each step of the way, how much information they want to consume.
▪ Put interactive feedback, such as confirmation that an entry is formatted correctly or an alert that the information was not entered correctly, after the element in the linear sequence. (See Chapter 5, Provide accessible instructions and feedback.)
▪ Good design and accessibility guidelines are a good place to start, but to create something that delights your users, you have to get out and meet them. For universal usability, user research and usability testing are key activities at the beginning of the project and through all phases of design and development, not just at the end.
▪ It’s hard to create a good experience relying only on compliance with principles, standards, and regulations. That’s especially true for universal usability. The accessibility standards, like WCAG 2.0, are written not only to solve a problem, but also to make it easy to test a site and know if it meets the standard. They get you part of the way, but not all the way to universal usability. If you don’t include usability testing with people who use assistive technologies, you will never know whether you have created a site that goes beyond accessibility to create delight for people with disabilities.
▪ Although it’s important to meet basic guidelines for accessibility, our goal is much more inclusive: to create a good user experience for everyone, including people with disabilities.
▪ Designing for universal usability allows people to explore safely and interact in a direct way. It layers information and activities so that users are not overwhelmed, and it acknowledges their achievements, and lets them control the flow of the activity, as well as the interface itself.
▪ In his May 2000 Communications of the ACM article, Ben raised the bar from accessibility to “universal usability,” going beyond technical accessibility for people with disabilities to successful use of computers by everyone.1 Now, more than a decade later, Ben is optimistic, citing examples including mobile apps, mobile phones, and digital cameras where “most people can succeed most of the time.”
▪ Similarly, we should strive to satisfy people “with different hardware, different network connections, different abilities, and different levels of knowledge about using computer technology.”
▪ But, in many cases, our expectations have not been forceful enough to affect change. Software still produces “frustration and difficulty.” University and commercial websites are not accessible. Even government agency websites that are under strict legal requirements to be accessible often aren’t. To make real gains, every user must become an activist, speaking up to influence those who can make change happen.
▪ One approach to designing universally usable software is using multi-layer interfaces. Ben calls these “karate interfaces,” in that users move metaphorically from white belt to black, mastering different skills at each step to build proficiency. “More attention to multi-layer interfaces could make systems usable by people with low skills and low needs, as well as people with high ability and high needs.”
▪ Ben recognizes that this type of interface requires more effort to build, but asserts, “It’s something we should all expect. Moderate effort by the design team can bring huge benefits for millions of users.”
▪ We expect automobiles to have levels of adjustability. We can move the seat, tilt the steering wheel, angle the mirrors, raise the lighting. Of course, it takes more time to design and may cost more, but the benefits to usability and safety are enormous.
Mature technologies have many forms of adjustability that are easy to use, enabling people to move gracefully from simple use to more elaborate use. They empower people to do remarkable things.
▪ The main force holding accessibility back is lack of knowledge in the profession. Ben suggests a universal usability review for textbooks. “That kind of review would make authors, adopters, professors, and university departments aware that universal usability is an essential part of computer science.” Ideally, the topic would be integrated into every aspect of the book, as with Ben’s seminal textbook, Designing the User Interface: Strategies for Effective Human-Computer Interaction, with Catherine Plaisant, Maxine Cohen, and Steven Jacobs. In the current 5th edition,
▪ Ben notes that “There is no chapter about universal usability—the whole book is about universal usability!”
▪ Clayton Lewis and John Reiman1 famously said, “It just won’t work to build a complete system and then, in the final stages of development, spread the interface over it like peanut butter.”
▪ In the two decades since they wrote this, it’s become obvious that this applies to content strategy, information architecture, interaction design, content, usability … and accessibility. To avoid the peanut butter approach to accessibility, accessibility must be integral to the practice of every member of the product team.
▪ You may be a team of one, or part of a large enterprise team, with many stakeholders and users. But most projects are a team effort. Websites don’t get built by the shoemaker’s elves, but by people—typically, teams of people who bring together needed skills and expertise.
▪ With a practice that supports a web for everyone, people and organizations consider accessibility integral to their work and products.
▪ Or it might be a fear of being sued over an inaccessible site that motivates attention to accessibility. There have been some high-profile lawsuits focused on equal access to ecommerce functions, such as shopping, finance, and travel. In companies concerned with lawsuits, legal or risk management departments may initiate work on accessibility.
▪ When accessibility efforts focus on compliance with guidelines or regulations, it’s seen more as a matter of completing a checklist. The team assigned to evaluate accessibility is typically outside of the product team, and can be seen as the “accessibility cops.”
▪ Even when accessibility is managed from within the product team, it may be relegated to QA or an audit by a specialized group after the code is done. These approaches treat accessibility as a real concern only after the fact.
▪ Wherever accessibility starts in a company, the simple truth is, if you want to create accessible websites and web apps, concern for accessibility has to be integrated into all the other activities that go into creating a great user experience. Accessibility must be the practice of every person who makes decisions in the design process. It must be simply how you do business.
▪ In an integrated practice, accessibility is part of all design and development work, and everyone on the team is accountable for making sure that the product works for everyone.
▪ Accessibility is a commitment. The whole company, from the head office to product teams, sees making a web for everyone as a priority. An organizational commitment ensures that accessibility isn’t done only when it is convenient. Instead, management creates a culture of accessibility from top to bottom.
▪ Accessibility is a team effort. Everyone shares responsibility, authority, and accountability for accessibility. The team may include people with special knowledge of assistive technology and how to design or code for it, but they are part of the team, rather than an external group.
▪ Usability testing is inclusive. People with disabilities are included in user research and usability evaluation
▪ Accessibility Statements
Down in the footer of many sites, you will find a link to an accessibility statement, an important tool for communicating your commitment to a web for everyone. Nomensa, an accessibility consultancy in the UK, describes the role of an accessibility statement this way:
▪ Accessibility statements and help pages are often muddled into the same document. For simplicity and ease of use, it’s best to keep these two pages separate. People looking for help may not always consider that an accessibility statement is the logical place to look.
▪ Creating an integrated practice is a process, not a single event. Even if you are building a new team, you have to start from the current situation. This section is organized as a checklist of questions to help you assess your current practice. That includes the current site, as well as the skills and resources on the team.
▪ Who are the senior managers? Are they on board? Support from top management is critical. For some companies, a focus on accessibility is a big change, and won’t happen unless there’s a top-level mandate.
▪ What is the development methodology? Agile? Lean? Waterfall? Whatever approach the development team takes, it’s helpful to be able to fit UX and accessibility into it seamlessly.
▪ Web Accessibility Code of Practice: BS 8878
The British Standards Institute launched a web accessibility code of practice in 2010 known as BS 8878. The code of practice is designed for web managers and is a comprehensive approach to developing and maintaining accessibility throughout the product lifecycle.
Meeting this standard is a statement that a process that takes accessibility into account has been followed, unlike technical standards like WCAG 2.0.
▪ You can read an overview at the Access 8878 site (www.access8878.co.uk). BS 8878 is based on an earlier publication, A Guide to Good Practice in Commissioning Accessible Websites, which is archived and made available for free by the UK Equality and Human Rights Commission (www.equalityhumanrights.com).
▪ The commitment to integrating accessibility into practice should be documented in company policy so that everyone in the organization understands the goals and recognizes the commitment.
▪ Whether the site content is created and maintained by a small group of authors or by people across the organization, a style guide can be a helpful way to ensure consistency by documenting decisions and examples of how design, content, and code elements are used. It can include many types of information, such as the following guidance to help content authors:
▪ Describe how to use styles in an appropriate and consistent way so that content managers maintain a consistent site style over time.
▪ Document decisions about the use of presentation elements such as tables, lists, icons, and headings for authors and designers.
▪ The style guide should also summarize the user research that led to design decisions so that it is easy to review and keep fresh.
▪ Apple’s leadership in accessibility is partly the result of the California state university system refusing to buy their products until everyone could use them.
▪ In February 2013, the WCAG 2.0 Evaluation Methodology Task Force (Eval TF) released a working draft of a standardized approach to testing websites against the Web Content Accessibility Guidelines (www.w3.org/TR/WCAG-EM/). The methodology covers:
• Defining the scope of the evaluation
• Understanding the features and functionality of the website
• Creating a representative sample of web pages to evaluate
• Evaluating the sample against WCAG 2.0
• Documenting and reporting findings
▪ The product team needs both tools to help design for accessibility and effective ways to test the site as it is developed. A robust program for evaluating accessibility may include automated testing with testing tools, a manual review by someone with a trained eye, and usability testing with people with disabilities who use different types of assistive technology.
▪ There are free toolbars for almost every browser that inspect a web page for accessibility issues. They are a useful way to complete a first check, looking for easily defined problems in the code. However, like any automatic testing system, these tools are only as good as their programming. For example, they can tell you if there is alt text present, but not whether it’s useful, informative text.
▪ Both the Mac OSX and Windows operating systems include features to support accessibility, such as display contrast options, keyboard support, and options to make the mouse more visible.
▪ You also may want to learn how to use screen readers and other assistive technologies, so you can check details of how the software reads a page. You may never be as proficient as someone who uses these tools all the time, but it’s possible to learn how to step through a page and use the navigation features to do a technical check.
▪ VoiceOver is built into Mac OSX. Go to Universal Access in System Preferences to turn it on and use the tutorial to get started. Although JAWS from Freedom Scientific is still the most widely used screen reader for Windows, there are some free tools. One of them, NVDA (Non Visual Desktop Access), which is an open source screen reader, has the added bonus of excellent support for WAI-ARIA.
▪ BrowseAloud (www.browsealoud.com) is not a full screen reader—it only reads web pages and PDF files that are intended for people who have reading disabilities such as dyslexia, learning difficulties, or mild visual disabilities.
▪ For more on evaluation tools and assistive technologies, see Appendix C, “More Reading.”
▪ To make a web for everyone part of the organizational mandates, the web governance plan and content strategy must include guidelines for how to manage and accommodate different business and user requests without sacrificing clean presentation and accessibility. You should also have a plan to monitor new content and multimedia, making sure that you have resources and planning for ongoing production of transcripts, captions, and video descriptions.
▪ Creating a practice that can support accessibility is not easy. It starts with a new approach to design, as we’ve described in this book. It also needs a team and organization to back up the vision of a web for everyone. The organizational and management issues are important if you want changes to stick. Building a web for everyone takes commitment and skill over the long term.
▪ Education is a catalyst for change.
Education often drives design trends. Students identify with what they are taught and how they are introduced to their field. If they are taught that form is paramount, then more functional concerns, such as accessibility, will always be secondary.
▪ In architecture, Valerie notes, “The only time an architect is likely to touch accessibility in a serious way is during licensing. Most commonly in the U.S., the only time one is taught anything about accessibility, let alone universal design, is likely in the context of an introduction to code requirements that teach plumbing code, electrical code, and accessibility. Is it any wonder people think [accessibility and universal design] is about cutting into your creative brilliance?”
▪ Today’s design curriculum does not do an adequate job of covering accessibility and universal design, and the information that is provided is geared toward meeting compliance standards. This approach results in a “just tell me what I have to do” approach to accessibility, which in turn produces inadequate designs. “Just tell me what I have to do has not resulted in the kind of creative energy and true innovation we need to make progress in this area,” says Valerie.
▪ For universal design to succeed, it first needs to be adopted by faculty and then taught to students. It needs to be intrinsic to how students learn the practice—fundamental to how they brand their work and pitch themselves professionally. “If we miss that opportunity, then it becomes a case of the one-off student—the one who, against all odds, persists.”
▪ Universal design has to be integrated into the practice of designing buildings, spaces, communications, products, interiors, and software—into the design of the things we use, the spaces we inhabit, and the way we learn and communicate.
▪ Accessibility guidelines set the baseline.
Section 508 and the Web Content Accessibility Guidelines are in some ways equivalent to building codes in the build environment. They help in establishing “a floor of accessibility and, in the case of W3C/WAI, beyond that to a high standard of usability.”
▪ However, design and designers are too often not part of the discussion, and Valerie sees this as a major failing. “There’s still a big gap in being able to identify great websites that look as good as they act. A lot of designers have yet to be convinced that you can get great design and great usability performance in a single site.”
▪ Looking ahead, Valerie sees the demand for customization and personalization of technology products and services as a catalyst for adoption of accessibility and universal design concepts by designers. “If you take ‘we’re all different’ as the starting point, and then train designers to respond to that reality, then you hit the sweet spot.”
▪ Dozens of people pointed out that all the “ilities”—reliability, quality, usability, security, and so on—must be part of the process from the beginning. None of them can be a single task, added at the end of a project, like one more feature; their principles must be “baked in.” The same goes for accessibility.
▪ As we say, if it isn’t usable for everyone, it can’t be accessible to anyone. (Perhaps not strictly true, but it makes an important point.)
—Cliff Tyllick Senior Manager, Web Accessibility
▪ • It will be invisible. Like good design, good accessibility is invisible. It doesn’t draw attention or require special consideration. It just works and makes people more successful.
▪ A web for everyone is a reflection of a universal acknowledgement that we are all human beings. We will know that we have reached it when we are no longer talking about it.
—Christopher Phillips Web Developer and Disability Services Manager
▪ William Gibson famously said, “The future is already here; it’s just not evenly distributed.” This is as true with accessibility as with anything else. It’s easy to pay attention to cool new technologies, but much harder to focus on the basics like designing to standards and making a site or app accessible.
▪ Unfortunately, at present we tend to go two steps forward and one back, as new technologies come out.
—David Andrews, Chief Technology Officer Minnesota State Services for the Blind
▪ Some large companies embrace accessibility, on financial, medical, shopping, and entertainment sites. But there are still too many valuable, interesting sites and apps launched that are simply not accessible. It’s unlikely that anyone on those teams consciously intended to exclude people with disabilities, but working with a disregard for accessibility has the same result.
▪ The pace of technological change, especially disruptive technologies, means that we are not heading toward a particular planned goal, but we are constantly playing catch-up with wherever technology takes us. Somehow, we need to make accessibility sexy and cool.
— Steve Green, Test Partners, Ltd.
▪ In a presentation about cross-cultural design, Jean-Luc Doumont said, “To sharpen your cross-cultural skills, experience more cultures firsthand.” The same principle applies to accessibility: to sharpen your accessibility skills, get to know more people with disabilities.
▪ When you recruit people for usability testing or user research, make the point of welcoming people with disabilities—and then really do it. You might be surprised at the range of people you find and what they need to be successful.
—Caroline Jarrett, User Experience Consultant
▪ In the past, many sites offered built-in controls to allow users to enlarge text or change colors. But now, browsers can do much of the work with text settings and zoom. Apple also led the way to more flexible devices when it included VoiceOver in iPhones, iPads, and iPods.
▪ We will know when we have reached the goal when accessibility is not a separate consideration, when it is baked into the infrastructure and we don’t have to worry about it.
—David Andrews, Chief Technology Officer Minnesota State Services for the Blind
▪ Many people complained that new versions of browsers and websites disabled adaptations that worked for them. Others dream of a time when their favorite technology will work better.
▪ For example, at Michigan State University, first-year engineering students are given projects that concern addressing the needs of people with disabilities. Sarah Swierenga, the Director of the Usability and Accessibility Research Center, points out what a profound influence this early exposure can have. “Once you’ve had to think deeply about disabilities and human diversity, you will always think about it. Accessibility will always be part of your work.”
▪ Ten years ago, most people thought of websites as pages on a desktop computer, designed for people with perfect vision, perfect hearing, perfect motor skills, perfect memory, and perfect understanding. Now, designers, developers, owners, and users are regularly experiencing websites on multiple devices, at multiple sizes, in all sorts of conditions, and this will help them to empathize with users of all abilities.
—Alan Dalton, Accessibility Development Advisor National Disability Authority (Ireland)
▪ Web standards are like curb cuts. They have value beyond their original purpose. Curb cuts were originally created for people who used wheelchairs, but helped people with carts, strollers, bicycles, and luggage. Similarly, both responsive design and accessibility rely on strong standards for the broad benefits they create.
▪ It is unfortunate when a small, basic accessibility bug keeps some people from using a site, particularly when the problem could easily be prevented.