When I started working at Socialtext, I came in right at a time when we were working on a large Accessibility project. For those not familiar with the term Accessibility, it’s the variety of standards, tools, and devices that collectively allow for individuals with disabilities to get access to the information, either on their systems or on the web, and interact with it as seamlessly as everyday users that do not have disabilities.
There are several standards that can be referenced and used as starting points for understanding accessibility, and a variety of tools, both free and commercial, exist to help the programmer and tester address accessibility issues, create fixes, and test them to see if they work as intended. Over the past year, Accessibility has become a focal point of my testing practice, one I didn’t spend much time thinking about or doing prior to working here.
While it’s important to understand accessibility, it would be even better if more people were to give thought to accessibility and testing for accessibility in their design decisions, and early in the process make the case that Accessibility to all users (or as many as possible) is an important part of our mission as product owner, creators, designers and testers. Sarah Horton and Whitney Quesenbery approach this challenge and this mission with their book “A Web For Everyone”. More than just ways to code and test for accessibility, this book attempts to help anyone who creates software applications to develop the understanding and the empathy necessary to make design decisions that truly help to make “A Web for Everyone” possible.
So how do Horton and Quesenbery score on this front?
Chapter 1 lays out the case for why we all should consider creating A Web for Everyone, and using the “Principles of Inclusive Design” (POUR) at the outset. Inclusive design can be seen as the cross section of good design, usability and accessibility. The Web Content Accessibility Guidelines (WCAG) 2.0 standard is introduced, which encompasses various accessibility standards in use in the U.S., the U.K., the European Union, etc. Pour uses seven principles for helping design products that work for the widest range of abilities. Equitable, Flexible, Simple, Intuitive, Perceptible, Tolerant and Considerate of Space and Effort make up the core of POUR. This chapter also focuses on Design Thinking, which emphasizes understanding the human needs first, rather than letting the technology dictate the scope or direction. Combining WCAG, POUR, universal design, and design thinking, starting with the user experience, we can make great strides in designing sites and applications that allow for the greatest possibility of use by a broad variety of users and ability levels.
Chapter 2 introduces us to the idea of People First Design by introducing us to eight different people. To those unfamiliar with the idea of “personas”, this is a great introduction, and a really nice modeling of the idea. Rather than make eight abstract personas, the book outlines eight people in quite specific detail; their physical and cognitive abilities, their skill with technology and understanding/knowledge, and attitudes (motivation, emotions & determination) are fleshed out so that we can relate to them, as well as their unique challenges and abilities/disabilities. By having so much detail, we can empathize with them as though we actually know them. Personal interjection here; even with this level of detail, personas are, by necessity, incomplete. They are stand-in’s for real people. While we will have to “fill in the blanks” for a fair number of things, the more complete a persona we can make and identify with, the more likely we will be able to consider their interaction and design for them to be effective.
Chapter 3 sets the stage for the idea of “Clear Purpose”. Clear Purpose starts with understanding our audience, putting “Accessibility First” to ensure that the broadest group of people can use the product effectively. Emphasis on universal design and equivalent use are more desirable than accommodation, since accommodation usually makes for a less fulfilling experience.
Chapter 4 focuses on Solid Structure. An emphasis is placed on the various markup and presentation options including the options associated with HTML, HTML5 and WAI-ARIA, separating the content from the presentation (yes, CSS is useful for accessibility as well as for eye candy) and optimizing content to be organized in a way that screen readers and assistive technologies can get to the the most important content first. Most important, sites with well defined structure help to remove barriers, and give users confidence they can find what they need when they use a site or an application.
Chapter 5 covers Easy Interaction. By focusing ion making interactions easy for those with disabilities, we go a long way in developing a product that is easier to interact with for everyone. Focusing on keyboard interactions, having codes in both HTML and CSS that leverage assistive technologies to provide more details or outline areas where the keyboard has focus, or to speak to the user where the keyboard focus currently is. Easy interaction enables users to control the interface, with large enough controls. It avoids taking unexpected actions for users that they can do on their own. Easy interaction also includes both preventing and handling errors in an accessible way.
Chapter 6 is all about orientation and navigation, or as the book puts it, “Helpful Wayfinding”. This consists of being consistent with design elements, mapping items similarly on pages so that the look and feel remains consistent, differentiating where it really makes sense to differentiate, and include information as to where a user actually was in the site (think of the bread crumb trail we often take for granted). ARIA roles work with HTML and HTML5 tags to help define where on the page the user is to that assistive technology can reference those rage and provide meaningful alerts and signposts. It also gives some good suggestions as to how to pattern links and navigation items, such as using action words as links, presenting links in an obvious and consistent way, including images as clickable elements, keeping the navigation process simple, and resisting the temptation to bury content in layers of submenus.
Chapter 7 focuses on Clean Presentation, or placing a focus on the visual layout, images and fonts for easy perception. To get the best effect from this, though, Clean Presentation looks to take into consideration a variety of visual disabilities, as well as allowing users the ability to customize the look and feel, using native browser options or physical controls in the site or app itself (think of the font enlarging/shrinking of a Kindle eBook as an example). Stylesheets can help considerably in this regard, and can allows the visuals to me modified both at the user preference level and at the device level (laptop, vs. tablet. vs. phone). Making a contrast between the text and background, font size, style, weight, and spacing, as well as the contrast for images can also help make a site more usable.
Chapter 8 gets to the heart of the matter regarding “Plain Language” Not to be confused with “summing down” content, but writing to the intended audience with words and terms they will understand. Plain language also helps drive content presentation. Clear headings, columns to break up text, small paragraphs, bullet points and use of bolding, italics and links. In general, make it a point to read your site regularly, and incorporate your personals to see what they would think of your presentation.
Chapter 9 covers Accessible Media. Much of what we post requires visual cues. Images and audio/video are the most obvious, and there are differing challenges depending on the individual and the disability. For sighted users, image rich sites can be little more that large blank canvases with a few words here and there. Audio files cannot easily be consumed by those who cannot hear. This is where aspects like alt tags for image, closed captioning for video files, transcripts for audio files, and other ways to describe the content on the page will goa long way towards letting more people get involved with the content.
Chapter 10 brings us to Universal Usability, or put in a different way, a focus on a great user experience for all can go a long way towards helping incorporate many accessibility ideas for everyone. Technology should not have to be fought with to get a job done, or to accomplish a goal. Well designed sites and apps anticipate user interaction, and help guide them to their completion, without requiring a lot of redirection or memorizing of options to get a task completed. A popular phrase is “Don’t make me think!” the site or app should allow the user to focus on their goal, not trying to figure out how the site or app needs to have them achieve it.
Chapter 11, In Practice, looks to unify the concepts in the book into a holistic approach. More than just using the techniques described, the organization as a whole needs to buy into the value of accessibility as a lifestyle and a core business goal. Start by evaluating your current site and seeing where you re doing well and where changes would be valuable. Determine what training, skills, people power and infrastructure will help you get from A to B. Also, while personas are a great heuristic, they do not take the place of flesh and blood people dealing with the various disabilities we want to help make our software accessible to. Look to interact with and develop relationships with real people who can give a much clearer understanding of the challenges, so that you can come up with better solutions.
Chapter 12 considers The Future, and what A Web for Everyone might look like. Overall goals include a web that is ubiquitous, where accessibility is part of design from the ground up. Another goal is flexibility as a first principle of design. Our interaction should be invisible, or at least stay out of our way as much as possible. Methods in which we will get to that place will involve being more inclusive and diverse in our understanding of who uses our products, and how they use them. We’ll need to make accessibility part of the way we think, not as an afterthought after we’ve done everything else.
The book ends with three appendices. Appendix A is a brief listing of all the principled discussed in each chapter, and would make for an excellent starting point for any story workshop or test design session. This is a great set of “What if?” questions for software testers. Appendix B is a summary of the WCAG 2.0 standard and how the various sections map to the chapters of the book. IF you want to get into the nitty-gritty details of the spec, or get access to other links and supporting documentation, that’s all here. Appendix C gives a lengthy list of additional reading (book, links, etc.) about the topics covered in the book. If you want to know more about any specific area or heading, check here.
“A Web For Everyone” gives a lot of attention to the the personas and real world examples of accessible design, which are interspersed through all of the chapters. We see their plights, and we empathize with them. These persona examples are humanizing and very helpful. They help us see the what and the why of accessibility. We see many interesting design ideas shared, but we get only a few examples of the how. Implementation is discussed, but only a few ideas are fleshed out beyond the basic prose. This is not necessarily a criticism, because A Web for Everyone does a really good job explaining the what’s and the why’s of accessibility design. High level design ideas and technology briefs are handled quite nicely. A variety of coding examples to show the ideas in actual practice, not so much. If you are looking for a guide to coding sites for accessibility with exercises and examples to create, this isn’t that book. If, however, you want to get inspired to make, test or promote software that can be used and usable by a broader variety of people, this book does an admirable job.