Design accessible web sites 36 Keys to Creating Content for All Audiences and Platforms potx

Thank you for taking part in this experiment.

Andy and Dave

Design Accessible Web Sites

Thirty-Six Keys to Creating Content for All Audiences and Platforms

Jeremy J. Sydik

The Pragmatic Bookshelf

Raleigh, North Carolina Dallas, Texas

Many of the designations used by manufacturers and sellers to distinguish their prod￾ucts are claimed as trademarks. Where those designations appear in this book, and The

Pragmatic Programmers, LLC was aware of a trademark claim, the designations have

been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The

Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g

device are trademarks of The Pragmatic Programmers, LLC.

Quotation from “The Hobbit” by J. R. R. Tolkien. Copyright © 1937, 1966 by The J. R.

R. Tolkien Copyright Trust. Reprinted by permission of The J. R. R. Tolkien Copyright

Trust.

Quotation from “Monty Python and the Holy Grail.” Copyright © 1975 by Python (Monty)

Pictures Ltd. Reprinted by permission of Python (Monty) Pictures Ltd.

Web Content Accessibility Guidelines 1.0 (Recommendation) http://www.w3.org/TR/WCAG10/

Copyright © 1999 World Wide Web Consortium (Massachusetts Institute of Technology,

European Research Consortium for Informatics and Mathematics, Keio University). All

Rights Reserved

Web Content Accessibility Guidelines 2.0 (Public Working Draft)

http://www.w3.org/TR/WCAG20/ Copyright © 2007 World Wide Web Consortium (Massachusetts

Institute of Technology, European Research Consortium for Informatics and Mathemat￾ics, Keio University). All Rights Reserved

Cover image courtesy of Katherine A.W. Sydik

Every precaution was taken in the preparation of this book. However, the publisher

assumes no responsibility for errors or omissions, or for damages that may result from

the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team

create better software and have more fun. For more information, as well as the latest

Pragmatic titles, please visit us at

http://www.pragmaticprogrammer.com

Copyright © 2007 Jeremy J. Sydik.

All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmit￾ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or

otherwise, without the prior consent of the publisher.

Printed in the United States of America.

ISBN-10: 1-934356-02-6

ISBN-13: 978-1-934356-02-9

Contents

Acknowledgments 10

Preface 12

Getting to Know Each Other . . . . . . . . . . . . . . . . . . . 13

Finding Your Way Through This Book . . . . . . . . . . . . . . 14

Principles Before Guidelines . . . . . . . . . . . . . . . . . . . . 15

Part I—Laying the Foundation 18

Why Be Accessible? 19

1.1 It’s the Right Thing to Do . . . . . . . . . . . . . . . . . 19

1.2 Accessibility is Good Business . . . . . . . . . . . . . . 20

1.3 Accessible Sites are More Usable . . . . . . . . . . . . . 21

1.4 It’s the Law . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.5 Building with Accessibility Can Make You More Capable 24

A Brief Introduction to Disabilities 26

2.1 Visual Impairments . . . . . . . . . . . . . . . . . . . . . 26

2.2 Auditory Impairments . . . . . . . . . . . . . . . . . . . 29

2.3 Mobility Impairments . . . . . . . . . . . . . . . . . . . 31

2.4 Cognitive Impairments . . . . . . . . . . . . . . . . . . . 32

2.5 Multiple Disabilities . . . . . . . . . . . . . . . . . . . . 33

An Environment for Access 35

1. Making a Team Effort . . . . . . . . . . . . . . . . . . . 37

2. Plan for Access . . . . . . . . . . . . . . . . . . . . . . . 46

3. Multiple Access Paths . . . . . . . . . . . . . . . . . . . 53

4. Don’t Get WET! . . . . . . . . . . . . . . . . . . . . . . . 57

5. Guidelines for Accessibility . . . . . . . . . . . . . . . . 61

CONTENTS 7

Testing for Accessibility 64

6. Testing as a Design Decision . . . . . . . . . . . . . . . 65

7. Building a Testing Toolbox . . . . . . . . . . . . . . . . 69

8. Getting Your Hands Dirty . . . . . . . . . . . . . . . . . 76

Part II—Building a Solid Structure 81

The Structured Life 82

9. Say It With Meaning . . . . . . . . . . . . . . . . . . . . 83

10. Keeping It Simple is Smart . . . . . . . . . . . . . . . . 89

11. Minding Your <p>’s and <q>’s . . . . . . . . . . . . . . . 94

12. Linking It All Together . . . . . . . . . . . . . . . . . . . 98

13. Styled To The Nines . . . . . . . . . . . . . . . . . . . . 101

14. Welcome To The Future . . . . . . . . . . . . . . . . . . 105

Round Tables 110

15. Setting The Table . . . . . . . . . . . . . . . . . . . . . . 111

