A Web for Everyone

As I continue on the quest to catch up on all the webbish reading I have started or stacked up, I finished A Web for Everyone by Sarah Horton and Whitney Quesenbery and it was a great refresher on accessibility. But the book did more than just refresh me on a bunch of accessibility techniques, it introduced me to so many different people working hard in this area of the web.

Each chapter ended with a spotlight interview on different people who are working towards a better, more accessible web and it opened my eyes to a lot of people I didn’t know about but who are doing great work. In addition, the book lays out so many fantastic things to think about as you are designing and building to make sure that all people can access your content. I highly recommend this book if you are interesting in accessibility but just don’t know where to start.

I read the epub version of the book and since page numbers are so problematic, I have my highlights broken up by chapter below.

Chapter 1

When we have a web for everyone, people with diverse abilities and contexts can use the web successfully and enjoyably.

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.

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.

The question, then, is how to avoid creating barriers and thus maximize the accessibility of a product? The answer: by adopting a practice of accessibility.

“Universal design is appealing because it provides an intentional, designed approach—aesthetic and elegant—while creating products that are often beneficial to everyone.

And with design thinking, you can use your designer’s toolkit—exploration, prototyping, and testing—to integrate accessibility into elegant, accessible products.

WCAG + Universal Design + Design Thinking = A Web for Everyone

Chapter 2

When designing for differences, people are the first consideration, and sites are designed with the needs of everyone in the audience in mind.

…[R]emember that people with disabilities are people first, with habits, context, emotions, and preferences—part of the audience for your work.

Chapter 3

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

The best time to consider accessibility is at the start of a project when defining the product purpose. When accessibility is part of the purpose and built in from the beginning, the product works better for everyone.

When good designers shift this around, thinking about accessibility first, they end up with a product that is stronger and more usable for everyone. Considering a diverse audience is just the same as working in many languages or across many devices and platforms. When you include accessibility in your thinking from the beginning, it is just one more aspect of the flexibility needed for today’s products.

It’s not okay to create a separate design—one that delivers a separate and degraded experience—for people with disabilities.

The danger of taking advantage of this “equivalent use” approach and relying on other programs for accessibility is that they all have to be kept up-to-date as features and the API change. Over time, the accessible versions can fall behind or even stop working entirely.

Chapter 4

Machine-readable data is what makes the web so powerful.

A strong structure allows consistency and flexibility across devices and interaction modes so that everyone has an equitable experience.

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.

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.

Headings are particularly important, because most screen readers provide a helpful list of headings on a page so that users can use them to navigate the hierarchy of information.

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.

Chapter 5

Using known and well-established interactive controls goes a long way in designing for easy interaction.

With WAI-ARIA, you can identify and describe interactive elements in a way that software can read, so it is accessible to users of assistive technology.

But you should consider the ramifications carefully before moving away from standard technologies. Is the interaction necessary to the purpose and goals of the product? If so, can you accomplish what’s needed using standard coding? Exhaust the possibility of using standard web technologies before you make a commitment to a non-standard, and therefore less stable and accessible format.

Another common practice is opening links in a new window, usually with the rationale that it will help users return to the originating website because they can just close the window. Unfortunately, opening a new window starts a new browsing history. When users navigate in this new window and try to use the back button to return to the first website, they can’t do so because the first website is not in the history for the programmatically opened window. Indeed, this practice could end up having the exact opposite of the desired effect—in that, users will not be able to find their way back.

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.

Chapter 6

Although a clear and consistent model is important for any user, it is especially important for people who use screen readers and other technologies that read the page linearly. For linear access, consistent placement of elements and use of consistent semantic markup, including headings, helps users form mental models.

There can be too much consistency if it blurs important distinctions. People like predictability, so when the same words, images, or buttons do different things, it’s disorienting and breaks their mental models.

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.

Chapter 7

People usually think of information design in visual terms, such as how elements are arranged in an information space: they use visual cues, such as alignment and white space, to guide the eye through information and interactive elements. But you cannot rely on just one sense—in this example, vision—to communicate meaning. Users may not have access to information conveyed visually, or they may have changed the display to meet their own needs, thereby changing the information design.

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.

A quick way to check color contrast is by looking at the presentation in grayscale.

Chapter 8

Writing in plain language does not mean oversimplifying or dumbing down the content.

You might also think that writing for the web is different than other writing, but research suggests that guidelines for print and web are very similar. The differences are based on the genre or the type of information being presented. The important consideration for deciding which guidelines to follow is the type of information, especially for information that appears both in print and online.

Writing for your audience means using terminology your audience understands. We’ve emphasized “your audience” because we are not suggesting that all content needs to be reduced to one-syllable words. Plain, accessible language is language that fits the context and the audience.

Readability formulas may seem like a way to define clear writing, but they are not a very good way of evaluating plain language. The reason is simple: these formulas work by counting syllables in words and words in sentences, and those counts have very little to do with whether the information is readable. They also ignore an important part of the definition of plain language: that the content is written for the readers.

Chapter 9

Making media accessible is critical for a simple reason: without alternatives, the information in images, audio, and video is completely hidden from some people. This creates an absolute barrier to understanding the content and a generally frustrating experience for people who can’t access the information.

One of the first rules of accessibility that many people learn is “not by color alone.” This doesn’t mean not to use color at all—far from it. Color is an important part of design. It just means you must use redundant cues of shape, position, or text to reinforce the meaning.

Chapter 11

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.”

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.

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.

Chapter 12

Web accessibility is all of our responsibility. It cannot be realized unless we all make a commitment and work toward a shared vision for the future. Other voices join ours in this look into the future, weighing in, sharing perspectives on what a web for everyone is and what we need to get there. In the end, we ask you to add your voice.