Slashdot Mirror
Constructing Accessible Web Sites
What does the book cover?
Chapter 1 is an introduction to web accessibility. I would guess that most people who pick up this book will already know at least a little bit about accessibility, but this chapter provides a good overview and presents some compelling arguments for providing accessible websites. Interestingly, none of these is based on a moral argument -- they are all sound reasons why it is in the interests of an organization to think about accessibility. For example, one of these sections mentions that people with disabilities in the U.S. are estimated to control a discretionary income of over $175 billion. Making a site accessible to these people gives it access to an additional market that non-accessible sites cannot tap.
This first chapter sets the tone for the whole book. It doesn't preach about accessibility for the sake of people with disabilities but rather seeks to convince the reader that accessibility is in their interests.
Chapter 2 concentrates on one of the major reasons for making web sites accessible - laws that compel us to do so. It presents an overview of the state of the law in different parts of the world and a couple of examples of cases involving web usability. I have to admit I skimmed this chapter, as I wanted to get on to the technical stuff.
In Chapter 3, the book gets on to the mechanics of accessibility -- assistive technologies. It provides a short survey of the screen readers and other technologies that are available. I would have liked to have seen more information here on how widespread these systems are, even if just approximate.
Chapter 4 is where the book starts talking about the actual work involved in creating accessible content. It runs down the basics of accessibility (most of it is good practice such as using ALT text and so on). The blink tag even gets a mention and a "good for them!" is given to Opera for not supporting it :) This chapter will not be news to anyone who has done any accessibility work (or even just best-practices web development). The information on how tables are handled by screen readers is good though.
Chapter 5 looks in more detail at navigation. The advice here is good even outside of an accessibility context and there are some good points about 'gotchas' that could make sites difficult to navigate with assistive technologies.
In Chapter 6, input gets the same treatment that navigation got in the last chapter. I wasn't sure about the stuff on PDF forms (does anyone actually use these for web input?) but the advice on HTML forms was great.
Chapter 7 is about testing for section 508 (of the U.S. Rehabilitation Act) compliance. Initially, this was another chapter that I skimmed, as I am not based in the U.S., but then I realised that the testing advice in this chapter is not just useful for section 508 compliance -- it is useful for general accessibility testing.
Chapter 8 studies the accessibility of web development tools themselves. This doesn't apply to me but it was interesting to see how the tools (Dreamweaver, Frontpage, GoLive, Homesite and BBEdit) compare in terms of usability. This would have been a lot easier if there had been a summary table of the ratings given to the applications.
Chapter 9 seemed a little out of place. It is on "Separating Style from Presentation" and basically looks at CSS. I'm sure most people picking up this book will, like me, not need to be taught CSS basics. I skipped the chapter and very nearly missed an interesting little section on aural stylesheets.
I was surprised that chapter 10 was devoted to Flash, as I expected that Flash coverage in an accessibility book would be limited to a few paragraphs lambasting Macromedia for creating such an inaccessible technology. Well, it turns out that the new version of Flash supports accessibility much better than previous ones. This chapter was a real eye-opener for me. Clearly there is more work to be done but well done to Macromedia for putting accessibility support in!
Chapter 11 didn't really interest me much -- it seems to be more aimed at people who need to implement an accessibility strategy, one to hand over to managers once the technical content of the book is digested.
Chapter 12 is a bit of a heads-up on newer technologies and how they affect accessibility. There is some brief but decent discussion of how technologies such as SVG support accessibility.
The last actual chapter, Chapter 13, is a more in-depth look at U.S. web accessibility law. This was another one that I skimmed but one section did catch my eye. There is a discussion that raises the scary idea that web developers may be held liable for inaccessible web sites, even if their client told them to ignore the issue. If this is true, then it is an important point for every web developer to consider -- could you be held liable?
There are three appendices in the book; a quick reference guide summarises the most important advice given in the book, a glossary of terms and an appendix that details the U.S. Section 508 legislation.
Conclusion
Apart from the basic CSS coverage and the more U.S.-specific sections, I found the vast majority of the information in the book to be very interesting to me. The style was good too -- I was surprised that a book with 8 authors manages to maintain such a consistent and readable tone throughout.
Overall, I found the book a much more interesting read than I was expecting it to be. It gives specific advice about the way web sites should be constructed with accessibility in mind and offers strong arguments for following the advice.
It seems that accessibility is going to be a fact of life in web development. That being the case, every web developer needs to learn at least something about it, if only to use as ammunition in interviews. I would definitely recommend Constructing Accessible Websites as a good source of information on the area.
You can purchase Constructing Accessible Web Sites from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This is a book I think I'll be ordering as soon as my next personal budget is approved. In fact, I think the boss will order it anyway.
:-)
We take this so seriously that we've now hired a blind guy, to ensure that all of our sites are accesible. It's quite amazing what I'd discovered within a month of working alongside him! I've been developing/designing for years now, and thought I was pretty good at alting my tags and commenting my forms... But he's really opened my eyes to how a few simple and quick practices can be adopted to make a BIG difference.
So I recommend books of this ilk (I've not read this one yet obviously). You really can't afford to ignore these matters anymore. Even if just to find out about blindness accessiblity... generally though, Nielsen is right; most sites have significant failings in these areas.
Buy it
M.
*...Slacker, Artist, Techie - Geek *
Remember: Nothing is Cool.
You can't really have an appreciation for accessibility until you need it. It is a good lesson for everyone designing web sites to really try to use them with their monitor turned off and with speech software or on a television screen from across the room.
If anyone cares about your website, then the content matters as much or more than how it looks on your monitor. Well, I guess except for pr0n.
So instead of focusing on making the web accessible for people using alternate access methods, we should settle on a web standard. It would make the alternate methods that much easier to implement.
I think the way to go about writing univerally readable pages is to incorporate it into W3C HTML specs. I'm not saying eliminating all the things that aren't ADA compliant like javascript and tables. I talking about bringing the standard up to speed and making sure all browsers adhere to it strictly. If all browsers adhere to the standards very strictly then no non-compliant pages can be viewed with them. There's the incentive for webmasters to stick to the standards. Why are standards such an important thing? If everyone adhered to the standards, it would be infinitely easier to build tools for people with disabilities. Audio readers could parse the pages and read them back in an easy to understand way. ADA people could do what they need/want to do without pushing draconian requirements on to the rest of us.
Like I said before, I don't mean to sound like a hardass. I just don't see how the needs of the few could justify draconian legislation. If we could adhere to a standard, it would make things easier for everyone, not just handicap persons.
When I picked up this book, accessibility was an area that interested me but I am now convinced that it should be in the thoughts of every web developer. Some of the laws that are emerging to regulate accessibility look positively scary and there are lots of other good reasons to take accessibility seriously.
As a disabled person I hope people take accessibility seriously because there are disabled people who need or wish to use the internet as well. I have a permanent visual impairment and one of the worst things is websites that force a tiny font on you instead of respecting your browser's settings for what *you* need the fonts to be sized as. I really hope that people would design ther websites in such a way that both disabled and non-disabled can use them easily, and I know this is totally possible, and doesn't even require any great sacrifice on the part of the designer in having a nice looking site. Unfortunately, of course, I suppose most people won't bother until it becomes a legal requirement. Still it would be nice if they did...
"question = (to) ? be : !be;" --Shakespeare
Why should a book have more authority than the US Government? Accessiblility has been LAW for some time now. Just because you ignore it does not mean its legal to do so.
My mother is legally blind and I help her with windows usage often. Frames can be done if the Author is concious of what he/she is doing. But trash such as right clicking to save a page and the page not saving because its appearing through some deep linkage garbage is terrible. Screen readers can not dig through all that garbage.
The days when we all use HTML editors to do our websites were much kinder. Now that we use non-html tools, the generated code is quite a mess but no one cares. YOu used to be able to even read a web page through telnet. You can forget it now.
Hes right on all the flash TV Wannabe jibberish. But you can always have 2 sites. In stead of frames / non-frames, go Standard, or accessible. An accessible site can be BLAND and just a list of links and pages such as generated by TUX> or whatever that linux html generator thingy is.
Glad to see this. M$ has been bullsitting on Accessibility for ages. Though they are far ahead of Linux.
Because for Web technology, the extra costs of making your site accessible are trivial, and have lots of additional benefits, like making it accessible to sighted people browsing from PDAs, cellphones and WebTV.
I spent seven months doing civil service for Slovenian association of blind people and it was a really eye-opening experience.
First, and less important, bird watching and target-shooting are among hobbies of blind people. Yes, I was surprised to learn that too. Bad examples, but I know what you mean.
Second, I do understand your point, but think about this from different perspective. There are around 7000 registered people who are either blind or visually impaired in Slovenia, which has a population of 2 million. How many would be willing to spend time and money to make sites accessible for them? I can even give you an answer to this, because lacking legislation that USA has in this regard, the answer is pretty much noone does.
I believe it's important for society that nobody is a second class citizen. Sometimes this means that majority of us have to make some effort for that. And if sensibility of public is not enough, than it's good if there's at least legislation to push us all in the right direction.
Just make sure that your site is browsable with lynx. That's a pretty good indication that you've placed content and usability above presentation.
Hmm, I wonder how text-to-speech handles the <blink> tag?
If you were blocking sigs, you wouldn't have to read this.
The law doesn't apply to private sites. There is a section of the Americans with Disabilities Act, Section 508, that addresses web accessibility. Section 508 applies to any site that receives government funding.
However, there is a reasonable expectation that web sites won't exclude a subset of customers. This is not being addressed through any criminal process, but through various civil cases brought against individual sites. One of the most famous, of course, was the Olympic site debacle, for two iterations of the Games. After the 2000 games site was sued for not having such basics as alt-tags or a text-based menu, the 2002 games committed the same mistakes. It's just good web design to allow your code to gracefully degrade, rather than break in anything but the newest and most-overloaded browser.
I know a bit about Section 508 because I've had to do web design for DoD the past several years. Many other DoD sites, I've noticed, claim compliance while using a Flash-based menu or Java applets for buttons. Clueless.
Illegitimi non carborundum
People should also remember accessible sites are also nice and searchable sites!
My clients come to me wondering why Google doesn't index them - their site is a mess! All those fancy Flash animations are just plain opaque to the search engines and screen readers, of course they can't navigate!
I am surprised that nobody has mentioned Bobby yet. Developed by the Center for Applied Special Technology (CAST) in cooperation with the W3C, Bobby is "a software tool designed to help expose and repair barriers to accessibility and encourage compliance with existing accessibility guidelines."
I've used it extensively over the past year. It used to be freeware when it was owned by CAST, but still... at $99USD it is a miniscule cost for any company that must comply with accessibility on it's web pages.
"Bobby"