16. Ah, <table>, I Hardly Knew Ye! . . . . . . . . . . . . . . 115

17. Layout And Other Bad Table Manners . . . . . . . . . . 122

The Accessible Interface 130

18. It’s Their Web—We’re Just Building In It . . . . . . . . 131

19. Getting <form>al . . . . . . . . . . . . . . . . . . . . . . 135

20. Tickling The Keys . . . . . . . . . . . . . . . . . . . . . . 142

21. Your Interface Has Some Explaining To Do . . . . . . . 145

Part III—Getting the Perfect View 149

A Picture is Worth... 150

22. Stoplights and Poison Apples . . . . . . . . . . . . . . . 151

23. Thinking in Terms of Black and White . . . . . . . . . . 157

24. To Put it Another Way . . . . . . . . . . . . . . . . . . . 162

25. More Than alt= Can Say . . . . . . . . . . . . . . . . . . 167

26. alt.text.odds-and-ends . . . . . . . . . . . . . . . . . . . 174

Video Killed the Something-Something 179

27. It’s Not Polite to Flash the Audience . . . . . . . . . . . 181

28. Words That Go [Creak] in the Night . . . . . . . . . . . 185

29. Describe it to Me . . . . . . . . . . . . . . . . . . . . . . 190

30. On the Cutting Room Floor . . . . . . . . . . . . . . . . 194

CONTENTS 8

Part IV—Putting on Some Additions 206

Not All Documents Are Created Equal 207

31. Back at the Office . . . . . . . . . . . . . . . . . . . . . . 209

32. PDF: Trying to Make Portable Accessible . . . . . . . . 213

Scripted Responses 221

33. Unassuming Scripts . . . . . . . . . . . . . . . . . . . . 222

34. Higher Order Scripts . . . . . . . . . . . . . . . . . . . . 226

Embedded Applications: Rinse and Repeat 232

35. The Many Faces of Flash . . . . . . . . . . . . . . . . . 233

36. Java: Is Your Brew Fair-Trade? . . . . . . . . . . . . . . 239

Part V—Building Codes 243

Web Content Accessibility Guidelines 1.0 244

13.1 Checkpoint Priorities . . . . . . . . . . . . . . . . . . . . 245

13.2 Conformance . . . . . . . . . . . . . . . . . . . . . . . . 246

13.3 The 14 Guidelines of WCAG 1.0 . . . . . . . . . . . . . 247

Section 508 261

14.1 Software Applications and Operating Systems (§1194.21) 262

14.2 Web-Based Intranet and Internet Information and Applications (§1194.22) 264

14.3 Video and Multimedia Products (§1194.24) . . . . . . . 267

Web Content Accessibility Guidelines 2.0 270

15.1 The Basics of WCAG 2.0 . . . . . . . . . . . . . . . . . . 271

15.2 Concerns About WCAG 2.0 . . . . . . . . . . . . . . . . 272

15.3 The WCAG 2.0 Guidelines . . . . . . . . . . . . . . . . . 273

Meanwhile, In the Rest of the World... 288

16.1 Australia . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

16.2 Canada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

16.3 The European Union . . . . . . . . . . . . . . . . . . . . 290

16.4 Japan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

16.5 United Kingdom . . . . . . . . . . . . . . . . . . . . . . . 292

16.6 United Nations . . . . . . . . . . . . . . . . . . . . . . . 292

16.7 More Information . . . . . . . . . . . . . . . . . . . . . . 294

CONTENTS 9

Final Thoughts 295

17.1 Keep Trying . . . . . . . . . . . . . . . . . . . . . . . . . 295

17.2 Stay Informed . . . . . . . . . . . . . . . . . . . . . . . . 295

17.3 Have Fun . . . . . . . . . . . . . . . . . . . . . . . . . . . 296

Bibliography 298

Index 299

The Journey is the Reward.

Zen Proverb

Acknowledgments

Every journey has a beginning and, in the case of this book, the journey

truly began over ten years ago at the University of Nebraska—Lincoln

Accommodation Resource Center. Dr. Christy Horn first showed me the

importance of accessibility and has continued ever since to shape me

as a professional and as a person. Thank you for your mentorship and

your friendship. I also thank Christy, Roger Bruning, Barbara Robert￾son and everyone else at the Center for Instructional Innovation for

contributing to the supportive environment that makes working on a

project like this possible.

The road to this book would have been impossible to navigate without

help along the way. Mike Hostetler, Peter Krantz, Jason Kunesh, Florian

Ockhuysen, Aza Raskin, Ian Scheitle, and Warren Werner read early

versions of this content, reviewed chapter drafts, and called me to task

when I oversimplified or underexplained. This book is much better for

your help (But I’m still taking credit for all of the mistakes, so there).

