Constructing Accessible Web Sites 301
Constructing Accessible Web Sites | |
author | Jim Thatcher, Paul Bohman, Michael Burks, Shawn Lawton Henry, Bob Regan, Sarah Swierenga, Mark D. Urban, Cynthia D. Waddell |
pages | 415 |
publisher | Glasshaus |
rating | 8 |
reviewer | actiondan |
ISBN | 1904151000 |
summary | The whys and hows of making web sites accessible to all. |
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.
Don't click on Slashdots book link (Score:-1, Informative)
Save yourself some money!
Why buy the book... (Score:5, Informative)
Re:Finally getting attention! (Score:5, Informative)
Slashdot would *just* pass the basic test, I'm informed
M.
Don't click on RedWolves2 book link (Score:3, Informative)
Other vendors typically have it for less than Amazon. Go to Dealtime [dealtime.com] and use their book price comparison engine to get the best price. In this case, they report [dealtime.com] that Walmart has it for $31.49 [walmart.com]. And if you provide your zip code, they can compare prices including shipping.
And, of course, there's always half.com [ebay.com] for used books.
Re:Does anyone else have a problem with this???? (Score:5, Informative)
This isnt about your personal website, this isnt about your blog, or your Sailor Moon fan fiction.
The key here is if you run a venture that is designed as a place of *public accomadation*, then it must be accessable to all the *public*. That's the key word.
If you sell products or offer services, everyone needs to be able to access those products or services.
Ie; there's no law saying you need a wheelchair ramp on your home. If you run a restaurant, hotel, or other place of public accomodation, then there is.
The same rules about accessability coincide with good web design for the most part. Don't scan your paper catalog and serve a bunch of jpg files. Dont force people to chase down one of those stupid javascript adverts that blocks the page until you answer its poll, etc.
Re:crazy laws (Score:5, Informative)
Adapting existing sites, on the other hand, can be troublesome. If the site was designed well from the start that certain elements are modulized, adaption to accessibity should be near trivial. However, those sites that build every page uniquely will have a much harder time of getting to the end goal of accessibility. Particularly for those sites that were build by WYSIWYG editors that do not account for accessibilty options (such as tag-soup output engines).
But the key is here that there's two critical legal elements that will affect site accessibility in the States at least: Section 508 rules that apply to gov't sites and those that want to contract with it, and the potental requirement of accessibility to those commercial sites that may be covered by the ADA (see the recent stories on lawsuits against American and Southwest Airlines by blind users). Hobbists', non-commercial, or otherwise personal web sites have yet to be concerned for accessibility and I don't believe they ever will be, as these provide no required service to the general public.
That's not to say that you shouldn't think about accessibility if you run that type of site. Accessibility is not only about making your site available to more people, but it's also about better web design in general; seperate presentation from content, don't treat the browser as a pixel-perfect rendering engine, and the like. A causal site design would certainly do no harm in converting an inaccessible site to one that is, and that could mean more visitors and also improving one's HTML/web page skills.
Betsie (Score:5, Informative)
Re:Boring Web (Score:4, Informative)
Save some time... (Score:5, Informative)
* That doesn't mean using Dreamweaver or any other GUI HTML design software. Real HTML-ers write it by hand. Real Men use vi [thomer.com] from what I hear but I like BBEdit [barebones.com] for UNIX [apple.com].
Re:Why buy the book... (Score:5, Informative)
Re:We don't nee more legislation (Score:3, Informative)
Re:Lemme guess... (Score:2, Informative)
BTW, the W3C HTML validator [w3.org] checks out your code and will tell you what's not standard. To make sure your code is syntactically correct, make your page XHTML 1.0 compliant, and you'll be in good shape. (XHTML requires many of these 'optional' attributes, like 'alt' attributes for images, and closing 'p' tags, etc. It's very handy; it makes your code cleaner, and it turns HTML into an XML document.)
Re:Simple Question (Score:5, Informative)
I think a good compromise here would be what a lot of people did back when frames were all the rage. Simply offer a no-frills page for people who are disabled. You get to keep your flashy page for your regularly abled (hah) consumers, and those who need special access can get it.
Also, I don't personally use/need screen readers, what I do need is websites that do simple things like respect my need for larger fonts (that means flash is right out). A lot of websites don't do that, and until the last year or so I had to actually copy out the text I needed to read and paste it into something else. Now mozilla at least does text enlarging which makes my life a hell of a lot easier.
http://www.diveintoaccessibility.org/ (Score:4, Informative)
Re:Lemme guess... (Score:5, Informative)
Actually, the newest Flash version has capabilities for disabled people. the Nielsen Norman Group [nngroup.com] helped them in adapting the product for different target groups.
The latest Alertbox [useit.com] of Jacob Nielsen talks about Making Flash Usable for Users With Disabilities - also the subject of a tutorial [macromedia.com] at Macromedia DevCon [macromedia.com] in Orlando.
Re:crazy laws (Score:2, Informative)
Well, in a way "they" do. Under the US copyright law, publishers are required to allow agencies serving people with disabilities to produce accessible versions of their books without charging royalties. Thus, for example, organizations like Recording for the Blind & Dyslexic [rfbd.org] can freely produce audio textbooks for distribution to students with print disabilities.
And there's more on the way. A bill has been introduced into congress (the Instructional Materials Accessibility Act) that will take this further, requiring textbook publishers to provide electronic text files in a uniform format for use by agencies that produce Braille and audio books for students with disabilities.
Re:Hopefully for the *users*.. (Score:5, Informative)
Then why do you let the html dictate what font's/fontsize you see?
In the 3 major browsers, its easy:
Moz: Edit|Preferences|Appearance|Fonts - choose your font's and typesize, and uncheck "Allow documents to use other fonts"
IE: Tools|Internet Options|General Tab - Fonts Button: Set your Fonts and typesize here|Accessablity button: check the 2 "Ignore font..." box's, or you can supply your own style sheet
Opera: File|Preferences|Fonts: there are too many options that you can control here, upto and including using your own style sheet.
It's not difficult for the end-user to do, or to have it done for them by a helper.
Just my
Dive Into Accessibility (Score:3, Informative)
Mark Pilgrim has a wonderful site at http://diveintoaccessibility.org/ [diveintoac...bility.org]
It's set up as a 30-day transformation process, with each day containing a new change. He includes has a few example characters, each with their own unique set of disabilities and/or web-browsing choices, and he explains how each of these people would benefit from said changes.
No info on dynamic visual data? (Score:4, Informative)
Re:Hopefully for the *users*.. (Score:3, Informative)
Mostly because I'd like to preserve as much of the design as possible. I think that (at least on some sites
The simple fact of the matter is that since just about every site out there is "done for IE" people *know* what the default fontsizes in IE are. It is very uncommon for people to change their default fontsizes, and I think that when they do webpages should respect that simply because that does not violate POLA. It's not *just* for visually disabled people, those who want fonts bigger or smaller for whatever reason should be able to get them, and it doesn't take much to not hardcode your fontsizes.
Re:http://www.diveintoaccessibility.org/ (Score:2, Informative)
There is also a pretty interesting example of usability gone wild at Chris Davis' - Sillyness spelled wrong intentionally [concepthause.com] who's site validates as XHTML 1.0 strict [w3.org]
I've often wondered if sometimes we're not all hooked into usability for usability sake, sometime forsaking compelling content? Not so much in the case of Chris Davis, but of some other sites claiming to be diciples of 'the Pilgrim [google.com]'.
Re:Why buy the book... (Score:4, Informative)
The problem with tools like Bobby is that they only address half the issue, things like ALT tags, commenting, etc. What Bobby does NOT do well is address "readability" issues. While implementing CSS, using ALT Tags, formatting forms, and commenting your pages are nice, a poor layout can make the page completely unreadable to a blind user. I couldn't tell you how many pages I've seen that "passed" their Bobby checks, but were totally unuseable by screen readers because of poor table and content layouts. Instead of using Bobby, try this one on your next page: Download a copy of JAWS [freedomscientific.com] or the IBM Homepage Reader [ibm.com], put on a blindfold, and try to surf your website by ear. If you have designed your website well, you should have no problems. If the reader makes no sense, then your site is NOT accessible...whether or not Bobby likes it.
Accessibity, in a nutshell: do it (Score:5, Informative)
Why? Here's the quick course:
On the web, the primary way that information is represented is in the form of HTML and XML documents.
Neither HTML nor XML was designed as a visual medium; rather, both are intended to represent information in a manner that is independent of presentation.
However -- and this is where the problems start -- almost all other media that designers and content creators have experience with (e.g., the ever-popular ink on paper) are visually oriented media, and so many designers and content creators approach web media with this bias.
As a result, all too many web sites are designed with the goal of looking a certain way instead of communicating the intended information clearly. This is an understandable error because with most other media (e.g., ink on paper), these two goals are one and the same. But it is still an error.
To correct the error requires nothing more than the following:
Even if your web site's audience does not include people with disabilities, there are many good reasons for making your site accessible:
There you have it. When doing the right thing is easier, why not do it?
medical websites (Score:3, Informative)
Re:Hopefully for the *users*.. (Score:4, Informative)
I think it comes down to the difference between absolute font sizes and relative font sizes. I like to use the 'Larger' setting for font sizes in IE (I've recently moved to Mozilla and now use the 150% setting) as it's more comfortable for me and I can read default sized text OK. If a web page uses relative font sizes then I can still read it OK as IE (or Mozilla) will apply the size adjustment I've specified on top of the one specified by the web page. However if the page specifies an absolute size the IE will render the text at that size (I haven't been using Mozilla long enough to make a definate statement on what it does yet), not appling the size adjustment I've specified.
I've tried using the overrides in IE, including local stylesheet, but have found it patchy at best. For example if the page specifies a separate stylesheet IE will use my local one instead, if it uses an inline stylesheet it will override some settings but not all and if it uses style settings in the body of the page it won't override them at all.
Probably for some sites the design and the content are intertwined, however most of the sites I use most often (mainly technical how-to sites, product information sites and Buffy fanfiction sites) the important parts of the content are separate from the presentation/design side of things. I want to be able to read the text, not struggle to read it due to it being set to a small font size or get a headache from the color scheme the page author has chosen to use (e.g. pale yellow on orange, yellow on blue, dark brown on black &c, those are real colour schemes I've seen in the past few weeks).
Stephen
Re:Hopefully for the *users*.. (Score:3, Informative)
Haven't used Opera much and only recently started using Mozilla so can't really comment on those. However I can tell you from bitter experience that the overrides in IE (and the last version of Netscape that I used, four point something I think) work patchilly at best.
Typically they will override somethings but not others, depending on how the page sets things. The overrides are not a universal panacea for poorly accessible pages.
Stephen
Corrected Link (Score:2, Informative)
link for german-speaking people (Score:3, Informative)
einfach für alle [einfach-fuer-alle.de]