Many people ask me how a developer who was working on the back-end for websites got involved in accessibility. After all, it wasnât technically a part of my job description. It wasnât going to make our sites faster (though I later found out it could have that side affect). I didnât have a disability, nor did I seem to be closely associated with the disabled.
The truth of the matter: I stumbled into it. I was working on a contract at NASA, and we were required to make our sites 508 compliant in order to get them deployed. A separate group was responsible for assessing our sites then sending us exact fixes. Our websites kept failing and we found ourselves falling behind schedule again and again.
We often asked the testers to explain why something had failed, but they, like everyone else on the contract, were too busy to take time to educate a handful of developers. They gave us a checklist, which we read and were baffled by. Tables need scopes? What are scopes? Why do they need them? Whatâs wrong with the designerâs color scheme? What do you mean the contrast is no good? Why was our alt text rejected?
At the time, the resources on the Internet focused on more on policy makers and lawyers than developers. Though we found many tips about creating an accessible application, few included why these added tags made our sites easier for the disabled to use. This made it increasingly difficult to make websites that were new and innovative without wondering if we were inadvertently shutting someone out.
Though there are books that talk about 508 compliance, few focused on the people that do the actual development. They were for managers or testers, and offered few practical insights into the world of accessibility.
It took me years of battling testers, Googling, and playing with tools to get a full understanding of accessibility. I didnât think it should be that hard, though. Why couldnât all of this information be collected in one place so I could take it in within a few sittings? Why did I have to wait for issues to come up before researching how to fix them? How could we develop new technologies without patching them later for accessibility?
I decided to write a book that focused on the disabilities rather than the patches. Yes, alt text should always be used and tables should always be scoped. Whatâs even more important to understand is how poor alt text or tables with no scopes affect the experience of a user. Understanding a userâs tools and limitations helps developers and designers make the next generation of web applications without excluding anyone.
Iâve also come to believe that making a site accessible makes it more usable for everyone. Though a few recommendations are exclusively for the disabled (such as alt text), many suggestions that will be made throughout the book will positively affect all users. No one likes forms that require absolute precision, and bad color choices hurt everyone. Creating a site that grows gracefully helps those on smaller monitors, such as tablets or netbooks, and including web fonts instead of images with text can make your site download faster. Good accessibility is good usability.
Being accessible is about making your website, with all of its data and functions, available for anyone, no matter how they have to use your website, or what difficulties they might have. Some people might have to use a screen reader, where the content of a site is read to them. Others may rely on subtitles and transcripts for audio content. Still others may be unable to use a mouse, or they may be using an adaptive device that works only through the mouse. They may need to override a websiteâs styling in order to make it more readable for them.
In short, no one should be excluded from using your website simply because they have to access the Web in a different way.
Being accessible doesnât mean stripping your website of any advanced functions because someone is using a screen reader, or might have issues using a mouse. It doesnât mean a return to the days of unstyled web pages, or hiring a group of people dedicated to making your products accessible. Accessibility, if kept firmly in mind during development, can be done without significantly increasing overhead, and can even improve your website for your standard users.
In 1998, Congress passed an amendment to the Rehabilitation Act, requiring that all websites created for the United States government be accessible to everyone, in spite of individual handicaps. This amendment was Section 508, so often, web accessibility is referred to as â508 compliance.â While the original act (passed in 1973) had its own 508 section in regards to technology, it was toothless until 1998, when standards were introduced. It was determined that any website paid for by federal funds must follow the requirements laid out in this amendment.
An out was written into the section, allowing for websites to get a waiver if their audience was small, and confirmed to have no one with any disabilities. With the growing number of disabled joining the ranks of not only the government, but also its contractors and affiliates, these waivers are growing more rare. Itâs difficult to prove that your audience will never include anyone with a disability, so this waiver is usually limited to top-secret projects or projects with an extremely limited timeframe (such as a workshop or one-time meeting).
The act covers anyone with a disability, but its interpretations often focus on three main groups:
The visually impaired
Those with hearing impairments
Those with physical impairments
Why not just call the first two groups the blind and the deaf? Section 508 takes a broader stance, considering those with low-vision and color blindness, as well as those who may not be completely deaf.
Obviously, the main benefactors are those with vision or hearing issues, or who have physical limitations. As websites grew in complexity, many people in these groups were left behind. Tables used for layout kept screen readers from performing correctly. Complex layouts refused to grow gracefully, causing issues for people with low vision. Menus that dropped down, then snapped back at the slightest wavering of the cursor caused websites to be impossible to navigate for the motion impaired.
Theyâre not the only benefactors, however. A website that is accessible for the disabled often gains the benefit of becoming easier to use for everyone. Narrow clicking margins are annoying to those with full mouse control as well as those with motion disorders. Websites that donât grow gracefully can be difficult for people using different size monitors. Someone on a low bandwidth connection (for example, tethered to a phone with a low data cap) might need to turn off images while surfing.
Also, itâs important to remember that not everyone who is disabled has been disabled forever or will remain disabled. A person who has broken her dominant arm learns very quickly how difficult websites can be to navigate without a steady mouse. A person without headphones will have trouble with websites that require sound. And a person who has forgotten his glasses will be subjected to websites that donât deal with large text gracefully.
In other words, everyone can benefit in the end.
This book is centered around how to make a website accessible from a practical perspective rather than from a legal perspective. As such, this book is geared toward developers, both at the application and front-end layers, who wish to make their websites accessible. Itâs also presented as a way for those who manage projects to think about how they might work accessibility into their schedule, and how they might sell it to their customers. This book can also be used by quality assurance professionals interested in how to use testing tools for accessibility beyond tools that only scan HTML and look for obvious errors.
This book can also be used by those who wish to sell accessibility to customers who may not see the immediate benefits of making their website accessible. The last chapter is dedicated to collecting all the direct and indirect benefits of a focus on accessibility, while also making the case that doing so doesnât add as much overhead as some might fear.
Part of understanding accessibility is understanding the struggles of those with disabilities trying to use a website. For this reason, this book is split up into sections based on the disabilities covered in Section 508. Each section focuses on the specific challenges of the people with that disability, the tools they might use to work with their issues, and how a developer can make their life easier.
Every effort has been made to make code samples that are clear, and reasonably cross-browser. The code samples should not be considered the end solution for the developer, however. Accessibility can be achieved in many ways, and the best solution is one that works with both the vision of the designer and the needs of all the users.
Each sample has been tested with the following browsers in Table 1.
Table 1. Browsers tested
| Browser | Operating System | Versions |
|---|---|---|
| Internet Explorer | Windows | 8+ |
| Firefox | Windows | 7+ |
| Chrome | Windows | 10+ |
| Firefox | Mac | 7+ |
| Safari | Mac | 5+ |
| Chromium | Unix | 10+ |
| Firefox | Unix | 10+ |
With each example, only one solution is shown. While most of these should work with most modern browsers, the code is shown only as a guideline. As new technologies become more common, new solutions can be written. Years ago, formatting was done with tables because CSS wasnât common. These days, CSS is so common that using tables for layout seems archaic.
The following typographical conventions are used in this book:
- Italic
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant widthUsed for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width boldShows commands or other text that should be typed literally by the user.
Constant width italicShows text that should be replaced with user-supplied values or by values determined by context.
Tip
This icon signifies a tip, suggestion, or general note.
Caution
This icon indicates a warning or caution.
This book is here to help you get your job done. In general, you may use the code in this book in your programs and documentation. You do not need to contact us for permission unless youâre reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from OâReilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your productâs documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: âAccessibility Handbook by Katie Cunningham (OâReilly). Copyright 2012 Katie Cunningham, 978-1-449-32285-4.â
If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com.
Note
Safari Books Online (www.safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the worldâs leading authors in technology and business.
Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.
Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like OâReilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.
Please address comments and questions concerning this book to the publisher:
| OâReilly Media, Inc. |
| 1005 Gravenstein Highway North |
| Sebastopol, CA 95472 |
| 800-998-9938 (in the United States or Canada) |
| 707-829-0515 (international or local) |
| 707-829-0104 (fax) |
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://oreil.ly/access_handbook.
To comment or ask technical questions about this book, send email to bookquestions@oreilly.com.
For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia
Iâd like to thank my first editor, Julie Steele, for recognizing that this was a book that was needed. Iâd also like to thank my second editor, Meghan Blanchette, for her neverending patience while I struggled to finish the book.
Without my husband, Jim, I never would have been able to finish the book. He gave me space when I needed to write, wrangled the kids, brought me food when I needed to eat, and poured me wine when I needed to chill.
And kids? Thank you for learning that headphones mean that itâs a bad time to poke your mother.
And finally, I had the best tech editors in the world. They made this book so much stronger by being involved with it. Doug Hellman, Tom Wolber, Scot Taylor, and Sean OâConnor: You guys are the best!
Get Accessibility Handbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