Susannah Davidson Pfalzer had the (sometimes extremely) challenging

task of being the development editor for this project. I know I’m not easy

to negotiate with, so thank you for pushing when you knew this book

could be better and for trusting my judgement when I was convinced

that we were on the right path. I’d also like to thank Dave Thomas

for listening to the original concept for this book at RailsConf 2006 and

believing in the idea of a principles-based approach to web accessibility.

Dave, along with Andy Hunt, also answered many of the questions that

came up along the way about production, layout, copyright, and all of

the other things that turn a bunch of words into a book. It has been an

honor to write a Pragmatic Bookshelf title.

To get where you’re going, you need to remember where you came from.

My Mom and Dad are responsible for teaching me to believe in doing

the right thing, helping people who need to be helped, and trying to

be the best person I can be. (The rest is my own fault.) I’d also like to

ACKNOWLEDGMENTS 11

thank Gerry, Susie, Stephen, Jeannine, my grandparents, and the rest

of my family for their faith and prayers for this project and their under￾standing when I sometimes nodded off on a couch at family gatherings.

For every blessing that I have received, for giving me strength along this

path, and for all things, I thank God.

The difference between journeying and being lost is knowing where

home is. I want to thank you Kate. You’ve been my editor, reviewer,

cover designer, and first audience for this project. More importantly,

you are the mother of my son, my girlfriend, my best friend and my

wife. The things I do here and elsewhere are meaningless without that.

Finally, I’d like to thank my son, Aidan. You’re young enough that

you won’t remember much about your dad wandering around late at

night muttering about chapters, edits, markup, and guidelines but my

favorite part about late night writing was sitting with you long after

your mom was asleep and sharing a snack after I was done for the

evening. You remind me every morning why I want a better world and

every evening that, with you in it, I’m already in a better world.

Jeremy J. Sydik

August, 2007

New information and communications technologies can

improve the quality of life for people with disabilities, but

only if such technologies are designed from the beginning

so that everyone can use them. Given the explosive growth

in the use of the World Wide Web for publishing, electronic

commerce, lifelong learning and the delivery of government

services, it is vital that the Web be accessible to everyone.

William Jefferson Clinton, Statement of Sup￾port for the Web Accessibility Initiative

Preface

It was a dark and stormy night...

Actually, It was a late summer afternoon a little over ten years ago when

I first began to get accessibility. Back then, I was working as a student

web developer and sysadmin and we needed a system for a blind user

to work on a paper. Simple enough—we had some new systems. Just

grab one, install it, add the specialized software and we’re done. I was

fairly happy about the job—it was my first time through this kind of

configuration and I finished with plenty of time so I added on nicer (I

thought) speakers and keyboard.

Our user came in and started to use the system—or at least tried to use

the system. Everything started to fall apart. The keyboard was one of

the newer (at the time) ergonomic keyboards, which the user had never

worked with. The speakers were an even bigger problem. They came out

of the box set to a low volume and I hadn’t thought to set them high so

they could be controlled from software. The user’s began to panic when

the interface to the system was completely disrupted. Two decisions

that wouldn’t have usually been a problem turned the afternoon into a

disaster.

Of course, the real problem was human, not technological. My mis￾take was in my assumption about how people use computers which, of

course, was how I used a computer. I knew that blind users needed to

use special software on their computers, but I didn’t consider the real

difference in user experience. Later that evening, I got curious about

my web sites—seeing how much difference something as simple as a

different keyboard could make, how would my sites behave for users

with screen readers instead of monitors and keyboards but not mice?

It wasn’t pretty. I knew that I needed to design my sites differently, but

what exactly did I need to do? It turns out that accessibility isn’t really

that much about what you do—it’s a matter of how you do it. What

GETTING TO KNOW EACH OTHER 13

I really needed was information on what being accessible means and

how to think from the perspectives of many kinds of users.

Accessibility for the web is about designing content to be reachable by

the largest number of users possible. There are a lot of ways to be acces￾sible. Content can be accessible from a variety of hardware platforms

or browsers. Accessibility can also be in terms of which technologies

are assumed to be available to the user—less is more. Finally—and

most importantly for us since it will be the primary focus of this book—

content can be made accessible to users with disabilities. This kind of

accessibility means tailoring our content to be useful for people with

a wide range of physical, mental, and sensory abilities. As far as the

other kinds of accessibility, we’ll get the best of both worlds. Content

that is made accessible for users with disabilities is usually well on the

way to being ready for multiple platforms and browsers as well.

Getting to Know Each Other

This book is about learning to apply accessibility principles to your

web development practices. In other words, if you have anything to

do with building web sites, there’s something here for you. You could

be a project manager, a designer, a developer, an author, or an artist

(Take a look at Making a Team Effort, on page 37 to see how different

people fit into the accessibility process). I’ve written information that

will be useful for anyone who wants to produce accessible web sites.

You might want to do this because you believe it’s the right thing to

do, because you know it’ll make your sites more portable to different

platforms, or because you are concerned about the consequences of

accessibility laws. These are all valid reasons and, for each of them,

you’ll find plenty of useful principles and techniques here.

I’m also going to assume, however, that you understand the basics of

web development. We’ll be covering accessibility as it relates to HTML,

CSS, images, video, and sound. We’ll also make brief excursions into

accessibility for external document formats, JavaScript, Flash, and Java.

We’re not going to be covering how to use these technologies beyond

what we need for using them accessibly but I’ll do my best to point you

toward plenty of good resources to check out if you feel like you need

help getting up to speed. I think it’s important to mention, however,

that I’m not a member of any of the committees you’ll read about in

this book or the developer of any of the tools. When I give a recommen-

FINDING YOUR WAY THROUGH THIS BOOK 14

dation, it’s because I find the tool/book/website/whatever useful when

I write pages.

There are three things that I won’t be doing in this book, however.

I won’t be spending a lot of time explaining (over and over and over)

that accessibility is a good thing. I’m assuming that you’re already

partly convinced if you’re reading this so we’ll take look a quick look

at why accessibility is a good thing in Chapter 1, Why Be Accessible?,

on page 19. After that, it’s down to business. I also won’t be ripping

apart good visual design. Great visual design is an important element

of the web and I welcome every designer who wants to add accessibility

to their toolbox to come along—there’s plenty of information here for

you as well. Finally, I’m not going to focus primarily on accessibility

guidelines. I don’t think this is a useful route for understanding the

principles that underlie web accessibility, so we’re going to take a prin￾ciples first approach. We’ll get to the guidelines after we have a better

understanding of what they mean.

Finding Your Way Through This Book

Web content is often referred to in terms of places like sites, home

pages, stores, and so on. That works fine—if we’re building places, we

can look at our users as visitors or, better yet, as guests. With that

in mind, we’ll look at the concepts in this book in terms of building

these places. I’ve laid out the concepts in this book in order from basic

concepts to extra details:

• Part I—Laying the Foundation: All good buildings start with a strong

foundation. Here, we’ll get you started with a basic look at acces￾sibility, why it’s important and how to get started with accessible

development.

• Part II—Building a Solid Structure: Like the framing of a building,

markup gives our site a defined form. In this part, we’ll look at

web semantics and understanding how to use markup and styles

in an accessible way.

• Part III—Getting the Perfect View: When a building is well designed,

the views from it are remarkable, when it isn’t, the views are lack￾ing. When we add accessibility features to our images, videos, and

sounds, we provide the best view possible for our entire audience.

In this part, we’ll learn how to add alternative information for

accessibility.

PRINCIPLES BEFORE GUIDELINES 15

• Part IV—Putting on Some Additions: We might want to put some

extra features into our buildings. There are also extra things like

external documents, scripts, and plug-in technologies that we can

use in our sites that are at the edges of the web itself. In this part,

we’ll look at applying accessibility principles to these as well.

• Part V—Building Codes: Before a building is complete, it’s inspected.

Web sites should also be checked for correctness and, in this part,

we’ll wrap up by looking at the standards and how they connect

to the things we’ve learned in the rest of the book.

It’s not strictly necessary to follow the entire book in order, however. You

should start with Chapter 1, Why Be Accessible?, on page 19 and Chap￾ter 2, A Brief Introduction to Disabilities, on page 26 first but, after that,

you should feel free to move in the order you find most useful. If you’re

managing site development, you should probably continue into Chap￾ter 3, An Environment for Access, on page 35 but, if you’re a graphic

designer, you might find it more useful to jump ahead to Chapter 8, A

Picture is Worth..., on page 150.

Chapters three through twelve are comprised of a series of thirty-six

tips. These tips are meant to stand on their own—you should be able

to spend a short time with each tip, get the information you need and

walk away to apply it to your own projects. The Act on It! sections are

there to give you some ways to get started. Don’t just read these—give

them a try!

After you’ve been through the tips, go ahead and read through the dis￾cussion of guidelines and laws in Part V. They’ll make a lot more sense

once you’ve been through the rest of the book but, if they’re still confus￾ing, my commentary will point you back to the part of the book where

the underlying principle is covered.

Principles Before Guidelines

This book is going to take a principles before guidelines approach to

accessibility. Staying focused on compliance issues is a common approach

to accessibility, so it may seem surprising that I’m going to push the

guidelines out of the way for now. Guidelines are useful for sorting out

details and testing for compliance but they’re not written as instruc￾tional documents. Our goal is helping as many of our users as possible

get the information they want—not learning to be “rules lawyers” When

we add video to our sites, we don’t want to be thinking: